date:20190514

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

Regressions :-(

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

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

version targeted for testing:
 xen  3c04c258ab40405a74e194d9889a4cbc7abe94b4
baseline version:
 xen  99bb45e684283b3bc621dbc99b1b93c856b4dd1c

Last test of basis   136179  2019-05-13 16:02:31 Z1 days
Failing since136227  2019-05-14 15:01:02 Z0 days4 attempts
Testing same since   136241  2019-05-14 19:10:38 Z0 days3 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Julien Grall 

jobs:
 build-arm64-xsm  pass
 build-amd64  fail
 build-armhf  pass
 build-amd64-libvirt  blocked 
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-amd64-libvirt blocked 



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

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

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

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


Not pushing.


commit 3c04c258ab40405a74e194d9889a4cbc7abe94b4
Author: Andrew Cooper 
Date:   Wed Dec 12 19:22:15 2018 +

x86/spec-ctrl: Introduce options to control VERW flushing

The Microarchitectural Data Sampling vulnerability is split into categories
with subtly different properties:

 MLPDS - Microarchitectural Load Port Data Sampling
 MSBDS - Microarchitectural Store Buffer Data Sampling
 MFBDS - Microarchitectural Fill Buffer Data Sampling
 MDSUM - Microarchitectural Data Sampling Uncacheable Memory

MDSUM is a special case of the other three, and isn't distinguished further.

These issues pertain to three microarchitectural buffers.  The Load Ports, 
the
Store Buffers and the Fill Buffers.  Each of these structures are flushed by
the new enhanced VERW functionality, but the conditions under which flushing
is necessary vary.

For this concise overview of the issues and default logic, the abbreviations
SP (Store Port), FB (Fill Buffer), LP (Load Port) and HT (Hyperthreading) 
are
used for brevity:

 * Vulnerable hardware is divided into two categories - parts which suffer
   from SP only, and parts with any other combination of vulnerabilities.

 * SP only has an HT interaction when the thread goes idle, due to the 
static
   partitioning of resources.  LP and FB have HT interactions at all points,
   due to the competitive sharing of resources.  All issues potentially leak
   data across the return-to-guest transition.

 * The microcode which implements VERW flushing also extends MSR_FLUSH_CMD, 
so
   we don't need to do both on the HVM return-to-guest path.  However, some
   parts are not vulnerable to L1TF (therefore have no MSR_FLUSH_CMD), but 
are
   vulnerable to MDS, so do require VERW on the HVM path.

Note that we deliberately support mds=1 even without MD_CLEAR in case the
microcode has been updated but the feature bit not exposed.

This is part of XSA-297, CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, 
CVE-2019-11091.

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

commit 548a932ac786d6bf3584e4b54f2ab993e1117710
Author: Andrew Cooper 
Date:   Wed Dec 12 19:22:15 2018 +

x86/spec-ctrl: Infrastructure to use VERW to

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

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  e83077a3d11072708a5c38fa09fa9d011914e2a1
baseline version:
 xen  e83077a3d11072708a5c38fa09fa9d011914e2a1

Last test of basis   136156  2019-05-13 05:08:01 Z1 days
Testing same since  (not found) 0 attempts

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

[Xen-devel] [xen-unstable-smoke test] 136258: regressions - FAIL

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

Regressions :-(

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

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

version targeted for testing:
 xen  3c04c258ab40405a74e194d9889a4cbc7abe94b4
baseline version:
 xen  99bb45e684283b3bc621dbc99b1b93c856b4dd1c

Last test of basis   136179  2019-05-13 16:02:31 Z1 days
Failing since136227  2019-05-14 15:01:02 Z0 days3 attempts
Testing same since   136241  2019-05-14 19:10:38 Z0 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Julien Grall 

jobs:
 build-arm64-xsm  pass
 build-amd64  fail
 build-armhf  pass
 build-amd64-libvirt  blocked 
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-amd64-libvirt blocked 



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

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

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

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


Not pushing.


commit 3c04c258ab40405a74e194d9889a4cbc7abe94b4
Author: Andrew Cooper 
Date:   Wed Dec 12 19:22:15 2018 +

x86/spec-ctrl: Introduce options to control VERW flushing

The Microarchitectural Data Sampling vulnerability is split into categories
with subtly different properties:

 MLPDS - Microarchitectural Load Port Data Sampling
 MSBDS - Microarchitectural Store Buffer Data Sampling
 MFBDS - Microarchitectural Fill Buffer Data Sampling
 MDSUM - Microarchitectural Data Sampling Uncacheable Memory

MDSUM is a special case of the other three, and isn't distinguished further.

These issues pertain to three microarchitectural buffers.  The Load Ports, 
the
Store Buffers and the Fill Buffers.  Each of these structures are flushed by
the new enhanced VERW functionality, but the conditions under which flushing
is necessary vary.

For this concise overview of the issues and default logic, the abbreviations
SP (Store Port), FB (Fill Buffer), LP (Load Port) and HT (Hyperthreading) 
are
used for brevity:

 * Vulnerable hardware is divided into two categories - parts which suffer
   from SP only, and parts with any other combination of vulnerabilities.

 * SP only has an HT interaction when the thread goes idle, due to the 
static
   partitioning of resources.  LP and FB have HT interactions at all points,
   due to the competitive sharing of resources.  All issues potentially leak
   data across the return-to-guest transition.

 * The microcode which implements VERW flushing also extends MSR_FLUSH_CMD, 
so
   we don't need to do both on the HVM return-to-guest path.  However, some
   parts are not vulnerable to L1TF (therefore have no MSR_FLUSH_CMD), but 
are
   vulnerable to MDS, so do require VERW on the HVM path.

Note that we deliberately support mds=1 even without MD_CLEAR in case the
microcode has been updated but the feature bit not exposed.

This is part of XSA-297, CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, 
CVE-2019-11091.

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

commit 548a932ac786d6bf3584e4b54f2ab993e1117710
Author: Andrew Cooper 
Date:   Wed Dec 12 19:22:15 2018 +

x86/spec-ctrl: Infrastructure to use VERW to

[Xen-devel] [xen-4.7-testing test] 136175: regressions - FAIL

flight 136175 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136175/

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-credit1   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-win10-i386  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm  1 build-check(1)  blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-xtf-amd64-amd64-51 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-shadow 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm  1 build-check(1) blocked n/a
 test-xtf-amd64-amd64-41 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win10-i386  1 build-check(1) blocked n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-migrupgrade   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)  blocked n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qemut-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a

[Xen-devel] [linux-linus bisection] complete test-amd64-amd64-pair

branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-pair
testid guests-nbd-mirror/debian

Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  linux 
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
  Bug introduced:  47782361aca21a32ad4198f1b72f1655a7c9f7e5
  Bug not present: 444fe991353987c1c9bc5ab1f903d01f1b4ad415
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/136256/


  (Revision log too long, omitted.)


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-linus/test-amd64-amd64-pair.guests-nbd-mirror--debian.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/linux-linus/test-amd64-amd64-pair.guests-nbd-mirror--debian
 --summary-out=tmp/136256.bisection-summary --basis-template=133580 
--blessings=real,real-bisect linux-linus test-amd64-amd64-pair 
guests-nbd-mirror/debian
Searching for failure / basis pass:
 136116 fail [dst_host=godello0,src_host=godello1] / 135873 
[dst_host=italia0,src_host=italia1] 135753 [dst_host=italia1,src_host=italia0] 
135539 [dst_host=albana1,src_host=albana0] 135443 
[dst_host=albana0,src_host=albana1] 135426 
[dst_host=godello1,src_host=godello0] 135223 
[dst_host=chardonnay1,src_host=chardonnay0] 135057 
[dst_host=elbling0,src_host=elbling1] 134984 
[dst_host=albana1,src_host=albana0] 134885 ok.
Failure / basis pass flights: 136116 / 134885
(tree with no url: minios)
(tree with no url: seabios)
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 47782361aca21a32ad4198f1b72f1655a7c9f7e5 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
cd5147734cbe82f0c1665eb232608d75643944b0 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
9cca02d8ffc23e9688a971d858e4ffdff5389b11 
cb70a26f78848fe45f593f7ebc9cfaac760a791b
Basis pass 444fe991353987c1c9bc5ab1f903d01f1b4ad415 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
ef529e6ab7c31290a33045bb1f1837447cc0eb56 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
de5b678ca4dcdfa83e322491d478d66df56c1986 
cb70a26f78848fe45f593f7ebc9cfaac760a791b
Generating revisions with ./adhoc-revtuple-generator  
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#444fe991353987c1c9bc5ab1f903d01f1b4ad415-47782361aca21a32ad4198f1b72f1655a7c9f7e5
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/osstest/ovmf.git#ef529e6ab7c31290a33045bb1f1837447cc0eb56-cd5147734cbe82f0c1665eb232608d75643944b0
 git://xenbits.xen.org/qemu-xen-traditional.\
 
git#d0d8ad39ecb51cd7497cd524484fe09f50876798-d0d8ad39ecb51cd7497cd524484fe09f50876798
 
git://xenbits.xen.org/qemu-xen.git#de5b678ca4dcdfa83e322491d478d66df56c1986-9cca02d8ffc23e9688a971d858e4ffdff5389b11
 
git://xenbits.xen.org/xen.git#cb70a26f78848fe45f593f7ebc9cfaac760a791b-cb70a26f78848fe45f593f7ebc9cfaac760a791b
adhoc-revtuple-generator: tree discontiguous: linux-2.6
adhoc-revtuple-generator: tree discontiguous: ovmf
adhoc-revtuple-generator: tree discontiguous: qemu-xen
Loaded 4 nodes in revision graph
Searching for test results:
 125898 [dst_host=elbling0,src_host=elbling1]
 125921 [dst_host=pinot1,src_host=pinot0]
 126069 [dst_host=joubertin0,src_host=joubertin1]
 126202 [dst_host=albana1,src_host=albana0]
 126310 [dst_host=godello1,src_host=godello0]
 126412 [dst_host=debina1,src_host=debina0]
 126550 [dst_host=debina1,src_host=debina0]
 126682 [dst_host=debina1,src_host=debina0]
 126888 [dst_host=debina1,src_host=debina0]
 126978 [dst_host=debina1,src_host=debina0]
 127038 [dst_host=debina1,src_host=debina0]
 127108 [dst_host=debina1,src_host=debina0]
 127221 [dst_host=debina1,src_host=debina0]
 127148 [dst_host=debina1,src_host=debina0]
 127256 [dst_host=debina1,src_host=debina0]
 127193 [dst_host=debina1,src_host=debina0]
 127284 [dst_host=debina1,src_host=debina0]
 127315 [dst_host=debina1,src_host=debina0]
 127344 [dst_host=debina1,src_host=debina0]
 127364 [dst_host=debina1,src_host=debina0]
 127389 [dst_host=debina1,src_host=debina0]
 127403 [dst_host=debina1,src_host=debina0]
 127415 [dst_host=debina1,src_host=debina0]
 127428 [dst_host=debina1,src_host=debina0]
 127427 [dst_host=debina1,src_host=debina0]
 127425

Re: [Xen-devel] [PATCH v2 1/2] KVM: Start populating /sys/hypervisor with KVM entries

2019-05-14 Thread Sironi, Filippo



> On 14. May 2019, at 18:09, Sironi, Filippo  wrote:
> 
>> On 14. May 2019, at 17:26, Christian Borntraeger  
>> wrote:
>> 
>>> On 14.05.19 17:16, Filippo Sironi wrote:
>>> Start populating /sys/hypervisor with KVM entries when we're running on
>>> KVM. This is to replicate functionality that's available when we're
>>> running on Xen.
>>> 
>>> Start with /sys/hypervisor/uuid, which users prefer over
>>> /sys/devices/virtual/dmi/id/product_uuid as a way to recognize a virtual
>>> machine, since it's also available when running on Xen HVM and on Xen PV
>>> and, on top of that doesn't require root privileges by default.
>>> Let's create arch-specific hooks so that different architectures can
>>> provide different implementations.
>>> 
>>> Signed-off-by: Filippo Sironi 
>>> ---
>>> v2:
>>> * move the retrieval of the VM UUID out of uuid_show and into
>>> kvm_para_get_uuid, which is a weak function that can be overwritten
>>> 
>>> drivers/Kconfig  |  2 ++
>>> drivers/Makefile |  2 ++
>>> drivers/kvm/Kconfig  | 14 ++
>>> drivers/kvm/Makefile |  1 +
>>> drivers/kvm/sys-hypervisor.c | 30 ++
>>> 5 files changed, 49 insertions(+)
>>> create mode 100644 drivers/kvm/Kconfig
>>> create mode 100644 drivers/kvm/Makefile
>>> create mode 100644 drivers/kvm/sys-hypervisor.c
>>> 
>>> diff --git a/drivers/Kconfig b/drivers/Kconfig
>>> index 45f9decb9848..90eb835fe951 100644
>>> --- a/drivers/Kconfig
>>> +++ b/drivers/Kconfig
>>> @@ -146,6 +146,8 @@ source "drivers/hv/Kconfig"
>>> 
>>> source "drivers/xen/Kconfig"
>>> 
>>> +source "drivers/kvm/Kconfig"
>>> +
>>> source "drivers/staging/Kconfig"
>>> 
>>> source "drivers/platform/Kconfig"
>>> diff --git a/drivers/Makefile b/drivers/Makefile
>>> index c61cde554340..79cc92a3f6bf 100644
>>> --- a/drivers/Makefile
>>> +++ b/drivers/Makefile
>>> @@ -44,6 +44,8 @@ obj-y += soc/
>>> obj-$(CONFIG_VIRTIO)+= virtio/
>>> obj-$(CONFIG_XEN)   += xen/
>>> 
>>> +obj-$(CONFIG_KVM_GUEST)+= kvm/
>>> +
>>> # regulators early, since some subsystems rely on them to initialize
>>> obj-$(CONFIG_REGULATOR) += regulator/
>>> 
>>> diff --git a/drivers/kvm/Kconfig b/drivers/kvm/Kconfig
>>> new file mode 100644
>>> index ..3fc041df7c11
>>> --- /dev/null
>>> +++ b/drivers/kvm/Kconfig
>>> @@ -0,0 +1,14 @@
>>> +menu "KVM driver support"
>>> +depends on KVM_GUEST
>>> +
>>> +config KVM_SYS_HYPERVISOR
>>> +bool "Create KVM entries under /sys/hypervisor"
>>> +depends on SYSFS
>>> +select SYS_HYPERVISOR
>>> +default y
>>> +help
>>> +  Create KVM entries under /sys/hypervisor (e.g., uuid). When 
>>> running
>>> +  native or on another hypervisor, /sys/hypervisor may still be
>>> +  present, but it will have no KVM entries.
>>> +
>>> +endmenu
>>> diff --git a/drivers/kvm/Makefile b/drivers/kvm/Makefile
>>> new file mode 100644
>>> index ..73a43fc994b9
>>> --- /dev/null
>>> +++ b/drivers/kvm/Makefile
>>> @@ -0,0 +1 @@
>>> +obj-$(CONFIG_KVM_SYS_HYPERVISOR) += sys-hypervisor.o
>>> diff --git a/drivers/kvm/sys-hypervisor.c b/drivers/kvm/sys-hypervisor.c
>>> new file mode 100644
>>> index ..43b1d1a09807
>>> --- /dev/null
>>> +++ b/drivers/kvm/sys-hypervisor.c
>>> @@ -0,0 +1,30 @@
>>> +/* SPDX-License-Identifier: GPL-2.0 */
>>> +
>>> +#include 
>>> +
>>> +#include 
>>> +#include 
>>> +
>>> +__weak const char *kvm_para_get_uuid(void)
>>> +{
>>> +   return NULL;
>>> +}
>>> +
>>> +static ssize_t uuid_show(struct kobject *obj,
>>> +struct kobj_attribute *attr,
>>> +char *buf)
>>> +{
>>> +   const char *uuid = kvm_para_get_uuid();
>> 
>> I would prefer to have kvm_para_get_uuid return a uuid_t
>> but char * will probably work out as well.
> 
> Let me give this a quick spin.

I looked into getting a uuid_t.

At least for architectures where we retrieve that bit of
information from DMI tables, this is undesirable since
the interpretation of the UUID changed with DMI 2.6
(the first 3 fields are now encoded in little-endian).
This means that we wouldn't know how to print it in this
generic code.

I think that it's best if the architecture specific code
turns the UUID into the string representation.

>>> +   return sprintf(buf, "%s\n", uuid);
>>> +}
>>> +
>>> +static struct kobj_attribute uuid = __ATTR_RO(uuid);
>>> +
>>> +static int __init uuid_init(void)
>>> +{
>>> +   if (!kvm_para_available())
>> 
>> Isnt kvm_para_available a function that is defined in the context of the HOST
>> and not of the guest?
> 
> No, kvm_para_available is defined in the guest context.
> On x86, it checks for the presence of the KVM CPUID leafs.
> 
>>> +   return 0;
>>> +   return sysfs_create_file(hypervisor_kobj, );
>>> +}
>>> +
>>> +device_initcall(uuid_init);




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin

[Xen-devel] [xen-unstable-smoke test] 136241: regressions - FAIL

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

Regressions :-(

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

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-amd64-libvirt  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  3c04c258ab40405a74e194d9889a4cbc7abe94b4
baseline version:
 xen  99bb45e684283b3bc621dbc99b1b93c856b4dd1c

Last test of basis   136179  2019-05-13 16:02:31 Z1 days
Failing since136227  2019-05-14 15:01:02 Z0 days2 attempts
Testing same since   136241  2019-05-14 19:10:38 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Julien Grall 

jobs:
 build-arm64-xsm  pass
 build-amd64  fail
 build-armhf  pass
 build-amd64-libvirt  blocked 
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-amd64-libvirt blocked 



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

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

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

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


Not pushing.


commit 3c04c258ab40405a74e194d9889a4cbc7abe94b4
Author: Andrew Cooper 
Date:   Wed Dec 12 19:22:15 2018 +

x86/spec-ctrl: Introduce options to control VERW flushing

The Microarchitectural Data Sampling vulnerability is split into categories
with subtly different properties:

 MLPDS - Microarchitectural Load Port Data Sampling
 MSBDS - Microarchitectural Store Buffer Data Sampling
 MFBDS - Microarchitectural Fill Buffer Data Sampling
 MDSUM - Microarchitectural Data Sampling Uncacheable Memory

MDSUM is a special case of the other three, and isn't distinguished further.

These issues pertain to three microarchitectural buffers.  The Load Ports, 
the
Store Buffers and the Fill Buffers.  Each of these structures are flushed by
the new enhanced VERW functionality, but the conditions under which flushing
is necessary vary.

For this concise overview of the issues and default logic, the abbreviations
SP (Store Port), FB (Fill Buffer), LP (Load Port) and HT (Hyperthreading) 
are
used for brevity:

 * Vulnerable hardware is divided into two categories - parts which suffer
   from SP only, and parts with any other combination of vulnerabilities.

 * SP only has an HT interaction when the thread goes idle, due to the 
static
   partitioning of resources.  LP and FB have HT interactions at all points,
   due to the competitive sharing of resources.  All issues potentially leak
   data across the return-to-guest transition.

 * The microcode which implements VERW flushing also extends MSR_FLUSH_CMD, 
so
   we don't need to do both on the HVM return-to-guest path.  However, some
   parts are not vulnerable to L1TF (therefore have no MSR_FLUSH_CMD), but 
are
   vulnerable to MDS, so do require VERW on the HVM path.

Note that we deliberately support mds=1 even without MD_CLEAR in case the
microcode has been updated but the feature bit not exposed.

This is part of XSA-297, CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, 
CVE-2019-11091.

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

commit 548a932ac786d6bf3584e4b54f2ab993e1117710
Author: Andrew Cooper 
Date:   Wed Dec 12 19:22:15 2018 +

x86/spec-ctrl: Infrastructure to use VERW to

Re: [Xen-devel] [PATCH 3/5] iommu: move iommu_get_ops() into common code

Hi,

On 5/14/19 5:19 PM, Paul Durrant wrote:

-Original Message-
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: 13 May 2019 09:11
To: Paul Durrant 
Cc: Brian Woods ; Suravee Suthikulpanit 
; Julien
Grall ; Andrew Cooper ; Roger 
Pau Monne
; Wei Liu ; Kevin Tian 
; Stefano
Stabellini ; xen-devel 
Subject: Re: [PATCH 3/5] iommu: move iommu_get_ops() into common code

On 08.05.19 at 15:24,  wrote:

Currently x86 and ARM differ in their implementation for no good reason.
This patch moves the ARM variant of iommu_get/set_ops() helpers into
common code and modifies them so they deal with the __initconstrel
ops structures used by the x86 IOMMU vendor implementations (adding
__initconstrel to the SMMU code to bring it in line). Consequently, a lack
of init() method is now taken to mean uninitialized iommu_ops. Also, the
printk warning in iommu_set_ops() now becomes an ASSERT.

When having submitted the indirect call overhead reduction series
including IOMMU changes for the first time, I was told that the Arm
folks would like to retain the ability to eventually support
heterogeneous IOMMUs (and hence I shouldn't provide patching
infrastructure there). A single global iommu_[gs]et_ops() is sort of
getting in the way of this as well, I think, and hence I'm not sure it
is a desirable step to make this so far Arm-specific arrangement
the general model. At least it would further complicate Arm side
changes towards that (mid / long term?) goal.

That's correct, it is a mid / long term plan.

Ok. Do you have any more information on what such an architecture would look 
like? I guess it is also conceivable that an x86 architecture might have 
slightly different IOMMU implementations (or at least quirks) for different PCI 
segments. So perhaps a global ops structure is not a good idea in the long run.

I can see two uses cases:
1) Finding the IOMMU associated to a device
2) Applying an operation (i.e domain creation/destruction, 
map/unmap) on all the IOMMU

Actually, we already have similar concept within the SMMU driver because 
a platform may contain multiple SMMUs.

Any generic interface would actually be quite beneficial as we could 
simplify a lot the driver and avoid duplicating the logic in all the new 
Arm drivers.

Cheers,

--
Julien Grall

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

[Xen-devel] [freebsd-master test] 136173: all pass - PUSHED

flight 136173 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136173/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 freebsd  e45876ac9f0ee913fcc73cfa00e409a5a461dbfb
baseline version:
 freebsd  fbc304aae0efb87e60f17c0a42ca7c8286c24f1f

Last test of basis   136000  2019-05-10 14:50:45 Z4 days
Testing same since   136173  2019-05-13 09:19:54 Z1 days1 attempts


People who touched revisions under test:
  ae 
  bdrewery 
  br 
  cem 
  cy 
  delphij 
  dougm 
  glebius 
  jhb 
  jhibbits 
  johalun 
  kevans 
  luporl 
  manu 
  markj 
  mjg 
  rmacklem 
  schweikh 

jobs:
 build-amd64-freebsd-againpass
 build-amd64-freebsd  pass
 build-amd64-xen-freebsd  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 :

To xenbits.xen.org:/home/xen/git/freebsd.git
   fbc304aae0e..e45876ac9f0  e45876ac9f0ee913fcc73cfa00e409a5a461dbfb -> 
tested/master

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

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

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs. 134015

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

version targeted for testing:
 linuxbb4f008d1e075986888ad01579c21f79b62f5775
baseline version:
 linux1c453afcda4f68f634475f166418e937ac235200

Last test of basis   134015  2019-03-23

[Xen-devel] [xen-4.8-testing test] 136138: regressions - FAIL

flight 136138 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136138/

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-xtf-amd64-amd64-4 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 136028 pass 
in 136138
 test-xtf-amd64-amd64-2   50 xtf/test-hvm64-lbr-tsx-vmentry fail pass in 136028
 test-xtf-amd64-amd64-5   70 xtf/test-hvm64-xsa-278 fail pass in 136028
 test-xtf-amd64-amd64-2   70 xtf/test-hvm64-xsa-278 fail pass in 136028

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-migrupgrade  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-win10-i386  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-migrupgrade   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm  1 build-check(1)  blocked n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-livepatch 1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemut-win10-i386  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-shadow 1 build-check(1)   blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-5  50 xtf/test-hvm64-lbr-tsx-vmentry fail like 130965
 test-xtf-amd64-amd64-1  50 xtf/test-hvm64-lbr-tsx-vmentry fail like 130965
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 130965
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 130965
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 130965
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 130965
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass

[Xen-devel] [xen-4.6-testing test] 136152: regressions - FAIL

flight 136152 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136152/

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-xtf-amd64-amd64-51 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win10-i386  1 build-check(1) blocked n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-shadow1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-xtf-amd64-amd64-41 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemut-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-i386-migrupgrade   1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-11 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-21 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win10-i386  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm  1 build-check(1) blocked n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-qemuu-win10-i386  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1)  blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-credit1   1 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-31 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-migrupgrade  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1) blocked n/a

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

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-pair18 guests-nbd-mirror/debian fail REGR. vs. 133580
 test-amd64-amd64-xl-credit1  15 guest-saverestorefail REGR. vs. 133580
 test-amd64-amd64-xl-pvhv2-amd 15 guest-saverestore   fail REGR. vs. 133580
 test-amd64-i386-freebsd10-amd64 10 freebsd-install   fail REGR. vs. 133580
 test-amd64-amd64-xl-credit2  11 debian-fixup fail REGR. vs. 133580
 test-amd64-amd64-libvirt 11 debian-fixup fail REGR. vs. 133580
 test-amd64-amd64-libvirt-pair 17 debian-fixup/dst_host   fail REGR. vs. 133580
 test-amd64-amd64-xl-pvshim   11 debian-fixup fail REGR. vs. 133580
 test-amd64-amd64-xl-multivcpu 12 guest-start fail REGR. vs. 133580
 test-amd64-i386-libvirt-xsm  11 debian-fixup fail REGR. vs. 133580
 test-amd64-i386-qemut-rhel6hvm-amd 10 redhat-install fail REGR. vs. 133580
 test-amd64-amd64-xl-shadow   11 debian-fixup fail REGR. vs. 133580
 test-amd64-amd64-libvirt-xsm 11 debian-fixup fail REGR. vs. 133580
 test-amd64-amd64-xl-pvhv2-intel 15 guest-saverestore fail REGR. vs. 133580
 test-amd64-i386-libvirt-pair 17 debian-fixup/dst_hostfail REGR. vs. 133580
 test-amd64-i386-xl   11 debian-fixup fail REGR. vs. 133580
 test-amd64-i386-pair 17 debian-fixup/dst_hostfail REGR. vs. 133580
 test-amd64-i386-xl-pvshim11 debian-fixup fail REGR. vs. 133580
 test-amd64-i386-xl-xsm   15 guest-saverestorefail REGR. vs. 133580
 test-amd64-amd64-xl  11 debian-fixup fail REGR. vs. 133580
 test-amd64-amd64-xl-xsm  15 guest-saverestorefail REGR. vs. 133580
 test-amd64-amd64-qemuu-nested-amd 10 debian-hvm-install  fail REGR. vs. 133580
 test-amd64-i386-qemuu-rhel6hvm-intel 10 redhat-install   fail REGR. vs. 133580
 test-amd64-i386-xl-shadow15 guest-saverestorefail REGR. vs. 133580
 test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs. 133580
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail 
REGR. vs. 133580
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail 
REGR. vs. 133580
 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 
133580
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail 
REGR. vs. 133580
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail REGR. vs. 133580
 test-amd64-i386-xl-qemut-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 
133580
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail 
REGR. vs. 133580
 test-amd64-amd64-xl-qemut-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 
133580
 test-amd64-amd64-qemuu-nested-intel 10 debian-hvm-install fail REGR. vs. 133580
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 
133580
 test-amd64-amd64-libvirt-vhd 14 guest-saverestorefail REGR. vs. 133580
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install 
fail REGR. vs. 133580
 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 
133580
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install 
fail REGR. vs. 133580
 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 133580
 test-amd64-amd64-i386-pvgrub 17 guest-localmigrate/x10   fail REGR. vs. 133580
 test-arm64-arm64-xl-credit1  10 debian-install   fail REGR. vs. 133580
 test-arm64-arm64-libvirt-xsm 10 debian-install   fail REGR. vs. 133580
 test-arm64-arm64-xl-credit2  11 debian-fixup fail REGR. vs. 133580
 test-arm64-arm64-xl-xsm  10 debian-install   fail REGR. vs. 133580
 test-amd64-amd64-xl-qcow216 guest-saverestore.2  fail REGR. vs. 133580
 test-arm64-arm64-xl  11 debian-fixup fail REGR. vs. 133580
 test-amd64-i386-libvirt 18 guest-start/debian.repeat fail REGR. vs. 133580
 test-amd64-amd64-amd64-pvgrub 16 guest-saverestore.2 fail REGR. vs. 133580
 test-amd64-amd64-pygrub  17 guest-localmigrate/x10   fail REGR. vs. 133580
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 15 
depriv-audit-qemu/create fail REGR. vs. 133580
 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install   fail REGR. vs. 133580
 test-amd64-i386-xl-raw   10 debian-di-installfail REGR. vs. 133580
 test-amd64-i386-xl-qemut-win7-amd64 10 windows-install   fail REGR. vs. 133580
 test-amd64-amd64-xl-qemut-win7-amd64 10 windows-install  fail REGR. vs. 133580
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-install  fail REGR. vs. 133580
 test-amd64-amd64-xl-qemuu-win7-amd64 10 windows-install  fail REGR. vs. 133580
 test-amd64-i386-xl-qemut-ws16-amd64 10 windows-install

[Xen-devel] [PATCH v1 2/2] arm: rename tiny64.conf to tiny64_defconfig

2019-05-14 Thread Volodymyr Babchuk

As build system now supports *_defconfig rules it is good to be able
to configure minimal XEN image with

 make tiny64_defconfig

command.

Signed-off-by: Volodymyr Babchuk 
Suggested-by: Andrii Anisov 
---
 xen/arch/arm/configs/{tiny64.conf => tiny64_defconfig} | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename xen/arch/arm/configs/{tiny64.conf => tiny64_defconfig} (100%)

diff --git a/xen/arch/arm/configs/tiny64.conf 
b/xen/arch/arm/configs/tiny64_defconfig
similarity index 100%
rename from xen/arch/arm/configs/tiny64.conf
rename to xen/arch/arm/configs/tiny64_defconfig
-- 
2.21.0

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

[Xen-devel] [PATCH v1 1/2] makefile: add support for *_defconfig targets

2019-05-14 Thread Volodymyr Babchuk

Ease up XEN configuration for non-standard builds, like
armv8 tiny config.

Signed-off-by: Volodymyr Babchuk 
---
 Makefile | 4 
 xen/Makefile | 3 +++
 2 files changed, 7 insertions(+)

diff --git a/Makefile b/Makefile
index 829ac63741..ef1ea44ef1 100644
--- a/Makefile
+++ b/Makefile
@@ -54,6 +54,10 @@ build: $(TARGS_BUILD)
 build-xen:
$(MAKE) -C xen build
 
+.PHONY: %_defconfig
+%_defconfig:
+   $(MAKE) -C xen $@
+
 .PHONY: build-tools
 build-tools: build-tools-public-headers
$(MAKE) -C tools build
diff --git a/xen/Makefile b/xen/Makefile
index 1fd8ad5116..3c7e423132 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -269,6 +269,9 @@ kconfig := silentoldconfig oldconfig config menuconfig 
defconfig \
 $(kconfig):
$(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH) 
SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)" $@
 
+%_defconfig:
+   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH) 
SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)" $@
+
 include/config/%.conf: include/config/auto.conf.cmd $(KCONFIG_CONFIG)
$(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH) 
SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)" silentoldconfig
 
-- 
2.21.0

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

[Xen-devel] [xen-unstable-smoke test] 136227: regressions - FAIL

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

Regressions :-(

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

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

version targeted for testing:
 xen  14e122fcc45d8a86e27be9663cbd7bcea1602b25
baseline version:
 xen  99bb45e684283b3bc621dbc99b1b93c856b4dd1c

Last test of basis   136179  2019-05-13 16:02:31 Z1 days
Testing same since   136227  2019-05-14 15:01:02 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Julien Grall 

jobs:
 build-arm64-xsm  pass
 build-amd64  fail
 build-armhf  pass
 build-amd64-libvirt  blocked 
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-amd64-libvirt blocked 



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

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

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

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


Not pushing.


commit 14e122fcc45d8a86e27be9663cbd7bcea1602b25
Author: Jan Beulich 
Date:   Tue May 14 16:22:17 2019 +0200

IOMMU: avoid NULL deref in iommu_lookup_page()

Luckily the function currently has no callers - it would have called
through NULL for both Arm and x86/AMD.

Signed-off-by: Jan Beulich 
Acked-by: Andrew Cooper 
Reviewed-by: Paul Durrant 

commit 05fe88fef20bafb2b62190b08f28211a1c4a1b12
Author: Jan Beulich 
Date:   Tue May 14 16:21:33 2019 +0200

x86/mm: subsume set_gpfn_from_mfn() into guest_physmap_add_page()

The two callers in common/memory.c currently call set_gpfn_from_mfn()
themselves, so moving the call into guest_physmap_add_page() helps
tidy their code.

The two callers in common/grant_table.c fail to make that call alongside
the one to guest_physmap_add_page(), so will actually get fixed by the
change.

Other (x86) callers are HVM only and are hence unaffected by a change
to the function's !paging_mode_translate() part.

Sadly this isn't enough yet to drop Arm's dummy macro, as there's one
more use in page_alloc.c.

Signed-off-by: Jan Beulich 
Acked-by: Julien Grall 
Reviewed-by: George Dunlap 

commit cf7de5d9543bba1076fe8ede57b0d314394c943a
Author: Jan Beulich 
Date:   Tue May 14 16:20:06 2019 +0200

x86/mm: make guest_physmap_add_entry() HVM-only

Lift its !paging_mode_translate() part into guest_physmap_add_page()
(which is what common code calls), eliminating the dummy use of a
(HVM-only really) P2M type in the PV case.

Suggested-by: George Dunlap 
Signed-off-by: Jan Beulich 
Reviewed-by: Wei Liu 
Reviewed-by: George Dunlap 

commit b81813dfb36fde9bd47c2e1b806e368cb9d6cbdb
Author: Jan Beulich 
Date:   Tue May 14 16:18:58 2019 +0200

x86/mm: short-circuit HVM-only mode flags when !HVM

#define-ing them to zero allows better code generation in this case,
and paves the way for more DCE, allowing to leave certain functions just
declared, but not defined.

Signed-off-by: Jan Beulich 
Reviewed-by: Wei Liu 
Reviewed-by: George Dunlap 
(qemu changes not included)

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

Re: [Xen-devel] [PATCH] gitlab-ci: allow specifying base and tip in build test

2019-05-14 Thread Doug Goldstein

On Tue, Apr 16, 2019 at 08:21:39AM +0100, Wei Liu wrote:
> We will soon provide this new capability to humans and automated
> systems.
> 
> The default behaviour is retained: tip and base are passed by Gitlab
> CI.
> 
> Signed-off-by: Wei Liu 

Swore I replied to this already. I apologize.

Acked-by: Doug Goldstein 

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

Re: [Xen-devel] [PATCH] x86/altp2m: move altp2m_get_effective_entry() under CONFIG_HVM

>>> On 14.05.19 at 18:13,  wrote:
> All its callers live inside #ifdef CONFIG_HVM sections.
> 
> Signed-off-by: Razvan Cojocaru 

Thanks!

> --- a/xen/include/asm-x86/p2m.h
> +++ b/xen/include/asm-x86/p2m.h
> @@ -514,6 +514,7 @@ static inline unsigned long mfn_to_gfn(struct domain *d, 
> mfn_t mfn)
>  return mfn_x(mfn);
>  }
>  
> +#ifdef CONFIG_HVM
>  #define AP2MGET_prepopulate true
>  #define AP2MGET_query false
>  
> @@ -525,6 +526,7 @@ static inline unsigned long mfn_to_gfn(struct domain *d, 
> mfn_t mfn)
>  int altp2m_get_effective_entry(struct p2m_domain *ap2m, gfn_t gfn, mfn_t 
> *mfn,
> p2m_type_t *t, p2m_access_t *a,
> bool prepopulate);
> +#endif
>  
>  /* Deadlock-avoidance scheme when calling get_gfn on different gfn's */
>  struct two_gfns {

I don't think these adjustments are strictly needed, but at least for
now they of course also don't hurt.

Jan



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

Re: [Xen-devel] [PATCH v2 1/2] KVM: Start populating /sys/hypervisor with KVM entries

2019-05-14 Thread Christian Borntraeger



On 14.05.19 18:09, Sironi, Filippo wrote:

>> Isnt kvm_para_available a function that is defined in the context of the HOST
>> and not of the guest?
> 
> No, kvm_para_available is defined in the guest context.
> On x86, it checks for the presence of the KVM CPUID leafs.
> 

Right you are, I mixed that up.


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

Re: [Xen-devel] [PATCH 3/5] iommu: move iommu_get_ops() into common code

2019-05-14 Thread Paul Durrant

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 13 May 2019 09:11
> To: Paul Durrant 
> Cc: Brian Woods ; Suravee Suthikulpanit 
> ; Julien
> Grall ; Andrew Cooper ; 
> Roger Pau Monne
> ; Wei Liu ; Kevin Tian 
> ; Stefano
> Stabellini ; xen-devel 
> 
> Subject: Re: [PATCH 3/5] iommu: move iommu_get_ops() into common code
> 
> >>> On 08.05.19 at 15:24,  wrote:
> > Currently x86 and ARM differ in their implementation for no good reason.
> > This patch moves the ARM variant of iommu_get/set_ops() helpers into
> > common code and modifies them so they deal with the __initconstrel
> > ops structures used by the x86 IOMMU vendor implementations (adding
> > __initconstrel to the SMMU code to bring it in line). Consequently, a lack
> > of init() method is now taken to mean uninitialized iommu_ops. Also, the
> > printk warning in iommu_set_ops() now becomes an ASSERT.
> 
> When having submitted the indirect call overhead reduction series
> including IOMMU changes for the first time, I was told that the Arm
> folks would like to retain the ability to eventually support
> heterogeneous IOMMUs (and hence I shouldn't provide patching
> infrastructure there). A single global iommu_[gs]et_ops() is sort of
> getting in the way of this as well, I think, and hence I'm not sure it
> is a desirable step to make this so far Arm-specific arrangement
> the general model. At least it would further complicate Arm side
> changes towards that (mid / long term?) goal.
>

Ok. Do you have any more information on what such an architecture would look 
like? I guess it is also conceivable that an x86 architecture might have 
slightly different IOMMU implementations (or at least quirks) for different PCI 
segments. So perhaps a global ops structure is not a good idea in the long run.

  Paul
 
> > --- a/xen/drivers/passthrough/iommu.c
> > +++ b/xen/drivers/passthrough/iommu.c
> > @@ -21,6 +21,21 @@
> >  #include 
> >  #include 
> >
> > +static struct iommu_ops __read_mostly iommu_ops;
> > +
> > +const struct iommu_ops *iommu_get_ops(void)
> > +{
> > +return _ops;
> > +}
> > +
> > +void __init iommu_set_ops(const struct iommu_ops *ops)
> > +{
> > +BUG_ON(!ops);
> > +
> > +ASSERT(!iommu_ops.init || iommu_ops.init == ops->init);
> > +iommu_ops = *ops;
> > +}
> 
> I realize that you merely move (and slightly re-arrange) what has
> been there, but now that I look at it again I think ops->init should
> also be verified to be non-NULL, or else installing such a set of
> hooks would effectively revert back to the "no hooks yet" state.
> 
> > @@ -33,11 +32,7 @@ int __init iommu_hardware_setup(void)
> >  if ( !iommu_init_ops )
> >  return -ENODEV;
> >
> > -if ( !iommu_ops.init )
> > -iommu_ops = *iommu_init_ops->ops;
> > -else
> > -/* x2apic setup may have previously initialised the struct. */
> > -ASSERT(iommu_ops.init == iommu_init_ops->ops->init);
> > +iommu_set_ops(iommu_init_ops->ops);
> 
> I was specifically asked to add the comment that you get rid of.
> While mentioning x2APIC in common code may no be appropriate,
> I'm sure this could be worded in a more general way and attached
> to the moved check.
> 
> Jan
> 


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

Re: [Xen-devel] [PATCH v6] x86/altp2m: Aggregate get entry and populate into common funcs


On 5/14/19 6:42 PM, Jan Beulich wrote:

On 23.04.19 at 16:30,  wrote:

--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -478,6 +478,43 @@ void p2m_unlock_and_tlb_flush(struct p2m_domain *p2m)
  mm_write_unlock(>lock);
  }
  
+int altp2m_get_effective_entry(struct p2m_domain *ap2m, gfn_t gfn, mfn_t *mfn,

+   p2m_type_t *t, p2m_access_t *a,
+   bool prepopulate)
+{
+*mfn = ap2m->get_entry(ap2m, gfn, t, a, 0, NULL, NULL);
+
+/* Check host p2m if no valid entry in alternate */
+if ( !mfn_valid(*mfn) && !p2m_is_hostp2m(ap2m) )
+{
+struct p2m_domain *hp2m = p2m_get_hostp2m(ap2m->domain);
+unsigned int page_order;
+int rc;
+
+*mfn = __get_gfn_type_access(hp2m, gfn_x(gfn), t, a,
+ P2M_ALLOC | P2M_UNSHARE, _order, 0);
+
+rc = -ESRCH;
+if ( !mfn_valid(*mfn) || *t != p2m_ram_rw )
+return rc;
+
+/* If this is a superpage, copy that first */
+if ( prepopulate && page_order != PAGE_ORDER_4K )
+{
+unsigned long mask = ~((1UL << page_order) - 1);
+gfn_t gfn_aligned = _gfn(gfn_x(gfn) & mask);
+mfn_t mfn_aligned = _mfn(mfn_x(*mfn) & mask);
+
+rc = ap2m->set_entry(ap2m, gfn_aligned, mfn_aligned, page_order, 
*t, *a, 1);
+if ( rc )
+return rc;
+}
+}
+
+return 0;
+}
+
+
  mfn_t __get_gfn_type_access(struct p2m_domain *p2m, unsigned long gfn_l,
  p2m_type_t *t, p2m_access_t *a, p2m_query_t q,
  unsigned int *page_order, bool_t locked)


May I ask how the placement of this function was chosen? It looks
as if all its callers live inside #ifdef CONFIG_HVM sections, just this
function doesn't (reportedly causing build issues together with
later changes).


I believe it's just an oversight. I've sent out a patch that hopefully 
fixes this in a satisfactory manner.



Thanks,
Razvan

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

[Xen-devel] [PATCH] x86/altp2m: move altp2m_get_effective_entry() under CONFIG_HVM

All its callers live inside #ifdef CONFIG_HVM sections.

Signed-off-by: Razvan Cojocaru 
---
 xen/arch/x86/mm/p2m.c | 72 +++
 xen/include/asm-x86/p2m.h |  2 ++
 2 files changed, 38 insertions(+), 36 deletions(-)

diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index cc6661e..57c5eed 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -478,42 +478,6 @@ void p2m_unlock_and_tlb_flush(struct p2m_domain *p2m)
 mm_write_unlock(>lock);
 }
 
-int altp2m_get_effective_entry(struct p2m_domain *ap2m, gfn_t gfn, mfn_t *mfn,
-   p2m_type_t *t, p2m_access_t *a,
-   bool prepopulate)
-{
-*mfn = ap2m->get_entry(ap2m, gfn, t, a, 0, NULL, NULL);
-
-/* Check host p2m if no valid entry in alternate */
-if ( !mfn_valid(*mfn) && !p2m_is_hostp2m(ap2m) )
-{
-struct p2m_domain *hp2m = p2m_get_hostp2m(ap2m->domain);
-unsigned int page_order;
-int rc;
-
-*mfn = __get_gfn_type_access(hp2m, gfn_x(gfn), t, a,
- P2M_ALLOC | P2M_UNSHARE, _order, 0);
-
-rc = -ESRCH;
-if ( !mfn_valid(*mfn) || *t != p2m_ram_rw )
-return rc;
-
-/* If this is a superpage, copy that first */
-if ( prepopulate && page_order != PAGE_ORDER_4K )
-{
-unsigned long mask = ~((1UL << page_order) - 1);
-gfn_t gfn_aligned = _gfn(gfn_x(gfn) & mask);
-mfn_t mfn_aligned = _mfn(mfn_x(*mfn) & mask);
-
-rc = ap2m->set_entry(ap2m, gfn_aligned, mfn_aligned, page_order, 
*t, *a, 1);
-if ( rc )
-return rc;
-}
-}
-
-return 0;
-}
-
 mfn_t __get_gfn_type_access(struct p2m_domain *p2m, unsigned long gfn_l,
 p2m_type_t *t, p2m_access_t *a, p2m_query_t q,
 unsigned int *page_order, bool_t locked)
@@ -2378,6 +2342,42 @@ int unmap_mmio_regions(struct domain *d,
 
 #ifdef CONFIG_HVM
 
+int altp2m_get_effective_entry(struct p2m_domain *ap2m, gfn_t gfn, mfn_t *mfn,
+   p2m_type_t *t, p2m_access_t *a,
+   bool prepopulate)
+{
+*mfn = ap2m->get_entry(ap2m, gfn, t, a, 0, NULL, NULL);
+
+/* Check host p2m if no valid entry in alternate */
+if ( !mfn_valid(*mfn) && !p2m_is_hostp2m(ap2m) )
+{
+struct p2m_domain *hp2m = p2m_get_hostp2m(ap2m->domain);
+unsigned int page_order;
+int rc;
+
+*mfn = __get_gfn_type_access(hp2m, gfn_x(gfn), t, a,
+ P2M_ALLOC | P2M_UNSHARE, _order, 0);
+
+rc = -ESRCH;
+if ( !mfn_valid(*mfn) || *t != p2m_ram_rw )
+return rc;
+
+/* If this is a superpage, copy that first */
+if ( prepopulate && page_order != PAGE_ORDER_4K )
+{
+unsigned long mask = ~((1UL << page_order) - 1);
+gfn_t gfn_aligned = _gfn(gfn_x(gfn) & mask);
+mfn_t mfn_aligned = _mfn(mfn_x(*mfn) & mask);
+
+rc = ap2m->set_entry(ap2m, gfn_aligned, mfn_aligned, page_order, 
*t, *a, 1);
+if ( rc )
+return rc;
+}
+}
+
+return 0;
+}
+
 void p2m_altp2m_check(struct vcpu *v, uint16_t idx)
 {
 if ( altp2m_active(v->domain) )
diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
index 2d0bda1..7e71bf0 100644
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -514,6 +514,7 @@ static inline unsigned long mfn_to_gfn(struct domain *d, 
mfn_t mfn)
 return mfn_x(mfn);
 }
 
+#ifdef CONFIG_HVM
 #define AP2MGET_prepopulate true
 #define AP2MGET_query false
 
@@ -525,6 +526,7 @@ static inline unsigned long mfn_to_gfn(struct domain *d, 
mfn_t mfn)
 int altp2m_get_effective_entry(struct p2m_domain *ap2m, gfn_t gfn, mfn_t *mfn,
p2m_type_t *t, p2m_access_t *a,
bool prepopulate);
+#endif
 
 /* Deadlock-avoidance scheme when calling get_gfn on different gfn's */
 struct two_gfns {
-- 
2.7.4


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

Re: [Xen-devel] [PATCH 2/5] iommu / x86: move call to scan_pci_devices() out of vendor code

2019-05-14 Thread Paul Durrant

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 13 May 2019 08:36
> To: Paul Durrant 
> Cc: Brian Woods ; Suravee Suthikulpanit 
> ; Andrew
> Cooper ; Roger Pau Monne ; 
> Wei Liu
> ; Kevin Tian ; xen-devel 
> 
> Subject: Re: [PATCH 2/5] iommu / x86: move call to scan_pci_devices() out of 
> vendor code
> 
> >>> On 08.05.19 at 15:24,  wrote:
> > It's not vendor specific so it shouldn't really be there.
> 
> Perhaps, but this needs better justification:
> 
> > --- a/xen/drivers/passthrough/vtd/iommu.c
> > +++ b/xen/drivers/passthrough/vtd/iommu.c
> > @@ -2372,10 +2372,6 @@ static int __init vtd_setup(void)
> >  P(iommu_hap_pt_share, "Shared EPT tables");
> >  #undef P
> >
> > -ret = scan_pci_devices();
> > -if ( ret )
> > -goto error;
> > -
> >  ret = init_vtd_hw();
> 
> Even after some looking around, it's not obvious to me that the latter
> call doesn't depend on PCI devices being known, more specifically
> segment 0's bus2bridge[] having been filled. Nor can I tell whether
> there would be some noticeable misbehavior (prior to any guests
> starting) if there was a dependency and it got broken by the re-
> ordering.

I don't see any dependency but the code is somewhat tangled. Perhaps it would 
be better to build the PCI topology *before* IOMMU init and then iterate over 
the the devices after init to do the group assignment. I certainly can't see 
anything in the scan as it stands that would need the IOMMU to have been 
initialized.

  Paul

> 
> Jan
> 


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

Re: [Xen-devel] [PATCH v2 1/2] KVM: Start populating /sys/hypervisor with KVM entries

2019-05-14 Thread Sironi, Filippo



> On 14. May 2019, at 17:26, Christian Borntraeger  
> wrote:
> 
> 
> 
> On 14.05.19 17:16, Filippo Sironi wrote:
>> Start populating /sys/hypervisor with KVM entries when we're running on
>> KVM. This is to replicate functionality that's available when we're
>> running on Xen.
>> 
>> Start with /sys/hypervisor/uuid, which users prefer over
>> /sys/devices/virtual/dmi/id/product_uuid as a way to recognize a virtual
>> machine, since it's also available when running on Xen HVM and on Xen PV
>> and, on top of that doesn't require root privileges by default.
>> Let's create arch-specific hooks so that different architectures can
>> provide different implementations.
>> 
>> Signed-off-by: Filippo Sironi 
>> ---
>> v2:
>> * move the retrieval of the VM UUID out of uuid_show and into
>>  kvm_para_get_uuid, which is a weak function that can be overwritten
>> 
>> drivers/Kconfig  |  2 ++
>> drivers/Makefile |  2 ++
>> drivers/kvm/Kconfig  | 14 ++
>> drivers/kvm/Makefile |  1 +
>> drivers/kvm/sys-hypervisor.c | 30 ++
>> 5 files changed, 49 insertions(+)
>> create mode 100644 drivers/kvm/Kconfig
>> create mode 100644 drivers/kvm/Makefile
>> create mode 100644 drivers/kvm/sys-hypervisor.c
>> 
>> diff --git a/drivers/Kconfig b/drivers/Kconfig
>> index 45f9decb9848..90eb835fe951 100644
>> --- a/drivers/Kconfig
>> +++ b/drivers/Kconfig
>> @@ -146,6 +146,8 @@ source "drivers/hv/Kconfig"
>> 
>> source "drivers/xen/Kconfig"
>> 
>> +source "drivers/kvm/Kconfig"
>> +
>> source "drivers/staging/Kconfig"
>> 
>> source "drivers/platform/Kconfig"
>> diff --git a/drivers/Makefile b/drivers/Makefile
>> index c61cde554340..79cc92a3f6bf 100644
>> --- a/drivers/Makefile
>> +++ b/drivers/Makefile
>> @@ -44,6 +44,8 @@ obj-y  += soc/
>> obj-$(CONFIG_VIRTIO) += virtio/
>> obj-$(CONFIG_XEN)+= xen/
>> 
>> +obj-$(CONFIG_KVM_GUEST) += kvm/
>> +
>> # regulators early, since some subsystems rely on them to initialize
>> obj-$(CONFIG_REGULATOR)  += regulator/
>> 
>> diff --git a/drivers/kvm/Kconfig b/drivers/kvm/Kconfig
>> new file mode 100644
>> index ..3fc041df7c11
>> --- /dev/null
>> +++ b/drivers/kvm/Kconfig
>> @@ -0,0 +1,14 @@
>> +menu "KVM driver support"
>> +depends on KVM_GUEST
>> +
>> +config KVM_SYS_HYPERVISOR
>> +bool "Create KVM entries under /sys/hypervisor"
>> +depends on SYSFS
>> +select SYS_HYPERVISOR
>> +default y
>> +help
>> +  Create KVM entries under /sys/hypervisor (e.g., uuid). When 
>> running
>> +  native or on another hypervisor, /sys/hypervisor may still be
>> +  present, but it will have no KVM entries.
>> +
>> +endmenu
>> diff --git a/drivers/kvm/Makefile b/drivers/kvm/Makefile
>> new file mode 100644
>> index ..73a43fc994b9
>> --- /dev/null
>> +++ b/drivers/kvm/Makefile
>> @@ -0,0 +1 @@
>> +obj-$(CONFIG_KVM_SYS_HYPERVISOR) += sys-hypervisor.o
>> diff --git a/drivers/kvm/sys-hypervisor.c b/drivers/kvm/sys-hypervisor.c
>> new file mode 100644
>> index ..43b1d1a09807
>> --- /dev/null
>> +++ b/drivers/kvm/sys-hypervisor.c
>> @@ -0,0 +1,30 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +
>> +#include 
>> +
>> +#include 
>> +#include 
>> +
>> +__weak const char *kvm_para_get_uuid(void)
>> +{
>> +return NULL;
>> +}
>> +
>> +static ssize_t uuid_show(struct kobject *obj,
>> + struct kobj_attribute *attr,
>> + char *buf)
>> +{
>> +const char *uuid = kvm_para_get_uuid();
> 
> I would prefer to have kvm_para_get_uuid return a uuid_t
> but char * will probably work out as well.

Let me give this a quick spin.

>> +return sprintf(buf, "%s\n", uuid);
>> +}
>> +
>> +static struct kobj_attribute uuid = __ATTR_RO(uuid);
>> +
>> +static int __init uuid_init(void)
>> +{
>> +if (!kvm_para_available())
> 
> Isnt kvm_para_available a function that is defined in the context of the HOST
> and not of the guest?

No, kvm_para_available is defined in the guest context.
On x86, it checks for the presence of the KVM CPUID leafs.

>> +return 0;
>> +return sysfs_create_file(hypervisor_kobj, );
>> +}
>> +
>> +device_initcall(uuid_init);




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrer: Christian Schlaeger, Ralf Herbrich
Ust-ID: DE 289 237 879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B



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

[Xen-devel] xen/arm: potential bug in advance_pc

2019-05-14 Thread Lukas Jünger


Hello all,

in the function advance_pc in xen/arch/arm/traps.c in line 1655,1656 you 
can find the following code:


1655 BUG_ON( (!psr_mode_is_32bit(cpsr)||!(cpsr_THUMB))
1656 && (cpsr_IT_MASK) );

This code seems to check that we are not running in thumb mode and that 
the PSR_IT_MASK is not set.
On ARMv8.5-BTI systems bits [11:10] of spsr_el2 indicate the BTYPE (see 
https://developer.arm.com/docs/ddi0595/b/aarch64-system-registers/spsr_el2).
If an exception is taken in the guest (e.g. write to system register) 
from AArch64 state these bits might be set.
The PSR_IT_MASK for thumb mode overlaps with these bits and BUG_ON is 
executed.

This seems to be a bug.
Is it really necessary to check the PSR_IT_MASK for BUG_ON here?
Why is the execution mode checked twice with psr_mode_is_32bit and 
cpsr_THUMB, as they seem to do the same thing?
If PSR_IT_MASK does not need to be checked for BUG_ON, the if statement 
in the following line should check for thumb mode again, right?


Best regards,
Lukas



smime.p7s
Description: S/MIME Cryptographic Signature
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v6] x86/altp2m: Aggregate get entry and populate into common funcs

>>> On 23.04.19 at 16:30,  wrote:
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -478,6 +478,43 @@ void p2m_unlock_and_tlb_flush(struct p2m_domain *p2m)
>  mm_write_unlock(>lock);
>  }
>  
> +int altp2m_get_effective_entry(struct p2m_domain *ap2m, gfn_t gfn, mfn_t 
> *mfn,
> +   p2m_type_t *t, p2m_access_t *a,
> +   bool prepopulate)
> +{
> +*mfn = ap2m->get_entry(ap2m, gfn, t, a, 0, NULL, NULL);
> +
> +/* Check host p2m if no valid entry in alternate */
> +if ( !mfn_valid(*mfn) && !p2m_is_hostp2m(ap2m) )
> +{
> +struct p2m_domain *hp2m = p2m_get_hostp2m(ap2m->domain);
> +unsigned int page_order;
> +int rc;
> +
> +*mfn = __get_gfn_type_access(hp2m, gfn_x(gfn), t, a,
> + P2M_ALLOC | P2M_UNSHARE, _order, 
> 0);
> +
> +rc = -ESRCH;
> +if ( !mfn_valid(*mfn) || *t != p2m_ram_rw )
> +return rc;
> +
> +/* If this is a superpage, copy that first */
> +if ( prepopulate && page_order != PAGE_ORDER_4K )
> +{
> +unsigned long mask = ~((1UL << page_order) - 1);
> +gfn_t gfn_aligned = _gfn(gfn_x(gfn) & mask);
> +mfn_t mfn_aligned = _mfn(mfn_x(*mfn) & mask);
> +
> +rc = ap2m->set_entry(ap2m, gfn_aligned, mfn_aligned, page_order, 
> *t, *a, 1);
> +if ( rc )
> +return rc;
> +}
> +}
> +
> +return 0;
> +}
> +
> +
>  mfn_t __get_gfn_type_access(struct p2m_domain *p2m, unsigned long gfn_l,
>  p2m_type_t *t, p2m_access_t *a, p2m_query_t q,
>  unsigned int *page_order, bool_t locked)

May I ask how the placement of this function was chosen? It looks
as if all its callers live inside #ifdef CONFIG_HVM sections, just this
function doesn't (reportedly causing build issues together with
later changes).

Jan



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

Re: [Xen-devel] [PATCH v5] libxl: fix migration of PV and PVH domUs with and without qemu

On Tue, May 14, 2019 at 04:44:19PM +0200, Olaf Hering wrote:
> Am Tue, 14 May 2019 15:38:55 +0100
> schrieb Wei Liu :
> 
> > > While it is easy for the resume path, doing the same in the suspend path
> > > needs more changes. libxl__domain_suspend_device_model would need to 
> > > receive
> > > the callback and set it if a device model is active.  
> > 
> > What do you mean here? Can't you handle the NONE case just like you do
> > in the resume function?
> 
> It means calling libxl__domain_suspend_device_model unconditionally, and
> let that function decide what to do. Maybe there is no downside to set the
> callback unconditionally, I will check that.

Sure. In the meantime I will apply this patch at some point to fix the
bug first.

Wei.

> 
> Olaf



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

[Xen-devel] [PATCH v2 1/2] KVM: Start populating /sys/hypervisor with KVM entries

2019-05-14 Thread Filippo Sironi

Start populating /sys/hypervisor with KVM entries when we're running on
KVM. This is to replicate functionality that's available when we're
running on Xen.

Start with /sys/hypervisor/uuid, which users prefer over
/sys/devices/virtual/dmi/id/product_uuid as a way to recognize a virtual
machine, since it's also available when running on Xen HVM and on Xen PV
and, on top of that doesn't require root privileges by default.
Let's create arch-specific hooks so that different architectures can
provide different implementations.

Signed-off-by: Filippo Sironi 
---
v2:
* move the retrieval of the VM UUID out of uuid_show and into
  kvm_para_get_uuid, which is a weak function that can be overwritten

 drivers/Kconfig  |  2 ++
 drivers/Makefile |  2 ++
 drivers/kvm/Kconfig  | 14 ++
 drivers/kvm/Makefile |  1 +
 drivers/kvm/sys-hypervisor.c | 30 ++
 5 files changed, 49 insertions(+)
 create mode 100644 drivers/kvm/Kconfig
 create mode 100644 drivers/kvm/Makefile
 create mode 100644 drivers/kvm/sys-hypervisor.c

diff --git a/drivers/Kconfig b/drivers/Kconfig
index 45f9decb9848..90eb835fe951 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -146,6 +146,8 @@ source "drivers/hv/Kconfig"
 
 source "drivers/xen/Kconfig"
 
+source "drivers/kvm/Kconfig"
+
 source "drivers/staging/Kconfig"
 
 source "drivers/platform/Kconfig"
diff --git a/drivers/Makefile b/drivers/Makefile
index c61cde554340..79cc92a3f6bf 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -44,6 +44,8 @@ obj-y += soc/
 obj-$(CONFIG_VIRTIO)   += virtio/
 obj-$(CONFIG_XEN)  += xen/
 
+obj-$(CONFIG_KVM_GUEST)+= kvm/
+
 # regulators early, since some subsystems rely on them to initialize
 obj-$(CONFIG_REGULATOR)+= regulator/
 
diff --git a/drivers/kvm/Kconfig b/drivers/kvm/Kconfig
new file mode 100644
index ..3fc041df7c11
--- /dev/null
+++ b/drivers/kvm/Kconfig
@@ -0,0 +1,14 @@
+menu "KVM driver support"
+depends on KVM_GUEST
+
+config KVM_SYS_HYPERVISOR
+bool "Create KVM entries under /sys/hypervisor"
+depends on SYSFS
+select SYS_HYPERVISOR
+default y
+help
+  Create KVM entries under /sys/hypervisor (e.g., uuid). When running
+  native or on another hypervisor, /sys/hypervisor may still be
+  present, but it will have no KVM entries.
+
+endmenu
diff --git a/drivers/kvm/Makefile b/drivers/kvm/Makefile
new file mode 100644
index ..73a43fc994b9
--- /dev/null
+++ b/drivers/kvm/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_KVM_SYS_HYPERVISOR) += sys-hypervisor.o
diff --git a/drivers/kvm/sys-hypervisor.c b/drivers/kvm/sys-hypervisor.c
new file mode 100644
index ..43b1d1a09807
--- /dev/null
+++ b/drivers/kvm/sys-hypervisor.c
@@ -0,0 +1,30 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#include 
+
+#include 
+#include 
+
+__weak const char *kvm_para_get_uuid(void)
+{
+   return NULL;
+}
+
+static ssize_t uuid_show(struct kobject *obj,
+struct kobj_attribute *attr,
+char *buf)
+{
+   const char *uuid = kvm_para_get_uuid();
+   return sprintf(buf, "%s\n", uuid);
+}
+
+static struct kobj_attribute uuid = __ATTR_RO(uuid);
+
+static int __init uuid_init(void)
+{
+   if (!kvm_para_available())
+   return 0;
+   return sysfs_create_file(hypervisor_kobj, );
+}
+
+device_initcall(uuid_init);
-- 
2.7.4


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

[Xen-devel] KVM: Start populating /sys/hypervisor with KVM entries

2019-05-14 Thread Filippo Sironi

Long-time Xen HVM and Xen PV users are missing /sys/hypervisor entries when
moving to KVM.  One report is about getting the VM UUID.  The VM UUID can
already be retrieved using /sys/devices/virtual/dmi/id/product_uuid.  This has
two downsides: (1) it requires root privileges and (2) it is only available on
KVM and Xen HVM.

By exposing /sys/hypervisor/uuid when running on KVM as well, we provide an
interface that's functional for KVM, Xen HVM, and Xen PV.  Let's do so by
providing arch-specific hooks so that different architectures can implement the
hooks in different ways.

Further work can be done by consolidating the creation of the basic
/sys/hypervisor across hypervisors.

Filippo Sironi (2):
  KVM: Start populating /sys/hypervisor with KVM entries
  KVM: x86: Implement the arch-specific hook to report the VM UUID


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

[Xen-devel] [PATCH v2 2/2] KVM: x86: Implement the arch-specific hook to report the VM UUID

2019-05-14 Thread Filippo Sironi

On x86, we report the UUID in DMI System Information (i.e., DMI Type 1)
as VM UUID.

Signed-off-by: Filippo Sironi 
---
 arch/x86/kernel/kvm.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 5c93a65ee1e5..441cab08a09d 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -694,6 +695,12 @@ bool kvm_para_available(void)
 }
 EXPORT_SYMBOL_GPL(kvm_para_available);
 
+const char *kvm_para_get_uuid(void)
+{
+   return dmi_get_system_info(DMI_PRODUCT_UUID);
+}
+EXPORT_SYMBOL_GPL(kvm_para_get_uuid);
+
 unsigned int kvm_arch_para_features(void)
 {
return cpuid_eax(kvm_cpuid_base() | KVM_CPUID_FEATURES);
-- 
2.7.4


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

Re: [Xen-devel] [PATCH v2 1/2] KVM: Start populating /sys/hypervisor with KVM entries

2019-05-14 Thread Christian Borntraeger



On 14.05.19 17:16, Filippo Sironi wrote:
> Start populating /sys/hypervisor with KVM entries when we're running on
> KVM. This is to replicate functionality that's available when we're
> running on Xen.
> 
> Start with /sys/hypervisor/uuid, which users prefer over
> /sys/devices/virtual/dmi/id/product_uuid as a way to recognize a virtual
> machine, since it's also available when running on Xen HVM and on Xen PV
> and, on top of that doesn't require root privileges by default.
> Let's create arch-specific hooks so that different architectures can
> provide different implementations.
> 
> Signed-off-by: Filippo Sironi 
> ---
> v2:
> * move the retrieval of the VM UUID out of uuid_show and into
>   kvm_para_get_uuid, which is a weak function that can be overwritten
> 
>  drivers/Kconfig  |  2 ++
>  drivers/Makefile |  2 ++
>  drivers/kvm/Kconfig  | 14 ++
>  drivers/kvm/Makefile |  1 +
>  drivers/kvm/sys-hypervisor.c | 30 ++
>  5 files changed, 49 insertions(+)
>  create mode 100644 drivers/kvm/Kconfig
>  create mode 100644 drivers/kvm/Makefile
>  create mode 100644 drivers/kvm/sys-hypervisor.c
> 
> diff --git a/drivers/Kconfig b/drivers/Kconfig
> index 45f9decb9848..90eb835fe951 100644
> --- a/drivers/Kconfig
> +++ b/drivers/Kconfig
> @@ -146,6 +146,8 @@ source "drivers/hv/Kconfig"
>  
>  source "drivers/xen/Kconfig"
>  
> +source "drivers/kvm/Kconfig"
> +
>  source "drivers/staging/Kconfig"
>  
>  source "drivers/platform/Kconfig"
> diff --git a/drivers/Makefile b/drivers/Makefile
> index c61cde554340..79cc92a3f6bf 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -44,6 +44,8 @@ obj-y   += soc/
>  obj-$(CONFIG_VIRTIO) += virtio/
>  obj-$(CONFIG_XEN)+= xen/
>  
> +obj-$(CONFIG_KVM_GUEST)  += kvm/
> +
>  # regulators early, since some subsystems rely on them to initialize
>  obj-$(CONFIG_REGULATOR)  += regulator/
>  
> diff --git a/drivers/kvm/Kconfig b/drivers/kvm/Kconfig
> new file mode 100644
> index ..3fc041df7c11
> --- /dev/null
> +++ b/drivers/kvm/Kconfig
> @@ -0,0 +1,14 @@
> +menu "KVM driver support"
> +depends on KVM_GUEST
> +
> +config KVM_SYS_HYPERVISOR
> +bool "Create KVM entries under /sys/hypervisor"
> +depends on SYSFS
> +select SYS_HYPERVISOR
> +default y
> +help
> +  Create KVM entries under /sys/hypervisor (e.g., uuid). When running
> +  native or on another hypervisor, /sys/hypervisor may still be
> +  present, but it will have no KVM entries.
> +
> +endmenu
> diff --git a/drivers/kvm/Makefile b/drivers/kvm/Makefile
> new file mode 100644
> index ..73a43fc994b9
> --- /dev/null
> +++ b/drivers/kvm/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_KVM_SYS_HYPERVISOR) += sys-hypervisor.o
> diff --git a/drivers/kvm/sys-hypervisor.c b/drivers/kvm/sys-hypervisor.c
> new file mode 100644
> index ..43b1d1a09807
> --- /dev/null
> +++ b/drivers/kvm/sys-hypervisor.c
> @@ -0,0 +1,30 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +
> +#include 
> +
> +#include 
> +#include 
> +
> +__weak const char *kvm_para_get_uuid(void)
> +{
> + return NULL;
> +}
> +
> +static ssize_t uuid_show(struct kobject *obj,
> +  struct kobj_attribute *attr,
> +  char *buf)
> +{
> + const char *uuid = kvm_para_get_uuid();

I would prefer to have kvm_para_get_uuid return a uuid_t
but char * will probably work out as well.


> + return sprintf(buf, "%s\n", uuid);
> +}
> +
> +static struct kobj_attribute uuid = __ATTR_RO(uuid);
> +
> +static int __init uuid_init(void)
> +{
> + if (!kvm_para_available())

Isnt kvm_para_available a function that is defined in the context of the HOST
and not of the guest?

> + return 0;
> + return sysfs_create_file(hypervisor_kobj, );
> +}
> +
> +device_initcall(uuid_init);
> 


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

Re: [Xen-devel] [PATCH v5] libxl: fix migration of PV and PVH domUs with and without qemu

2019-05-14 Thread Olaf Hering

Am Tue, 14 May 2019 15:38:55 +0100
schrieb Wei Liu :

> > While it is easy for the resume path, doing the same in the suspend path
> > needs more changes. libxl__domain_suspend_device_model would need to receive
> > the callback and set it if a device model is active.  
> 
> What do you mean here? Can't you handle the NONE case just like you do
> in the resume function?

It means calling libxl__domain_suspend_device_model unconditionally, and
let that function decide what to do. Maybe there is no downside to set the
callback unconditionally, I will check that.

Olaf


pgpz6BYSJmSGx.pgp
Description: Digitale Signatur von OpenPGP
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v5] libxl: fix migration of PV and PVH domUs with and without qemu

On Tue, May 14, 2019 at 10:14:52AM +0200, Olaf Hering wrote:
> Am Tue, 14 May 2019 10:05:58 +0200
> schrieb Olaf Hering :
> 
> > @@ -459,7 +461,9 @@ int libxl__domain_resume(libxl__gc *gc, uint32_t domid, 
> > int suspend_cancel)
> >  goto out;
> >  }
> >  
> > -if (type == LIBXL_DOMAIN_TYPE_HVM) {
> > +if (type == LIBXL_DOMAIN_TYPE_HVM ||
> > +libxl__device_model_version_running(gc, domid) ==
> > +LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
> >  rc = libxl__domain_resume_device_model(gc, domid);
> >  if (rc) {
> >  LOGD(ERROR, domid, "failed to resume device model:%d", rc);
> 
> I think this could be done like that instead, so that 
> libxl__device_model_version_running
> is called just once:
> 
> --- a/tools/libxl/libxl_dom_suspend.c
> +++ b/tools/libxl/libxl_dom_suspend.c
> @@ -444,6 +444,8 @@ int libxl__domain_resume_device_model(libxl__gc *gc, 
> uint32_t domid)
>  if (libxl__qmp_resume(gc, domid))
>  return ERROR_FAIL;
>  break;
> +case LIBXL_DEVICE_MODEL_VERSION_NONE:
> +break;
>  default:
>  return ERROR_INVAL;
>  }
> @@ -461,14 +463,10 @@ int libxl__domain_resume(libxl__gc *gc, uint32_t domid, 
> int suspend_cancel)
>  goto out;
>  }
>  
> -if (type == LIBXL_DOMAIN_TYPE_HVM ||
> -libxl__device_model_version_running(gc, domid) ==
> -LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
> -rc = libxl__domain_resume_device_model(gc, domid);
> -if (rc) {
> -LOGD(ERROR, domid, "failed to resume device model:%d", rc);
> -goto out;
> -}
> +rc = libxl__domain_resume_device_model(gc, domid);
> +if (rc) {
> +LOGD(ERROR, domid, "failed to resume device model:%d", rc);
> +goto out;
>  }
>  
>  if (xc_domain_resume(CTX->xch, domid, suspend_cancel)) {
> 

Yeah, from the look of it this is definitely better.

> 
> While it is easy for the resume path, doing the same in the suspend path
> needs more changes. libxl__domain_suspend_device_model would need to receive
> the callback and set it if a device model is active.

What do you mean here? Can't you handle the NONE case just like you do
in the resume function?

Wei.

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

Re: [Xen-devel] [PATCH v2 2/3] README: document requirement about python

>>> On 14.05.19 at 16:22,  wrote:
> Provide information on what is expected from the build system
> regarding python.
> 
> Signed-off-by: Wei Liu 

FWIW
Acked-by: Jan Beulich 



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

Re: [Xen-devel] [PATCH v1] libxl: add helper function to set device_model_version

On Tue, May 14, 2019 at 12:39:07PM +0200, Roger Pau Monné wrote:
> On Tue, May 14, 2019 at 12:31:18PM +0200, Olaf Hering wrote:
> > Am Tue, 14 May 2019 12:18:56 +0200
> > schrieb Roger Pau Monné :
> > 
> > > Why is it not fine to set the device model version in
> > > libxl__domain_build_info_setdefault?
> > 
> > Because it receives just build_info, which lacks all the data to decide
> > if a device type needs a device model or not.
> 
> Gah, thanks. Could you please add this to the commit message? Or else
> it's likely I will ask again.
> 
> With that:
> 
> Reviewed-by: Roger Pau Monné 

Acked-by: Wei Liu 

Olaf, if you can provide me with an updated version of the commit
message I can fold that in while committing. No need to resend this
patch.

Wei.

> 
> Roger.

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

[Xen-devel] [PATCH v2 3/3] INSTALL: remove duplicate sentence

The same sentence is repeated in the next paragraph.

Signed-off-by: Wei Liu 
---
 INSTALL | 1 -
 1 file changed, 1 deletion(-)

diff --git a/INSTALL b/INSTALL
index 9aa9ebdddc..1665ddd6a4 100644
--- a/INSTALL
+++ b/INSTALL
@@ -225,7 +225,6 @@ XEN_BUILD_TIME=hh:mm:ss
 SMBIOS_REL_DATE=mm/dd/
 VGABIOS_REL_DATE="dd Mon "
 
-During tools build external repos will be cloned into the source tree.
 This variable can be used to point to a different git binary to be used.
 GIT=
 
-- 
2.20.1


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

[Xen-devel] [PATCH v2 0/3] Misc patches

Wei Liu (3):
  gitignore: ignore .vscode directory
  README: document requirement about python
  INSTALL: remove duplicate sentence

 .gitignore | 1 +
 INSTALL| 1 -
 README | 7 +++
 3 files changed, 8 insertions(+), 1 deletion(-)

-- 
2.20.1


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

[Xen-devel] [PATCH v2 2/3] README: document requirement about python

Provide information on what is expected from the build system
regarding python.

Signed-off-by: Wei Liu 
---
 README | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/README b/README
index 23e4f7c3dc..26d44cf7c1 100644
--- a/README
+++ b/README
@@ -181,6 +181,13 @@ Various tools, such as pygrub, have the following runtime 
dependencies:
   URL:http://www.python.org/
   Debian: python
 
+Note that the build system expects `python` to be available. If your system
+only has `python2` or `python3` but not `python` (as in Linux From Scratch),
+you will need to create a symlink for it, or specify PYTHON= when invoking
+make, like (note the position of PYTHON= matters):
+
+# make PYTHON=/usr/bin/python3
+
 Intel(R) Trusted Execution Technology Support
 =
 
-- 
2.20.1


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

[Xen-devel] [PATCH v2 1/3] gitignore: ignore .vscode directory

The directory is created by Visual Studio Code editor to store its
local state.

Signed-off-by: Wei Liu 
---
 .gitignore | 1 +
 1 file changed, 1 insertion(+)

diff --git a/.gitignore b/.gitignore
index 26bc583f74..3822bb75ba 100644
--- a/.gitignore
+++ b/.gitignore
@@ -30,6 +30,7 @@ cscope.out
 cscope.po.out
 .config
 .vimrc
+.vscode
 
 dist
 stubdom/*.tar.gz
-- 
2.20.1


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

Re: [Xen-devel] [PATCH v1] x86/hvm: Generic instruction re-execution mechanism for execute faults




On 5/14/19 5:16 PM, Jan Beulich wrote:

On 14.05.19 at 15:47,  wrote:

Mem event emulation failed (5): d5v0 32bit @ 001b:6d96efff -> c5 f9 f5
05 c0 be ad 6d c5 e1 fe 1d a0 20 af 6d

Looking at the source code, the emulator does appear to support
vpmaddwd, however only for EVEX:

http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/x86/x86_emulate/x
86_emulate.c;h=032995ea586aa7dd90a1953b6ded656436652049;hb=refs/heads/staging
#l6696

whereas our fail case uses VEX.

This may be in the works in the aforementioned series, but is
legitimately unsupported in 4.13 staging.


Hmm, interesting. The origin of the encoding is at MMX times,
which means it's more than just VPMADDWD that's missing, and
it's been an omission back in the MMX/SSE2 series then. That's
a genuine oversight, and in the light of this I'd like to apologize
for my unfriendly initial reaction. I'll see about getting this fixed.
(It would have helped if you had shared the encoding right away,
since the mnemonic and operands are now often insufficient.)


No problem at all. Indeed, sharing the encoding would have cleared 
things up faster.



Thanks,
Razvan

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

Re: [Xen-devel] [PATCH v1] x86/hvm: Generic instruction re-execution mechanism for execute faults

>>> On 14.05.19 at 15:47,  wrote:
> Mem event emulation failed (5): d5v0 32bit @ 001b:6d96efff -> c5 f9 f5 
> 05 c0 be ad 6d c5 e1 fe 1d a0 20 af 6d
> 
> Looking at the source code, the emulator does appear to support 
> vpmaddwd, however only for EVEX:
> 
> http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/x86/x86_emulate/x 
> 86_emulate.c;h=032995ea586aa7dd90a1953b6ded656436652049;hb=refs/heads/staging
> #l6696
> 
> whereas our fail case uses VEX.
> 
> This may be in the works in the aforementioned series, but is 
> legitimately unsupported in 4.13 staging.

Hmm, interesting. The origin of the encoding is at MMX times,
which means it's more than just VPMADDWD that's missing, and
it's been an omission back in the MMX/SSE2 series then. That's
a genuine oversight, and in the light of this I'd like to apologize
for my unfriendly initial reaction. I'll see about getting this fixed.
(It would have helped if you had shared the encoding right away,
since the mnemonic and operands are now often insufficient.)

Jan

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

Re: [Xen-devel] Criteria / validation proposal: drop Xen

2019-05-14 Thread M A Young

On Tue, 14 May 2019, Steven Haigh wrote:

> The final fix would be figuring out why pygrub currently boots the *second*
> entry in the resulting grub.cfg - unlike how F29 worked. This may be either a
> fix on the grub2-mkconfig or pygrub side - I'm not quite sure yet. This would
> likely restore functionality completely. At least until something else more
> suitable is done?

The answer to why is easy. pygrub just ignores "if" instructions and there 
is a
set default=1
line in an if clause from /etc/grub.d/08_fallback_counting so it 
defaults to the second entry as they are numbered from 0.

Michael Young

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

Re: [Xen-devel] [PATCH v2] pvshim: make PV shim build selectable from configure

On Tue, May 14, 2019 at 03:59:22PM +0200, Roger Pau Monne wrote:
> So a user can decide whether to compile a PV shim as part of the tools
> build. Note that the default behavior is preserved, which is to build
> a PV shim when the target or host (if target is unset) architecture is
> 64bit x86.
> 
> Requested-by: Olaf Hering 
> Signed-off-by: Roger Pau Monné 
> ---
> NOTE: run autogen.sh after applying.

Noted.

Acked-by: Wei Liu 

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

[Xen-devel] [PATCH v2] pvshim: make PV shim build selectable from configure

2019-05-14 Thread Roger Pau Monne

So a user can decide whether to compile a PV shim as part of the tools
build. Note that the default behavior is preserved, which is to build
a PV shim when the target or host (if target is unset) architecture is
64bit x86.

Requested-by: Olaf Hering 
Signed-off-by: Roger Pau Monné 
---
NOTE: run autogen.sh after applying.
---
Cc: Ian Jackson 
Cc: Wei Liu 
---
Changes since v1:
 - Only enable by default on x86_64, like the previous behavior.
 - Fallback to use host_cpu if target_cpu is empty.
---
 config/Tools.mk.in  |  2 ++
 tools/configure.ac  | 13 +
 tools/firmware/Makefile |  4 
 3 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/config/Tools.mk.in b/config/Tools.mk.in
index 98245f63c9..84ddb1a542 100644
--- a/config/Tools.mk.in
+++ b/config/Tools.mk.in
@@ -75,3 +75,5 @@ TINFO_LIBS  := @TINFO_LIBS@
 ARGP_LDFLAGS:= @argp_ldflags@
 
 FILE_OFFSET_BITS:= @FILE_OFFSET_BITS@
+
+CONFIG_PV_SHIM  := @pvshim@
diff --git a/tools/configure.ac b/tools/configure.ac
index c9fd69ddfa..fcf282e74e 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -492,4 +492,17 @@ AC_ARG_ENABLE([9pfs],
 
 AC_SUBST(ninepfs)
 
+AC_ARG_ENABLE([pvshim],
+AS_HELP_STRING([--disable-pvshim],
+   [Disable pvshim build (enabled by default on 64bit x86)]),
+[AS_IF([test "x$enable_pvshim" = "xno"], [pvshim=n], [pvshim=y])], [
+cpu=`test -z "$target_cpu" && echo "$host_cpu" || echo "$target_cpu"`
+case "$cpu" in
+x86_64)
+   pvshim="y";;
+*) pvshim="n";;
+esac
+])
+AC_SUBST(pvshim)
+
 AC_OUTPUT()
diff --git a/tools/firmware/Makefile b/tools/firmware/Makefile
index cf304fc578..809a5fd025 100644
--- a/tools/firmware/Makefile
+++ b/tools/firmware/Makefile
@@ -1,10 +1,6 @@
 XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
-ifneq ($(XEN_TARGET_ARCH),x86_32)
-CONFIG_PV_SHIM := y
-endif
-
 # hvmloader is a 32-bit protected mode binary.
 TARGET  := hvmloader/hvmloader
 INST_DIR := $(DESTDIR)$(XENFIRMWAREDIR)
-- 
2.17.2 (Apple Git-113)


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

Re: [Xen-devel] Criteria / validation proposal: drop Xen

2019-05-14 Thread Steven Haigh



On Tue, May 14, 2019 at 11:50 PM, Lars Kurth  
wrote:

Apologies,
I mixed up some references
Lars


...

[A2] https://bugzilla.redhat.com/show_bug.cgi?id=1264103
[B1] https://bugzilla.redhat.com/show_bug.cgi?id=1703700


Bug B1 here was lodged by myself. There is also a post to xen-devel 
titled "pygrub not starting first menuentry in Fedora 30".


I just added a comment there which I shall paste below to include those 
not subscribed to that BZ:


Thinking about this further - and noticing it being referenced on 
xen-devel mailing list, I would like to suggest the following - which 
may have been overlooked right now...


If the grub %post scripting checked to see if it was installing / 
upgrading in a Xen DomU, it could set 'GRUB_ENABLE_BLSCFG=false' in 
/etc/default/grub automatically. This would fix both new installs and 
upgrades.


The final fix would be figuring out why pygrub currently boots the 
*second* entry in the resulting grub.cfg - unlike how F29 worked. This 
may be either a fix on the grub2-mkconfig or pygrub side - I'm not 
quite sure yet. This would likely restore functionality completely. At 
least until something else more suitable is done?




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

Re: [Xen-devel] Criteria / validation proposal: drop Xen

2019-05-14 Thread Lars Kurth

Apologies,
I mixed up some references
Lars

> On 13 May 2019, at 16:29, Lars Kurth  wrote:
> 
> Hi all,
> 
> I am going to step in here with my hat as Xen Project community
> manager. We had a discussion about this issue as part of last week's
> community call. I CC'ed a number of stake-holders, which probably
> should have been on the thread such as ITL (which builds QubesOS
> on top of Fedora) and Michael A Young (the Xen package manager).
> 
> First of all apologies that this issue has lingered so long. Key
> members of the community were not aware of the issues raised in
> this thread, otherwise we would have acted earlier. With this in
> mind, please in future raise issues with me, on xen-devel@,
> committers@ or the Xen-Fedora package manager. The Xen Community
> would like to see Fedora running as guest: in fact it would be
> somewhat odd if there was a Xen-Dom0 package and guest support
> didn't work. And there are some downstreams such as QubesOS,
> which depend on this support.
> 
>> On 6 Jul 2017, at 13:45, Adam Williamson  wrote:
>> 
>> On Thu, 2017-07-06 at 15:13 -0400, Konrad Rzeszutek Wilk wrote:
>>> On Thu, Jul 06, 2017 at 11:59:01AM -0700, Adam Williamson wrote:
 Hi, folks! A while ago, Xen virtualization functionality was added to
 the criteria and the validation test case set, on the understanding
 that Oracle would provide testing for it (and help fix bugs as they
 arose).
 
 For the last couple of releases we really have not had any such testing
>>> 
>>> We had been doing the testing, it just that we (or rather me and
>>> Dariof) seem to get a wind of this at the last minute. Not sure exactly
>>> how to fix that thought.
>> 
>> Well, I mean, every few *days* a compose gets nominated for validation
>> testing, and a mail is sent to test-announce. Just check your test-
>> announce archives for mails with "nominated for testing" in their
>> subject lines, and you'll see dozens. Is this not sufficient
>> notification?
> 
> We discussed this at the community call and came to the conclusion that
> we can run regular tests of Fedora RC's as part of our OSSTEST
> infrastructure. Ian Jackson volunteered to implement this, but there
> are some questions on
> a) The installer (which we can handle ourselves)
> b) When we would trigger a test - aka is there some trigger other than the
> c) How would results best be reported back to Fedora
> 
> Apologies, I am not very familiar with how the Fedora Test group works.
> Is there some documentation which would help integrate what you to with
> the test system of another open source project?
> 
 from Oracle. On that basis, I'm proposing we remove this Final
 criterion:
>>> 
>>> s/Oracle/Xen Project/ I believe?
>> 
>> Perhaps, it's just that it always seemed to be you doing the testing,
>> so they got a bit conflated :)
> 
> Can we come to some arrangement, by which such issues get communicated
> to the Xen Project earlier? Aka me, xen-devel@ or committers@
> 
 "The release must boot successfully as Xen DomU with releases providing
 a functional, supported Xen Dom0 and widely used cloud providers
 utilizing Xen."
 
 and change the 'milestone' for the test case -
 https://fedoraproject.org/wiki/QA:Testcase_Boot_Methods_Xen_Para_Virt -
 from Final to Optional.
 
 Thoughts? Comments? Thanks!
>>> 
>>> I would prefer for it to remain as it is.
>> 
>> This is only practical if it's going to be tested, and tested regularly
>> - not *only* on the final release candidate, right before we sign off
>> on the release. It needs to be tested regularly throughout the release
>> cycle, on the composes that are "nominated for testing".
> 
> Would the proposal above work for you? I think it satisfies what you are
> looking for. We would also have someone who monitors these test results
> pro-actively.
> 
> Then, there are the specific grub issues that need resolving
> [A1] https://bugzilla.redhat.com/show_bug.cgi?id=1486002 
> 
> (and a recently filed duplicate @
>  https://bugzilla.redhat.com/show_bug.cgi?id=1691559 
> ) caused by
>  [A2])
> [A2] https://bugzilla.redhat.com/show_bug.cgi?id=1703700 
> 
> [B1] https://bugzilla.redhat.com/show_bug.cgi?id=1264103 
> 

[A2] https://bugzilla.redhat.com/show_bug.cgi?id=1264103
[B1] https://bugzilla.redhat.com/show_bug.cgi?id=1703700 

> 
> The first makes it harder to boot Fedora _dom0_ (but workarounds exist).
> While it is unpleasant, it doesn't break the release criterion, but
> probably has deterred people from testing. The second one [B1] is about
> Fedora _domU_, which breaks the release criterion.
> 
> Marek and Michael had a discussion about these and there was also
> a summary from Daniel.
> 
> == On [A1]/[A2] ==
> Lack of GRUB2

Re: [Xen-devel] [PATCH v2 2/2] xen: implement VCPUOP_register_runstate_phys_memory_area




On 14/05/2019 14:05, Andrii Anisov wrote:



On 14.05.19 15:02, Jan Beulich wrote:

Well, I think Julian's implication was that we can't support in particular
the boot loader -> kernel handover case without extra measures (if
at all), and hence he added things together and said what results
from this. Of course ideally we'd reject mixed requests, but unless
someone can come up with a clever means of how to determine entity
boundaries I'm afraid this is not going to be possible without breaking
certain setups.


 From my understanding, if we are speaking of different entities in a domain and 
their boundaries, we have to define unregister interface as well. So that those 
entities would be able to take care of themselves explicitly.


You have to keep in mind that existing OS have to run on newer Xen without any 
modification.


The existing hypercall allows you to:
   1) De-register an interface using the value 0.
   2) Replacing a current existing interface

You probably can't use 2) for a bootloader -> kernel handover because we are 
dealing with guest virtual address. There is an high chance the virtual address 
space layout is going to be different or even turning off MMU for a bit (done on 
Arm). So you have to use 1) otherwise you might write in a random place in memory.


I am not entirely sure whether there are actual value for 2). The only reason I 
can think of is if you want to move around the runstate in your virtual address 
space. But that's sounds a bit weird at least on Arm.


For the new hypercall, I think we at least want 1) (with a magic value TBD). 2) 
might be helpful in the case the bootloader didn't do the right thing or we are 
using Kexec to boot a new kernel. This would also be safer as physical address 
could be excluded more easily.


2) should not be too difficult to implement. It is just a matter of clean-up 
whatever was used previous before registering the new interface.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] pygrub not starting first menuentry in Fedora 30

2019-05-14 Thread Steven Haigh



On Tue, May 14, 2019 at 11:40 PM, George Dunlap  
wrote:
On Mon, May 13, 2019 at 11:25 AM Steven Haigh  
wrote:


 There seems to be some changes in Fedora 30 that cause the second 
boot

 entry in grub.cfg to be booted instead of the first.

 This means that Fedora 30 systems either always boot into an older
 kernel, or in the case of systems with only one kernel installed, 
the

 rescue image.

 There also seems to be some new issues with the move to BLSCFG -
 however it seems a new requirement is to have
 GRUB_ENABLE_BLSCFG="false" in /etc/default/grub. This causes
 grub2-mkconfig to work correctly and spit out a grub.cfg file that
 pygrub can then use.

 Is this a bug in pygrub, or a problem with how Fedora 30 generates a
 grub.cfg?

 I tried to pick through pygrub - but couldn't quite follow the 
python

 logic to see where the default boot option is selected.


AFAICT, the basic issue is that pygrub is a partial re-implementation
of grub, and hasn't re-implemented the blscfg functionality.


I don't think this is an issue. When using 'GRUB_ENABLE_BLSCFG=false' 
in /etc/default/grub, the grub config file is generated correctly and 
works as expected. The problem is not that it doesn't work, but 
something is causing an offset in the default menu item (almost like an 
off-by-one) that causes the *second* entry in the grub.cfg to boot.



The *most robust* solution going forward is always going to be to use
grub-xen (AKA pvgrub2) instead of pygrub.  grub-xen is a port of the
actual grub project to run as a PV guest, and so will always be  the
most compatible with upstream grub.

Not sure who's "in charge" of pygrub enough to teach it how to use 
blscfg.


I'm not sure there's a huge rush for this... If upstream grub 
installers checked to see if it was installing on a Xen DomU, then set 
GRUB_ENABLE_BLSCFG=false by default - the remaining fix should be 
rather simple to figure out - after all, functionality is correct - 
apart from the wrong entry being selected by default.




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

Re: [Xen-devel] [PATCH v2 2/2] xen: implement VCPUOP_register_runstate_phys_memory_area

>>> On 14.05.19 at 15:05,  wrote:
> On 14.05.19 15:02, Jan Beulich wrote:
>> Well, I think Julian's implication was that we can't support in particular
>> the boot loader -> kernel handover case without extra measures (if
>> at all), and hence he added things together and said what results
>> from this. Of course ideally we'd reject mixed requests, but unless
>> someone can come up with a clever means of how to determine entity
>> boundaries I'm afraid this is not going to be possible without breaking
>> certain setups.
> 
>  From my understanding, if we are speaking of different entities in a domain 
> and their boundaries, we have to define unregister interface as well. So that 
> those entities would be able to take care of themselves explicitly.

If this was a concern only for newly written code, this would be fine.
But you need to make sure all existing code also continues to work
with whatever new interface you implement. Just because a kernel
uses your new physical address based mechanism doesn't mean the
boot loader knows to unregister what it has registered.

Jan



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

Re: [Xen-devel] [PATCH v1] x86/hvm: Generic instruction re-execution mechanism for execute faults

On 5/13/19 5:15 PM, Razvan Cojocaru wrote:

On 5/13/19 5:06 PM, Jan Beulich wrote:

On 13.05.19 at 15:58, wrote:

On 11/27/18 12:49 PM, Razvan Cojocaru wrote:

With a sufficiently complete insn emulator, single-stepping should
not be needed at all imo. Granted we're not quite there yet with
the emulator, but we've made quite a bit of progress. As before,
if there are particular instructions you know of that the emulator
doesn't handle yet, please keep pointing these out. Last I know
were some AVX move instructions, which have long been
implemented.

True, I haven't seen emulator issues in that respect with staging - the
emulator appears lately to be sufficiently complete. Thank you very
much

for your help and support - we'll definitely point out unsupported
instructions if we spot some again.

We've come accross a new instruction that the emulator can't handle in
Xen 4.13-unstable today:

vpmaddwd xmm4,xmm4,XMMWORD PTR ds:0x513fbb20

Perhaps there are plans for this to go into the emulator as well?

You're kidding? This is already in 4.12.0, and if it weren't I'm sure
you're aware there are about 40 more AVX512 patches pending
review.

Right, I did indeed forget about the pending review part, for some
reason I was sure they made it in. I've double-checked and we really are
using 4.13-unstable - but we've also made changes to the emulator,
working on the send-vm-events-from-the-emulator patch, so we'll revert
to a pristine staging and retry, there's a chance this happens because
of our changes.

We'll find out what's going on exactly.

I promised I'd return with more details. After some debugging, it
certainly looks like the emulator returns UNIMPLEMENTED (5):

Mem event emulation failed (5): d5v0 32bit @ 001b:6d96efff -> c5 f9 f5
05 c0 be ad 6d c5 e1 fe 1d a0 20 af 6d

Looking at the source code, the emulator does appear to support
vpmaddwd, however only for EVEX:

http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/x86/x86_emulate/x86_emulate.c;h=032995ea586aa7dd90a1953b6ded656436652049;hb=refs/heads/staging#l6696

whereas our fail case uses VEX.

This may be in the works in the aforementioned series, but is
legitimately unsupported in 4.13 staging.

Thanks,
Razvan

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

Re: [Xen-devel] pygrub not starting first menuentry in Fedora 30

2019-05-14 Thread George Dunlap

On Mon, May 13, 2019 at 11:25 AM Steven Haigh  wrote:
>
> There seems to be some changes in Fedora 30 that cause the second boot
> entry in grub.cfg to be booted instead of the first.
>
> This means that Fedora 30 systems either always boot into an older
> kernel, or in the case of systems with only one kernel installed, the
> rescue image.
>
> There also seems to be some new issues with the move to BLSCFG -
> however it seems a new requirement is to have
> GRUB_ENABLE_BLSCFG="false" in /etc/default/grub. This causes
> grub2-mkconfig to work correctly and spit out a grub.cfg file that
> pygrub can then use.
>
> Is this a bug in pygrub, or a problem with how Fedora 30 generates a
> grub.cfg?
>
> I tried to pick through pygrub - but couldn't quite follow the python
> logic to see where the default boot option is selected.

AFAICT, the basic issue is that pygrub is a partial re-implementation
of grub, and hasn't re-implemented the blscfg functionality.

The *most robust* solution going forward is always going to be to use
grub-xen (AKA pvgrub2) instead of pygrub.  grub-xen is a port of the
actual grub project to run as a PV guest, and so will always be  the
most compatible with upstream grub.

Not sure who's "in charge" of pygrub enough to teach it how to use blscfg.

 -George

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

Re: [Xen-devel] [PATCH v2 2/2] xen: implement VCPUOP_register_runstate_phys_memory_area

2019-05-14 Thread Andrii Anisov




On 14.05.19 15:02, Jan Beulich wrote:

Well, I think Julian's implication was that we can't support in particular
the boot loader -> kernel handover case without extra measures (if
at all), and hence he added things together and said what results
from this. Of course ideally we'd reject mixed requests, but unless
someone can come up with a clever means of how to determine entity
boundaries I'm afraid this is not going to be possible without breaking
certain setups.


From my understanding, if we are speaking of different entities in a domain and 
their boundaries, we have to define unregister interface as well. So that those 
entities would be able to take care of themselves explicitly.

--
Sincerely,
Andrii Anisov.

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

Re: [Xen-devel] [PATCH MM-PART2 RESEND v2 01/19] xen/const: Extend the existing macro BIT to take a suffix in parameter

>>> On 14.05.19 at 14:24,  wrote:
> Arm currently provides two macro BIT and BIT_ULL that are only usable
> in C and return respectively unsigned long and unsigned long long.
> 
> Extending the macros to deal with assembly would be a nice benefits as
> it could replace the common pattern to define fields (AC(1, sfx) << X)
> easier to read.
> 
> Rather than extending the two macros, it was decided to drop BIT_ULL()
> and extend the macro BIT() to take a suffix (e.g U, UL, ULL) in
> parameter. This would allow to use different suffix without having to
> define new macros.
> 
> The new extend macro is now moved in include/xen/const.h so it can be
> used by anyone in Xen and also avoid to include bitops.h in assembly
> code.
> 
> Signed-off-by: Julien Grall 

Thanks much for going this route! For the single line addition to
common code
Acked-by: Jan Beulich 

Jan



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

[Xen-devel] [PATCH MM-PART3 v2 10/12] xen/arm: mm: Rework Xen page-tables walk during update

Currently, xen_pt_update_entry() is only able to update the region covered
by xen_second (i.e 0 to 0x7fff).

Because of the restriction we end to have multiple functions in mm.c
modifying the page-tables differently.

Furthermore, we never walked the page-tables fully. This means that any
change in the layout may requires major rewrite of the page-tables code.

Lastly, we have been quite lucky that no one ever tried to pass an address
outside this range because it would have blown-up.

xen_pt_update_entry() is reworked to walk over the page-tables every
time. The logic has been borrowed from arch/arm/p2m.c and contain some
limitations for the time being:
- Superpage cannot be shattered
- Only level 3 (i.e 4KB) can be done

Note that the parameter 'addr' has been renamed to 'virt' to make clear
we are dealing with a virtual address.

Signed-off-by: Julien Grall 
Reviewed-by: Andrii Anisov 

---
Changes in v2:
- Add Andrii's reviewed-by
---
 xen/arch/arm/mm.c | 121 +++---
 1 file changed, 106 insertions(+), 15 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index f5979f549b..9a40754f44 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -984,6 +984,53 @@ static void xen_unmap_table(const lpae_t *table)
 unmap_domain_page(table);
 }
 
+#define XEN_TABLE_MAP_FAILED 0
+#define XEN_TABLE_SUPER_PAGE 1
+#define XEN_TABLE_NORMAL_PAGE 2
+
+/*
+ * Take the currently mapped table, find the corresponding entry,
+ * and map the next table, if available.
+ *
+ * The read_only parameters indicates whether intermediate tables should
+ * be allocated when not present.
+ *
+ * Return values:
+ *  XEN_TABLE_MAP_FAILED: Either read_only was set and the entry
+ *  was empty, or allocating a new page failed.
+ *  XEN_TABLE_NORMAL_PAGE: next level mapped normally
+ *  XEN_TABLE_SUPER_PAGE: The next entry points to a superpage.
+ */
+static int xen_pt_next_level(bool read_only, unsigned int level,
+ lpae_t **table, unsigned int offset)
+{
+lpae_t *entry;
+int ret;
+
+entry = *table + offset;
+
+if ( !lpae_is_valid(*entry) )
+{
+if ( read_only )
+return XEN_TABLE_MAP_FAILED;
+
+ret = create_xen_table(entry);
+if ( ret )
+return XEN_TABLE_MAP_FAILED;
+}
+
+ASSERT(lpae_is_valid(*entry));
+
+/* The function xen_pt_next_level is never called at the 3rd level */
+if ( lpae_is_mapping(*entry, level) )
+return XEN_TABLE_SUPER_PAGE;
+
+xen_unmap_table(*table);
+*table = xen_map_table(lpae_get_mfn(*entry));
+
+return XEN_TABLE_NORMAL_PAGE;
+}
+
 /* Sanity check of the entry */
 static bool xen_pt_check_entry(lpae_t entry, mfn_t mfn, unsigned int flags)
 {
@@ -1043,30 +1090,65 @@ static bool xen_pt_check_entry(lpae_t entry, mfn_t mfn, 
unsigned int flags)
 return true;
 }
 
-static int xen_pt_update_entry(unsigned long addr, mfn_t mfn,
-   unsigned int flags)
+static int xen_pt_update_entry(mfn_t root, unsigned long virt,
+   mfn_t mfn, unsigned int flags)
 {
 int rc;
+unsigned int level;
+/* We only support 4KB mapping (i.e level 3) for now */
+unsigned int target = 3;
+lpae_t *table;
+/*
+ * The intermediate page tables are read-only when the MFN is not valid
+ * and we are not populating page table.
+ * This means we either modify permissions or remove an entry.
+ */
+bool read_only = mfn_eq(mfn, INVALID_MFN) && !(flags & _PAGE_POPULATE);
 lpae_t pte, *entry;
-lpae_t *third = NULL;
+
+/* convenience aliases */
+DECLARE_OFFSETS(offsets, (paddr_t)virt);
 
 /* _PAGE_POPULATE and _PAGE_PRESENT should never be set together. */
 ASSERT((flags & (_PAGE_POPULATE|_PAGE_PRESENT)) != 
(_PAGE_POPULATE|_PAGE_PRESENT));
 
-entry = _second[second_linear_offset(addr)];
-if ( !lpae_is_valid(*entry) || !lpae_is_table(*entry, 2) )
+table = xen_map_table(root);
+for ( level = HYP_PT_ROOT_LEVEL; level < target; level++ )
 {
-int rc = create_xen_table(entry);
-if ( rc < 0 ) {
-printk("%s: L2 failed\n", __func__);
-return rc;
+rc = xen_pt_next_level(read_only, level, , offsets[level]);
+if ( rc == XEN_TABLE_MAP_FAILED )
+{
+/*
+ * We are here because xen_pt_next_level has failed to map
+ * the intermediate page table (e.g the table does not exist
+ * and the pt is read-only). It is a valid case when
+ * removing a mapping as it may not exist in the page table.
+ * In this case, just ignore it.
+ */
+if ( flags & (_PAGE_PRESENT|_PAGE_POPULATE) )
+{
+mm_printk("%s: Unable to map level %u\n", __func__, level);
+rc = -ENOENT;
+goto out;
+}
+else
+

[Xen-devel] [PATCH MM-PART3 v2 07/12] xen/arm: mm: Rework xen_pt_update_entry to avoid use xenmap_operation

With the newly introduced flags, it is now possible to know how the page
will be updated through the flags.

All the use of xenmap_operation are now replaced with the flags. At the
same time, validity check are now removed as they are gathered in
xen_pt_check_entry().

Signed-off-by: Julien Grall 
Reviewed-by: Andrii Anisov 

---

Changes in v2:
- Fix typo in the commit message
- Add Andrii's reviewed-by
---
 xen/arch/arm/mm.c | 47 +++
 1 file changed, 23 insertions(+), 24 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 45a6f9287f..86e1faeeb5 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -1067,34 +1067,33 @@ static int xen_pt_update_entry(enum xenmap_operation 
op, unsigned long addr,
 if ( !xen_pt_check_entry(*entry, mfn, flags) )
 return -EINVAL;
 
-switch ( op ) {
-case INSERT:
-case RESERVE:
-if ( op == RESERVE )
-break;
+/* If we are only populating page-table, then we are done. */
+if ( flags & _PAGE_POPULATE )
+return 0;
+
+/* We are removing the page */
+if ( !(flags & _PAGE_PRESENT) )
+memset(, 0x00, sizeof(pte));
+else
+{
+/* We are inserting a mapping => Create new pte. */
+if ( !mfn_eq(mfn, INVALID_MFN) )
+{
 pte = mfn_to_xen_entry(mfn, PAGE_AI_MASK(flags));
-pte.pt.ro = PAGE_RO_MASK(flags);
-pte.pt.xn = PAGE_XN_MASK(flags);
-BUG_ON(!pte.pt.ro && !pte.pt.xn);
+
+/* Third level entries set pte.pt.table = 1 */
 pte.pt.table = 1;
-write_pte(entry, pte);
-break;
-case MODIFY:
-case REMOVE:
-if ( op == REMOVE )
-pte.bits = 0;
-else
-{
-pte = *entry;
-pte.pt.ro = PAGE_RO_MASK(flags);
-pte.pt.xn = PAGE_XN_MASK(flags);
-}
-write_pte(entry, pte);
-break;
-default:
-BUG();
+}
+else /* We are updating the permission => Copy the current pte. */
+pte = *entry;
+
+/* Set permission */
+pte.pt.ro = PAGE_RO_MASK(flags);
+pte.pt.xn = PAGE_XN_MASK(flags);
 }
 
+write_pte(entry, pte);
+
 return 0;
 }
 
-- 
2.11.0


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

[Xen-devel] [PATCH MM-PART3 v2 09/12] xen/arm: mm: Use {, un}map_domain_page() to map/unmap Xen page-tables

Currently, the virtual address of the 3rd level page-tables is obtained
using mfn_to_virt().

On Arm32, mfn_to_virt can only work on xenheap page. While in practice
all the page-tables updated will reside in xenheap, in practive the
page-tables covering Xen memory (e.g xen_mapping) is part of Xen binary.

Furthermore, a follow-up change will update xen_pt_update_entry() to
walk all the levels and therefore be more generic. Some of the
page-tables will also part of Xen memory and therefore will not be
reachable using mfn_to_virt().

The easiest way to reach those pages is to use {, un}map_domain_page().
While on arm32 this means an extra mapping in the normal cases, this is not
very important as xen page-tables are not updated often.

In order to allow future change in the way Xen page-tables are mapped,
two new helpers are introduced to map/unmap the page-tables.

Signed-off-by: Julien Grall 
Reviewed-by: Andrii Anisov 

---

Changes in v2:
- Add Andrii's reviewed-by
---
 xen/arch/arm/mm.c | 26 ++
 1 file changed, 22 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 651e296041..f5979f549b 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -974,6 +974,16 @@ static int create_xen_table(lpae_t *entry)
 return 0;
 }
 
+static lpae_t *xen_map_table(mfn_t mfn)
+{
+return map_domain_page(mfn);
+}
+
+static void xen_unmap_table(const lpae_t *table)
+{
+unmap_domain_page(table);
+}
+
 /* Sanity check of the entry */
 static bool xen_pt_check_entry(lpae_t entry, mfn_t mfn, unsigned int flags)
 {
@@ -1036,6 +1046,7 @@ static bool xen_pt_check_entry(lpae_t entry, mfn_t mfn, 
unsigned int flags)
 static int xen_pt_update_entry(unsigned long addr, mfn_t mfn,
unsigned int flags)
 {
+int rc;
 lpae_t pte, *entry;
 lpae_t *third = NULL;
 
@@ -1054,15 +1065,17 @@ static int xen_pt_update_entry(unsigned long addr, 
mfn_t mfn,
 
 BUG_ON(!lpae_is_valid(*entry));
 
-third = mfn_to_virt(lpae_get_mfn(*entry));
+third = xen_map_table(lpae_get_mfn(*entry));
 entry = [third_table_offset(addr)];
 
+rc = -EINVAL;
 if ( !xen_pt_check_entry(*entry, mfn, flags) )
-return -EINVAL;
+goto out;
 
 /* If we are only populating page-table, then we are done. */
+rc = 0;
 if ( flags & _PAGE_POPULATE )
-return 0;
+goto out;
 
 /* We are removing the page */
 if ( !(flags & _PAGE_PRESENT) )
@@ -1087,7 +1100,12 @@ static int xen_pt_update_entry(unsigned long addr, mfn_t 
mfn,
 
 write_pte(entry, pte);
 
-return 0;
+rc = 0;
+
+out:
+xen_unmap_table(third);
+
+return rc;
 }
 
 static DEFINE_SPINLOCK(xen_pt_lock);
-- 
2.11.0


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

[Xen-devel] [PATCH MM-PART3 v2 02/12] xen/arm: mm: Rename create_xen_entries() to xen_pt_update()

create_xen_entries() is doing more than creating entries. It can also
modify and remove entries.

Rename the function to make clear what the function is actually doing.

Signed-off-by: Julien Grall 
Reviewed-by: Andrii Anisov 

---
Changes in v2:
- Add Andrii's reviewed-by
---
 xen/arch/arm/mm.c | 19 +--
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index b408de7c75..36e22fc9ad 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -970,11 +970,11 @@ enum xenmap_operation {
 
 static DEFINE_SPINLOCK(xen_pt_lock);
 
-static int create_xen_entries(enum xenmap_operation op,
-  unsigned long virt,
-  mfn_t mfn,
-  unsigned long nr_mfns,
-  unsigned int flags)
+static int xen_pt_update(enum xenmap_operation op,
+ unsigned long virt,
+ mfn_t mfn,
+ unsigned long nr_mfns,
+ unsigned int flags)
 {
 int rc = 0;
 unsigned long addr = virt, addr_end = addr + nr_mfns * PAGE_SIZE;
@@ -1067,25 +1067,24 @@ int map_pages_to_xen(unsigned long virt,
  unsigned long nr_mfns,
  unsigned int flags)
 {
-return create_xen_entries(INSERT, virt, mfn, nr_mfns, flags);
+return xen_pt_update(INSERT, virt, mfn, nr_mfns, flags);
 }
 
 int populate_pt_range(unsigned long virt, unsigned long nr_mfns)
 {
-return create_xen_entries(RESERVE, virt, INVALID_MFN, nr_mfns, 0);
+return xen_pt_update(RESERVE, virt, INVALID_MFN, nr_mfns, 0);
 }
 
 int destroy_xen_mappings(unsigned long v, unsigned long e)
 {
 ASSERT(v <= e);
-return create_xen_entries(REMOVE, v, INVALID_MFN, (e - v) >> PAGE_SHIFT, 
0);
+return xen_pt_update(REMOVE, v, INVALID_MFN, (e - v) >> PAGE_SHIFT, 0);
 }
 
 int modify_xen_mappings(unsigned long s, unsigned long e, unsigned int flags)
 {
 ASSERT(s <= e);
-return create_xen_entries(MODIFY, s, INVALID_MFN, (e - s) >> PAGE_SHIFT,
-  flags);
+return xen_pt_update(MODIFY, s, INVALID_MFN, (e - s) >> PAGE_SHIFT, flags);
 }
 
 enum mg { mg_clear, mg_ro, mg_rw, mg_rx };
-- 
2.11.0


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

[Xen-devel] [PATCH MM-PART3 v2 00/12] xen/arm: Provide a generic function to update Xen PT

Hi all,

This is the third part of the boot/memory rework for Xen on Arm. At the
moment, the update to Xen PT is scattered all around mm.c. This makes
difficult to rework Xen memory layout or even ensuring we are following the
Arm Arm properly (and we are not so far!).

This part contains code to provide a generic function to update Xen PT.
While I could have started from scratch, I decided to base the new function
on create_xen_entries() (now renamed xen_pt_update()). This makes slightly
easier to follow the changes.

In this series, the new generic function will only support 3rd-level update
and cannot be used in early boot (i.e because xenheap is not initialized).
This will be extended in follow-up series to allow more use within mm.c.

There are probably some optimization possible around the TLBs flush. I haven't
looked at it so far.

The last two patches of this series is to show how existing callers can be
converted. There are more conversion to come in follow-up series.

This series is based on the first two parts sent separately (see [1] and [2]).

For convenience, I provided a branch with all the patches applied based on
staging:

git://xenbits.xen.org/people/julieng/xen-unstable.git branch mm/part3/v2

Cheers,

[1] https://lists.xenproject.org/archives/html/xen-devel/2019-05/msg01109.html
[2] https://lists.xenproject.org/archives/html/xen-devel/2019-05/msg01149.html

Julien Grall (12):
  xen/arm: lpae: Add a macro to generate offsets from an address
  xen/arm: mm: Rename create_xen_entries() to xen_pt_update()
  xen/arm: mm: Move out of xen_pt_update() the logic to update an entry
  xen/arm: mm: Only increment mfn when valid in xen_pt_update
  xen/arm: mm: Introduce _PAGE_PRESENT and _PAGE_POPULATE
  xen/arm: mm: Sanity check any update of Xen page tables
  xen/arm: mm: Rework xen_pt_update_entry to avoid use xenmap_operation
  xen/arm: mm: Remove enum xenmap_operation
  xen/arm: mm: Use {, un}map_domain_page() to map/unmap Xen page-tables
  xen/arm: mm: Rework Xen page-tables walk during update
  xen/arm: mm: Don't open-code Xen PT update in {set, clear}_fixmap()
  xen/arm: mm: Remove set_pte_flags_on_range()

 xen/arch/arm/mm.c  | 421 ++---
 xen/arch/arm/p2m.c |  23 +--
 xen/include/asm-arm/lpae.h |   9 +
 xen/include/asm-arm/page.h |   9 +-
 4 files changed, 305 insertions(+), 157 deletions(-)

-- 
2.11.0


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

[Xen-devel] [PATCH MM-PART3 v2 12/12] xen/arm: mm: Remove set_pte_flags_on_range()

set_pte_flags_on_range() is yet another function that will open-code
update to a specific range in the Xen page-tables. It can be completely
dropped by using either modify_xen_mappings() or destroy_xen_mappings().

Signed-off-by: Julien Grall 
Reviewed-by: Andrii Anisov 

---
Changes in v2:
- Add missing newline in panic
- Add Andrii's reviewed-by
---
 xen/arch/arm/mm.c | 58 ++-
 1 file changed, 10 insertions(+), 48 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 23ca61e8f0..d74101bcd2 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -1277,52 +1277,6 @@ int modify_xen_mappings(unsigned long s, unsigned long 
e, unsigned int flags)
 return xen_pt_update(s, INVALID_MFN, (e - s) >> PAGE_SHIFT, flags);
 }
 
-enum mg { mg_clear, mg_ro, mg_rw, mg_rx };
-static void set_pte_flags_on_range(const char *p, unsigned long l, enum mg mg)
-{
-lpae_t pte;
-int i;
-
-ASSERT(is_kernel(p) && is_kernel(p + l));
-
-/* Can only guard in page granularity */
-ASSERT(!((unsigned long) p & ~PAGE_MASK));
-ASSERT(!(l & ~PAGE_MASK));
-
-for ( i = (p - _start) / PAGE_SIZE; 
-  i < (p + l - _start) / PAGE_SIZE; 
-  i++ )
-{
-pte = xen_xenmap[i];
-switch ( mg )
-{
-case mg_clear:
-pte.pt.valid = 0;
-break;
-case mg_ro:
-pte.pt.valid = 1;
-pte.pt.pxn = 1;
-pte.pt.xn = 1;
-pte.pt.ro = 1;
-break;
-case mg_rw:
-pte.pt.valid = 1;
-pte.pt.pxn = 1;
-pte.pt.xn = 1;
-pte.pt.ro = 0;
-break;
-case mg_rx:
-pte.pt.valid = 1;
-pte.pt.pxn = 0;
-pte.pt.xn = 0;
-pte.pt.ro = 1;
-break;
-}
-write_pte(xen_xenmap + i, pte);
-}
-flush_xen_tlb_local();
-}
-
 /* Release all __init and __initdata ranges to be reused */
 void free_init_memory(void)
 {
@@ -1331,8 +1285,12 @@ void free_init_memory(void)
 uint32_t insn;
 unsigned int i, nr = len / sizeof(insn);
 uint32_t *p;
+int rc;
 
-set_pte_flags_on_range(__init_begin, len, mg_rw);
+rc = modify_xen_mappings((unsigned long)__init_begin,
+ (unsigned long)__init_end, PAGE_HYPERVISOR_RW);
+if ( rc )
+panic("Unable to map RW the init section (rc = %d)\n", rc);
 
 /*
  * From now on, init will not be used for execution anymore,
@@ -1350,7 +1308,11 @@ void free_init_memory(void)
 for ( i = 0; i < nr; i++ )
 *(p + i) = insn;
 
-set_pte_flags_on_range(__init_begin, len, mg_clear);
+rc = destroy_xen_mappings((unsigned long)__init_begin,
+  (unsigned long)__init_end);
+if ( rc )
+panic("Unable to remove the init section (rc = %d)\n", rc);
+
 init_domheap_pages(pa, pa + len);
 printk("Freed %ldkB init memory.\n", (long)(__init_end-__init_begin)>>10);
 }
-- 
2.11.0


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

[Xen-devel] [PATCH MM-PART3 v2 06/12] xen/arm: mm: Sanity check any update of Xen page tables

The code handling Xen PT update has quite a few restrictions on what it
can do. This is not a bad thing as it keeps the code simple.

There are already a few checks scattered in current page table handling.
However they are not sufficient as they could still allow to
modify/remove entry with contiguous bit set.

The checks are divided in two sets:
- per entry check: They are gathered in a new function that will
check whether an update is valid based on the flags passed and the
current value of an entry.
- global check: They are sanity check on xen_pt_update() parameters.

Additionally to contiguous check, we also now check that the caller is
not trying to modify the memory attributes of an entry.

Lastly, it was probably a bit over the top to forbid removing an
invalid mapping. This could just be ignored. The new behavior will be
helpful in future changes.

Signed-off-by: Julien Grall 
Reviewed-by: Andrii Anisov 

---
Changes in v2:
- Correctly detect the removal of a page
- Fix ASSERT on flags in the else case
- Add Andrii's reviewed-by
---
 xen/arch/arm/mm.c | 115 +-
 1 file changed, 97 insertions(+), 18 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 2192dede55..45a6f9287f 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -50,6 +50,19 @@ struct domain *dom_xen, *dom_io, *dom_cow;
 #undef mfn_to_virt
 #define mfn_to_virt(mfn) __mfn_to_virt(mfn_x(mfn))
 
+#ifdef NDEBUG
+static inline void
+__attribute__ ((__format__ (__printf__, 1, 2)))
+mm_printk(const char *fmt, ...) {}
+#else
+#define mm_printk(fmt, args...) \
+do  \
+{   \
+dprintk(XENLOG_ERR, fmt, ## args);  \
+WARN(); \
+} while (0);
+#endif
+
 #define DEFINE_PAGE_TABLES(name, nr)\
 lpae_t __aligned(PAGE_SIZE) name[LPAE_ENTRIES * (nr)]
 
@@ -968,12 +981,74 @@ enum xenmap_operation {
 RESERVE
 };
 
+/* Sanity check of the entry */
+static bool xen_pt_check_entry(lpae_t entry, mfn_t mfn, unsigned int flags)
+{
+/* Sanity check when modifying a page. */
+if ( (flags & _PAGE_PRESENT) && mfn_eq(mfn, INVALID_MFN) )
+{
+/* We don't allow changing memory attributes. */
+if ( entry.pt.ai != PAGE_AI_MASK(flags) )
+{
+mm_printk("Modifying memory attributes is not allowed (0x%x -> 
0x%x).\n",
+  entry.pt.ai, PAGE_AI_MASK(flags));
+return false;
+}
+
+/* We don't allow modifying entry with contiguous bit set. */
+if ( entry.pt.contig )
+{
+mm_printk("Modifying entry with contiguous bit set is not 
allowed.\n");
+return false;
+}
+}
+/* Sanity check when inserting a page */
+else if ( flags & _PAGE_PRESENT )
+{
+/* We should be here with a valid MFN. */
+ASSERT(!mfn_eq(mfn, INVALID_MFN));
+
+/* We don't allow replacing any valid entry. */
+if ( lpae_is_valid(entry) )
+{
+mm_printk("Changing MFN for a valid entry is not allowed 
(%#"PRI_mfn" -> %#"PRI_mfn").\n",
+  mfn_x(lpae_get_mfn(entry)), mfn_x(mfn));
+return false;
+}
+}
+/* Sanity check when removing a page. */
+else if ( (flags & (_PAGE_PRESENT|_PAGE_POPULATE)) == 0 )
+{
+/* We should be here with an invalid MFN. */
+ASSERT(mfn_eq(mfn, INVALID_MFN));
+
+/* We don't allow removing page with contiguous bit set. */
+if ( entry.pt.contig )
+{
+mm_printk("Removing entry with contiguous bit set is not 
allowed.\n");
+return false;
+}
+}
+/* Sanity check when populating the page-table. No check so far. */
+else
+{
+ASSERT(flags & _PAGE_POPULATE);
+/* We should be here with an invalid MFN */
+ASSERT(mfn_eq(mfn, INVALID_MFN));
+}
+
+return true;
+}
+
 static int xen_pt_update_entry(enum xenmap_operation op, unsigned long addr,
mfn_t mfn, unsigned int flags)
 {
 lpae_t pte, *entry;
 lpae_t *third = NULL;
 
+/* _PAGE_POPULATE and _PAGE_PRESENT should never be set together. */
+ASSERT((flags & (_PAGE_POPULATE|_PAGE_PRESENT)) != 
(_PAGE_POPULATE|_PAGE_PRESENT));
+
 entry = _second[second_linear_offset(addr)];
 if ( !lpae_is_valid(*entry) || !lpae_is_table(*entry, 2) )
 {
@@ -989,15 +1064,12 @@ static int xen_pt_update_entry(enum xenmap_operation op, 
unsigned long addr,
 third = mfn_to_virt(lpae_get_mfn(*entry));
 entry = [third_table_offset(addr)];
 
+if ( !xen_pt_check_entry(*entry, mfn, flags) )
+return -EINVAL;
+
 switch ( op ) {
 case INSERT:
 case RESERVE:
-if ( lpae_is_valid(*entry) )
-{
-printk("%s: trying

[Xen-devel] [PATCH MM-PART3 v2 03/12] xen/arm: mm: Move out of xen_pt_update() the logic to update an entry

In preparation of rework of the Xen PT, the logic to update an entry
in moved out in a separate function.

Signed-off-by: Julien Grall 
Reviewed-by: Andrii Anisov 

---
Changes in v2:
- Add Andrii's reviewed-by
---
 xen/arch/arm/mm.c | 140 +-
 1 file changed, 74 insertions(+), 66 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 36e22fc9ad..f956aa6399 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -968,6 +968,76 @@ enum xenmap_operation {
 RESERVE
 };
 
+static int xen_pt_update_entry(enum xenmap_operation op, unsigned long addr,
+   mfn_t mfn, unsigned int flags)
+{
+lpae_t pte, *entry;
+lpae_t *third = NULL;
+
+entry = _second[second_linear_offset(addr)];
+if ( !lpae_is_valid(*entry) || !lpae_is_table(*entry, 2) )
+{
+int rc = create_xen_table(entry);
+if ( rc < 0 ) {
+printk("%s: L2 failed\n", __func__);
+return rc;
+}
+}
+
+BUG_ON(!lpae_is_valid(*entry));
+
+third = mfn_to_virt(lpae_get_mfn(*entry));
+entry = [third_table_offset(addr)];
+
+switch ( op ) {
+case INSERT:
+case RESERVE:
+if ( lpae_is_valid(*entry) )
+{
+printk("%s: trying to replace an existing mapping addr=%lx 
mfn=%"PRI_mfn"\n",
+   __func__, addr, mfn_x(mfn));
+return -EINVAL;
+}
+if ( op == RESERVE )
+break;
+pte = mfn_to_xen_entry(mfn, PAGE_AI_MASK(flags));
+pte.pt.ro = PAGE_RO_MASK(flags);
+pte.pt.xn = PAGE_XN_MASK(flags);
+BUG_ON(!pte.pt.ro && !pte.pt.xn);
+pte.pt.table = 1;
+write_pte(entry, pte);
+break;
+case MODIFY:
+case REMOVE:
+if ( !lpae_is_valid(*entry) )
+{
+printk("%s: trying to %s a non-existing mapping addr=%lx\n",
+   __func__, op == REMOVE ? "remove" : "modify", addr);
+return -EINVAL;
+}
+if ( op == REMOVE )
+pte.bits = 0;
+else
+{
+pte = *entry;
+pte.pt.ro = PAGE_RO_MASK(flags);
+pte.pt.xn = PAGE_XN_MASK(flags);
+if ( !pte.pt.ro && !pte.pt.xn )
+{
+printk("%s: Incorrect combination for addr=%lx\n",
+   __func__, addr);
+return -EINVAL;
+}
+}
+write_pte(entry, pte);
+break;
+default:
+BUG();
+}
+
+return 0;
+}
+
 static DEFINE_SPINLOCK(xen_pt_lock);
 
 static int xen_pt_update(enum xenmap_operation op,
@@ -978,78 +1048,16 @@ static int xen_pt_update(enum xenmap_operation op,
 {
 int rc = 0;
 unsigned long addr = virt, addr_end = addr + nr_mfns * PAGE_SIZE;
-lpae_t pte, *entry;
-lpae_t *third = NULL;
 
 spin_lock(_pt_lock);
 
 for(; addr < addr_end; addr += PAGE_SIZE, mfn = mfn_add(mfn, 1))
 {
-entry = _second[second_linear_offset(addr)];
-if ( !lpae_is_valid(*entry) || !lpae_is_table(*entry, 2) )
-{
-rc = create_xen_table(entry);
-if ( rc < 0 ) {
-printk("%s: L2 failed\n", __func__);
-goto out;
-}
-}
-
-BUG_ON(!lpae_is_valid(*entry));
-
-third = mfn_to_virt(lpae_get_mfn(*entry));
-entry = [third_table_offset(addr)];
-
-switch ( op ) {
-case INSERT:
-case RESERVE:
-if ( lpae_is_valid(*entry) )
-{
-printk("%s: trying to replace an existing mapping addr=%lx 
mfn=%"PRI_mfn"\n",
-   __func__, addr, mfn_x(mfn));
-rc = -EINVAL;
-goto out;
-}
-if ( op == RESERVE )
-break;
-pte = mfn_to_xen_entry(mfn, PAGE_AI_MASK(flags));
-pte.pt.ro = PAGE_RO_MASK(flags);
-pte.pt.xn = PAGE_XN_MASK(flags);
-BUG_ON(!pte.pt.ro && !pte.pt.xn);
-pte.pt.table = 1;
-write_pte(entry, pte);
-break;
-case MODIFY:
-case REMOVE:
-if ( !lpae_is_valid(*entry) )
-{
-printk("%s: trying to %s a non-existing mapping 
addr=%lx\n",
-   __func__, op == REMOVE ? "remove" : "modify", addr);
-rc = -EINVAL;
-goto out;
-}
-if ( op == REMOVE )
-pte.bits = 0;
-else
-{
-pte = *entry;
-pte.pt.ro = PAGE_RO_MASK(flags);
-pte.pt.xn =

[Xen-devel] [PATCH MM-PART3 v2 01/12] xen/arm: lpae: Add a macro to generate offsets from an address

There are few places requiring to generate offsets from an address.
Rather than open-coding everywhere, we can introduce a macro to do the
job for us.

Signed-off-by: Julien Grall 
Reviewed-by: Andrii Anisov 

---
Changes in v2:
- Add Andrii's reviewed-by
---
 xen/arch/arm/p2m.c | 23 +++
 xen/include/asm-arm/lpae.h |  9 +
 2 files changed, 12 insertions(+), 20 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 92c2413f20..06fa342a8f 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -368,12 +368,7 @@ mfn_t p2m_get_entry(struct p2m_domain *p2m, gfn_t gfn,
 p2m_type_t _t;
 
 /* Convenience aliases */
-const unsigned int offsets[4] = {
-zeroeth_table_offset(addr),
-first_table_offset(addr),
-second_table_offset(addr),
-third_table_offset(addr)
-};
+DECLARE_OFFSETS(offsets, addr);
 
 ASSERT(p2m_is_locked(p2m));
 BUILD_BUG_ON(THIRD_MASK != PAGE_MASK);
@@ -888,7 +883,6 @@ static int __p2m_set_entry(struct p2m_domain *p2m,
p2m_type_t t,
p2m_access_t a)
 {
-paddr_t addr = gfn_to_gaddr(sgfn);
 unsigned int level = 0;
 unsigned int target = 3 - (page_order / LPAE_SHIFT);
 lpae_t *entry, *table, orig_pte;
@@ -897,12 +891,7 @@ static int __p2m_set_entry(struct p2m_domain *p2m,
 bool removing_mapping = mfn_eq(smfn, INVALID_MFN);
 
 /* Convenience aliases */
-const unsigned int offsets[4] = {
-zeroeth_table_offset(addr),
-first_table_offset(addr),
-second_table_offset(addr),
-third_table_offset(addr)
-};
+DECLARE_OFFSETS(offsets, gfn_to_gaddr(sgfn));
 
 ASSERT(p2m_is_write_locked(p2m));
 
@@ -1199,15 +1188,9 @@ bool p2m_resolve_translation_fault(struct domain *d, 
gfn_t gfn)
 unsigned int level = 0;
 bool resolved = false;
 lpae_t entry, *table;
-paddr_t addr = gfn_to_gaddr(gfn);
 
 /* Convenience aliases */
-const unsigned int offsets[4] = {
-zeroeth_table_offset(addr),
-first_table_offset(addr),
-second_table_offset(addr),
-third_table_offset(addr)
-};
+DECLARE_OFFSETS(offsets, gfn_to_gaddr(gfn));
 
 p2m_write_lock(p2m);
 
diff --git a/xen/include/asm-arm/lpae.h b/xen/include/asm-arm/lpae.h
index 545b0c8f24..c22780f8f3 100644
--- a/xen/include/asm-arm/lpae.h
+++ b/xen/include/asm-arm/lpae.h
@@ -218,6 +218,15 @@ TABLE_OFFSET_HELPERS(64);
 #undef TABLE_OFFSET
 #undef TABLE_OFFSET_HELPERS
 
+/* Generate an array @var containing the offset for each level from @addr */
+#define DECLARE_OFFSETS(var, addr)  \
+const unsigned int var[4] = {   \
+zeroeth_table_offset(addr), \
+first_table_offset(addr),   \
+second_table_offset(addr),  \
+third_table_offset(addr)\
+}
+
 #endif /* __ASSEMBLY__ */
 
 /*
-- 
2.11.0


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

[Xen-devel] [PATCH MM-PART3 v2 05/12] xen/arm: mm: Introduce _PAGE_PRESENT and _PAGE_POPULATE

At the moment, the flags are not enough to describe what kind of update
will done on the VA range. They need to be used in conjunction with the
enum xenmap_operation.

It would be more convenient to have all the information for the update
in a single place.

Two new flags are added to remove the relience on xenmap_operation:
- _PAGE_PRESENT: Indicate whether we are adding/removing the mapping
- _PAGE_POPULATE: Indicate whether we only populate page-tables

Signed-off-by: Julien Grall 
Reviewed-by: Andrii Anisov 

---
Changes in v2:
- Add Andrii's reviewed-by
---
 xen/arch/arm/mm.c  | 2 +-
 xen/include/asm-arm/page.h | 9 +++--
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 9de2a1150f..2192dede55 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -1083,7 +1083,7 @@ int map_pages_to_xen(unsigned long virt,
 
 int populate_pt_range(unsigned long virt, unsigned long nr_mfns)
 {
-return xen_pt_update(RESERVE, virt, INVALID_MFN, nr_mfns, 0);
+return xen_pt_update(RESERVE, virt, INVALID_MFN, nr_mfns, _PAGE_POPULATE);
 }
 
 int destroy_xen_mappings(unsigned long v, unsigned long e)
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 2bcdb0f1a5..caf2fac1ff 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -76,6 +76,8 @@
  *
  * [0:2] Memory Attribute Index
  * [3:4] Permission flags
+ * [5]   Present bit
+ * [6]   Populate page table
  */
 #define PAGE_AI_MASK(x) ((x) & 0x7U)
 
@@ -86,12 +88,15 @@
 #define PAGE_XN_MASK(x) (((x) >> _PAGE_XN_BIT) & 0x1U)
 #define PAGE_RO_MASK(x) (((x) >> _PAGE_RO_BIT) & 0x1U)
 
+#define _PAGE_PRESENT(1U << 5)
+#define _PAGE_POPULATE   (1U << 6)
+
 /*
  * _PAGE_DEVICE and _PAGE_NORMAL are convenience defines. They are not
  * meant to be used outside of this header.
  */
-#define _PAGE_DEVICE_PAGE_XN
-#define _PAGE_NORMALMT_NORMAL
+#define _PAGE_DEVICE(_PAGE_XN|_PAGE_PRESENT)
+#define _PAGE_NORMAL(MT_NORMAL|_PAGE_PRESENT)
 
 #define PAGE_HYPERVISOR_RO  (_PAGE_NORMAL|_PAGE_RO|_PAGE_XN)
 #define PAGE_HYPERVISOR_RX  (_PAGE_NORMAL|_PAGE_RO)
-- 
2.11.0


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

[Xen-devel] [PATCH MM-PART3 v2 08/12] xen/arm: mm: Remove enum xenmap_operation

The enum xenmap_operation is not used anymore. So remove it.

Signed-off-by: Julien Grall 
Reviewed-by: Andrii Anisov 

---
Changes in v2:
- Add Andrii's reviewed-by
---
 xen/arch/arm/mm.c | 24 
 1 file changed, 8 insertions(+), 16 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 86e1faeeb5..651e296041 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -974,13 +974,6 @@ static int create_xen_table(lpae_t *entry)
 return 0;
 }
 
-enum xenmap_operation {
-INSERT,
-REMOVE,
-MODIFY,
-RESERVE
-};
-
 /* Sanity check of the entry */
 static bool xen_pt_check_entry(lpae_t entry, mfn_t mfn, unsigned int flags)
 {
@@ -1040,8 +1033,8 @@ static bool xen_pt_check_entry(lpae_t entry, mfn_t mfn, 
unsigned int flags)
 return true;
 }
 
-static int xen_pt_update_entry(enum xenmap_operation op, unsigned long addr,
-   mfn_t mfn, unsigned int flags)
+static int xen_pt_update_entry(unsigned long addr, mfn_t mfn,
+   unsigned int flags)
 {
 lpae_t pte, *entry;
 lpae_t *third = NULL;
@@ -1099,8 +1092,7 @@ static int xen_pt_update_entry(enum xenmap_operation op, 
unsigned long addr,
 
 static DEFINE_SPINLOCK(xen_pt_lock);
 
-static int xen_pt_update(enum xenmap_operation op,
- unsigned long virt,
+static int xen_pt_update(unsigned long virt,
  mfn_t mfn,
  unsigned long nr_mfns,
  unsigned int flags)
@@ -1131,7 +1123,7 @@ static int xen_pt_update(enum xenmap_operation op,
 
 for( ; addr < addr_end; addr += PAGE_SIZE )
 {
-rc = xen_pt_update_entry(op, addr, mfn, flags);
+rc = xen_pt_update_entry(addr, mfn, flags);
 if ( rc )
 break;
 
@@ -1156,24 +1148,24 @@ int map_pages_to_xen(unsigned long virt,
  unsigned long nr_mfns,
  unsigned int flags)
 {
-return xen_pt_update(INSERT, virt, mfn, nr_mfns, flags);
+return xen_pt_update(virt, mfn, nr_mfns, flags);
 }
 
 int populate_pt_range(unsigned long virt, unsigned long nr_mfns)
 {
-return xen_pt_update(RESERVE, virt, INVALID_MFN, nr_mfns, _PAGE_POPULATE);
+return xen_pt_update(virt, INVALID_MFN, nr_mfns, _PAGE_POPULATE);
 }
 
 int destroy_xen_mappings(unsigned long v, unsigned long e)
 {
 ASSERT(v <= e);
-return xen_pt_update(REMOVE, v, INVALID_MFN, (e - v) >> PAGE_SHIFT, 0);
+return xen_pt_update(v, INVALID_MFN, (e - v) >> PAGE_SHIFT, 0);
 }
 
 int modify_xen_mappings(unsigned long s, unsigned long e, unsigned int flags)
 {
 ASSERT(s <= e);
-return xen_pt_update(MODIFY, s, INVALID_MFN, (e - s) >> PAGE_SHIFT, flags);
+return xen_pt_update(s, INVALID_MFN, (e - s) >> PAGE_SHIFT, flags);
 }
 
 enum mg { mg_clear, mg_ro, mg_rw, mg_rx };
-- 
2.11.0


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

[Xen-devel] [PATCH MM-PART3 v2 04/12] xen/arm: mm: Only increment mfn when valid in xen_pt_update

Currently, the MFN will be incremented even if it is invalid. This will
result to have a valid MFN after the first iteration.

While this is not a major problem today, this will be in the future if
the code expect an invalid MFN at every iteration.

Such behavior is prevented by avoiding to increment an invalid MFN.

Signed-off-by: Julien Grall 
Reviewed-by: Andrii Anisov 

---
Changes in v2:
- Move the patch earlier on in the series
- Add Andrii's reviewed-by
---
 xen/arch/arm/mm.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index f956aa6399..9de2a1150f 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -1051,11 +1051,14 @@ static int xen_pt_update(enum xenmap_operation op,
 
 spin_lock(_pt_lock);
 
-for(; addr < addr_end; addr += PAGE_SIZE, mfn = mfn_add(mfn, 1))
+for( ; addr < addr_end; addr += PAGE_SIZE )
 {
 rc = xen_pt_update_entry(op, addr, mfn, flags);
 if ( rc )
 break;
+
+if ( !mfn_eq(mfn, INVALID_MFN) )
+mfn = mfn_add(mfn, 1);
 }
 
 /*
-- 
2.11.0


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

[Xen-devel] [PATCH MM-PART3 v2 11/12] xen/arm: mm: Don't open-code Xen PT update in {set, clear}_fixmap()

{set, clear}_fixmap() are currently open-coding update to the Xen
page-tables. This can be avoided by using the generic helpers
map_pages_to_xen() and destroy_xen_mappings().

Both function are not meant to fail for fixmap, hence the BUG_ON()
checking the return.

Signed-off-by: Julien Grall 
Reviewed-by: Andrii Anisov 

---
Changes in v2:
- Add Andrii's reviewed-by
---
 xen/arch/arm/mm.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 9a40754f44..23ca61e8f0 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -348,19 +348,19 @@ static inline lpae_t mfn_to_xen_entry(mfn_t mfn, unsigned 
attr)
 /* Map a 4k page in a fixmap entry */
 void set_fixmap(unsigned map, mfn_t mfn, unsigned int flags)
 {
-lpae_t pte = mfn_to_xen_entry(mfn, PAGE_AI_MASK(flags));
-pte.pt.table = 1; /* 4k mappings always have this bit set */
-pte.pt.xn = 1;
-write_pte(xen_fixmap + third_table_offset(FIXMAP_ADDR(map)), pte);
-flush_xen_tlb_range_va(FIXMAP_ADDR(map), PAGE_SIZE);
+int res;
+
+res = map_pages_to_xen(FIXMAP_ADDR(map), mfn, 1, flags);
+BUG_ON(res != 0);
 }
 
 /* Remove a mapping from a fixmap entry */
 void clear_fixmap(unsigned map)
 {
-lpae_t pte = {0};
-write_pte(xen_fixmap + third_table_offset(FIXMAP_ADDR(map)), pte);
-flush_xen_tlb_range_va(FIXMAP_ADDR(map), PAGE_SIZE);
+int res;
+
+res = destroy_xen_mappings(FIXMAP_ADDR(map), FIXMAP_ADDR(map) + PAGE_SIZE);
+BUG_ON(res != 0);
 }
 
 /* Create Xen's mappings of memory.
-- 
2.11.0


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

[Xen-devel] [PATCH MM-PART2 RESEND v2 15/19] xen/arm: mm: Introduce DEFINE_PAGE_TABLE{, S} and use it

We have multiple static page-tables defined in arch/arm/mm.c. The
current way to define them is difficult to read and does not help when
making modification.

Two new helpers DEFINE_PAGE_TABLES (to define multiple page-tables) and
DEFINE_PAGE_TABLE (alias of DEFINE_PAGE_TABLES(..., 1)) are introduced
and now used to define static page-tables.

Note that DEFINE_PAGE_TABLES() alignment differs from what is currently
used for allocating page-tables. This is fine because page-tables are
only required to be aligned to a page-size.

Signed-off-by: Julien Grall 

---
Changes in v2:
- Patch in replacement of "Use the shorter version
__aligned(PAGE_SIZE) to align page-tables".
---
 xen/arch/arm/mm.c | 32 ++--
 1 file changed, 18 insertions(+), 14 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 6db7dda0da..9a5f2e1c3f 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -50,6 +50,11 @@ struct domain *dom_xen, *dom_io, *dom_cow;
 #undef mfn_to_virt
 #define mfn_to_virt(mfn) __mfn_to_virt(mfn_x(mfn))
 
+#define DEFINE_PAGE_TABLES(name, nr)\
+lpae_t __aligned(PAGE_SIZE) name[LPAE_ENTRIES * (nr)]
+
+#define DEFINE_PAGE_TABLE(name) DEFINE_PAGE_TABLES(name, 1)
+
 /* Static start-of-day pagetables that we use before the allocators
  * are up. These are used by all CPUs during bringup before switching
  * to the CPUs own pagetables.
@@ -73,13 +78,13 @@ struct domain *dom_xen, *dom_io, *dom_cow;
  * Finally, if EARLY_PRINTK is enabled then xen_fixmap will be mapped
  * by the CPU once it has moved off the 1:1 mapping.
  */
-lpae_t boot_pgtable[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
+DEFINE_PAGE_TABLE(boot_pgtable);
 #ifdef CONFIG_ARM_64
-lpae_t boot_first[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
-lpae_t boot_first_id[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
+DEFINE_PAGE_TABLE(boot_first);
+DEFINE_PAGE_TABLE(boot_first_id);
 #endif
-lpae_t boot_second[LPAE_ENTRIES]  __attribute__((__aligned__(4096)));
-lpae_t boot_third[LPAE_ENTRIES]  __attribute__((__aligned__(4096)));
+DEFINE_PAGE_TABLE(boot_second);
+DEFINE_PAGE_TABLE(boot_third);
 
 /* Main runtime page tables */
 
@@ -93,8 +98,8 @@ lpae_t boot_third[LPAE_ENTRIES]  
__attribute__((__aligned__(4096)));
 
 #ifdef CONFIG_ARM_64
 #define HYP_PT_ROOT_LEVEL 0
-lpae_t xen_pgtable[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
-lpae_t xen_first[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
+static DEFINE_PAGE_TABLE(xen_pgtable);
+static DEFINE_PAGE_TABLE(xen_first);
 #define THIS_CPU_PGTABLE xen_pgtable
 #else
 #define HYP_PT_ROOT_LEVEL 1
@@ -107,17 +112,16 @@ static DEFINE_PER_CPU(lpae_t *, xen_pgtable);
  * DOMHEAP_VIRT_START...DOMHEAP_VIRT_END in 2MB chunks. */
 static DEFINE_PER_CPU(lpae_t *, xen_dommap);
 /* Root of the trie for cpu0, other CPU's PTs are dynamically allocated */
-lpae_t cpu0_pgtable[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
+static DEFINE_PAGE_TABLE(cpu0_pgtable);
 /* cpu0's domheap page tables */
-lpae_t cpu0_dommap[LPAE_ENTRIES*DOMHEAP_SECOND_PAGES]
-__attribute__((__aligned__(4096*DOMHEAP_SECOND_PAGES)));
+static DEFINE_PAGE_TABLES(cpu0_dommap, DOMHEAP_SECOND_PAGES);
 #endif
 
 #ifdef CONFIG_ARM_64
 /* The first page of the first level mapping of the xenheap. The
  * subsequent xenheap first level pages are dynamically allocated, but
  * we need this one to bootstrap ourselves. */
-lpae_t xenheap_first_first[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
+static DEFINE_PAGE_TABLE(xenheap_first_first);
 /* The zeroeth level slot which uses xenheap_first_first. Used because
  * setup_xenheap_mappings otherwise relies on mfn_to_virt which isn't
  * valid for a non-xenheap mapping. */
@@ -131,12 +135,12 @@ static __initdata int xenheap_first_first_slot = -1;
  * addresses from 0 to 0x7fff. Offsets into it are calculated
  * with second_linear_offset(), not second_table_offset().
  */
-lpae_t xen_second[LPAE_ENTRIES*2] __attribute__((__aligned__(4096*2)));
+static DEFINE_PAGE_TABLES(xen_second, 2);
 /* First level page table used for fixmap */
-lpae_t xen_fixmap[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
+DEFINE_PAGE_TABLE(xen_fixmap);
 /* First level page table used to map Xen itself with the XN bit set
  * as appropriate. */
-static lpae_t xen_xenmap[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
+static DEFINE_PAGE_TABLE(xen_xenmap);
 
 /* Non-boot CPUs use this to find the correct pagetables. */
 uint64_t init_ttbr;
-- 
2.11.0


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

[Xen-devel] [PATCH MM-PART2 RESEND v2 01/19] xen/const: Extend the existing macro BIT to take a suffix in parameter

Arm currently provides two macro BIT and BIT_ULL that are only usable
in C and return respectively unsigned long and unsigned long long.

Extending the macros to deal with assembly would be a nice benefits as
it could replace the common pattern to define fields (AC(1, sfx) << X)
easier to read.

Rather than extending the two macros, it was decided to drop BIT_ULL()
and extend the macro BIT() to take a suffix (e.g U, UL, ULL) in
parameter. This would allow to use different suffix without having to
define new macros.

The new extend macro is now moved in include/xen/const.h so it can be
used by anyone in Xen and also avoid to include bitops.h in assembly
code.

Signed-off-by: Julien Grall 

---
Changes in v2:
- Replace "xen/const: Introduce _BITUL and _BITULL"
---
 xen/arch/arm/arm32/insn.c |  2 +-
 xen/arch/arm/arm64/insn.c | 18 +-
 xen/arch/arm/gic-v3-its.c | 13 +++--
 xen/arch/arm/gic-v3-lpi.c |  4 ++--
 xen/arch/arm/guest_walk.c |  8 
 xen/arch/arm/vgic-v3-its.c| 12 ++--
 xen/arch/arm/vgic-v3.c|  2 +-
 xen/arch/arm/vgic.c   |  2 +-
 xen/drivers/char/meson-uart.c | 16 
 xen/drivers/char/mvebu-uart.c | 34 +-
 xen/include/asm-arm/bitops.h  |  2 --
 xen/include/asm-arm/gic_v3_defs.h |  4 ++--
 xen/include/asm-arm/gic_v3_its.h  | 10 +-
 xen/include/xen/const.h   |  2 ++
 14 files changed, 65 insertions(+), 64 deletions(-)

diff --git a/xen/arch/arm/arm32/insn.c b/xen/arch/arm/arm32/insn.c
index 7a5dbc53ec..49953a042a 100644
--- a/xen/arch/arm/arm32/insn.c
+++ b/xen/arch/arm/arm32/insn.c
@@ -58,7 +58,7 @@ int32_t aarch32_get_branch_offset(uint32_t insn)
  * Check the imm signed bit. If the imm is a negative value, we
  * have to extend the imm to a full 32 bit negative value.
  */
-if ( imm & BIT(23) )
+if ( imm & BIT(23, UL) )
 imm |= GENMASK(31, 24);
 
 return (int32_t)(imm << 2);
diff --git a/xen/arch/arm/arm64/insn.c b/xen/arch/arm/arm64/insn.c
index 73c18215a5..22f2bdebd5 100644
--- a/xen/arch/arm/arm64/insn.c
+++ b/xen/arch/arm/arm64/insn.c
@@ -45,40 +45,40 @@ static int __kprobes aarch64_get_imm_shift_mask(enum 
aarch64_insn_imm_type type,
 
switch (type) {
case AARCH64_INSN_IMM_26:
-   mask = BIT(26) - 1;
+   mask = BIT(26, UL) - 1;
shift = 0;
break;
case AARCH64_INSN_IMM_19:
-   mask = BIT(19) - 1;
+   mask = BIT(19, UL) - 1;
shift = 5;
break;
case AARCH64_INSN_IMM_16:
-   mask = BIT(16) - 1;
+   mask = BIT(16, UL) - 1;
shift = 5;
break;
case AARCH64_INSN_IMM_14:
-   mask = BIT(14) - 1;
+   mask = BIT(14, UL) - 1;
shift = 5;
break;
case AARCH64_INSN_IMM_12:
-   mask = BIT(12) - 1;
+   mask = BIT(12, UL) - 1;
shift = 10;
break;
case AARCH64_INSN_IMM_9:
-   mask = BIT(9) - 1;
+   mask = BIT(9, UL) - 1;
shift = 12;
break;
case AARCH64_INSN_IMM_7:
-   mask = BIT(7) - 1;
+   mask = BIT(7, UL) - 1;
shift = 15;
break;
case AARCH64_INSN_IMM_6:
case AARCH64_INSN_IMM_S:
-   mask = BIT(6) - 1;
+   mask = BIT(6, UL) - 1;
shift = 10;
break;
case AARCH64_INSN_IMM_R:
-   mask = BIT(6) - 1;
+   mask = BIT(6, UL) - 1;
shift = 16;
break;
default:
diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index ba4bc00df5..9558bad96a 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -363,11 +363,12 @@ static int its_map_baser(void __iomem *basereg, uint64_t 
regc,
  * attributes), retrying if necessary.
  */
 retry:
-table_size = ROUNDUP(nr_items * entry_size, BIT(BASER_PAGE_BITS(pagesz)));
+table_size = ROUNDUP(nr_items * entry_size,
+ BIT(BASER_PAGE_BITS(pagesz), UL));
 /* The BASE registers support at most 256 pages. */
 table_size = min(table_size, 256U << BASER_PAGE_BITS(pagesz));
 
-buffer = _xzalloc(table_size, BIT(BASER_PAGE_BITS(pagesz)));
+buffer = _xzalloc(table_size, BIT(BASER_PAGE_BITS(pagesz), UL));
 if ( !buffer )
 return -ENOMEM;
 
@@ -483,7 +484,7 @@ static int gicv3_its_init_single_its(struct host_its 
*hw_its)
 case GITS_BASER_TYPE_NONE:
 continue;
 case GITS_BASER_TYPE_DEVICE:
-ret = its_map_baser(basereg, reg, BIT(hw_its->devid_bits));
+ret = its_map_baser(basereg, reg, BIT(hw_its->devid_bits, UL));
 if ( ret )

[Xen-devel] [PATCH MM-PART2 RESEND v2 00/19] xen/arm: Clean-up & fixes in boot/mm code

Hi all,

This is the second part of the boot/memory rework for Xen on Arm. This
part contains mostly clean-up & fixes found during the rework.

The first part of the rework is "xen/arm: TLB flush helpers rework" [1].

For convenience, I provided a branch with all the patches applied based
on staging:

git://xenbits.xen.org/people/julieng/xen-unstable.git branch mm/part2/v2

Cheers,

[1] https://lists.xenproject.org/archives/html/xen-devel/2019-05/msg01109.html

Julien Grall (19):
  xen/const: Extend the existing macro BIT to take a suffix in parameter
  xen/arm: Rename SCTLR_* defines and remove unused one
  xen/arm: processor: Use BIT(.., UL) instead of _AC(1, U) in SCTLR_
defines
  xen/arm: Rework HSCTLR_BASE
  xen/arm: Remove parameter cpuid from start_xen
  xen/arm: Rework secondary_start prototype
  xen/arm64: head: Remove unnecessary comment
  xen/arm64: head: Move earlyprintk messages in .rodata.str
  xen/arm64: head: Correctly report the HW CPU ID
  xen/arm32: head: Correctly report the HW CPU ID
  xen/arm32: head: Don't set MAIR0 and MAIR1
  xen/arm32: head: Always zero r3 before update a page-table entry
  xen/arm32: mm: Avoid to zero and clean cache for CPU0 domheap
  xen/arm32: mm: Avoid cleaning the cache for secondary CPUs page-tables
  xen/arm: mm: Introduce DEFINE_PAGE_TABLE{,S} and use it
  xen/arm: mm: Protect Xen page-table update with a spinlock
  xen/arm: mm: Initialize page-tables earlier
  xen/arm: mm: Check start is always before end in {destroy,
modify}_xen_mappings
  xen/arm: Pair call to set_fixmap with call to clear_fixmap in
copy_from_paddr

 xen/arch/arm/arm32/head.S | 34 --
 xen/arch/arm/arm32/insn.c |  2 +-
 xen/arch/arm/arm64/head.S | 40 +
 xen/arch/arm/arm64/insn.c | 18 
 xen/arch/arm/gic-v3-its.c | 13 +++---
 xen/arch/arm/gic-v3-lpi.c |  4 +-
 xen/arch/arm/guest_walk.c | 10 ++---
 xen/arch/arm/kernel.c |  3 +-
 xen/arch/arm/mm.c | 62 +-
 xen/arch/arm/setup.c  |  7 ++-
 xen/arch/arm/smpboot.c|  4 +-
 xen/arch/arm/traps.c  |  6 +--
 xen/arch/arm/vgic-v3-its.c| 12 ++---
 xen/arch/arm/vgic-v3.c|  2 +-
 xen/arch/arm/vgic.c   |  2 +-
 xen/drivers/char/meson-uart.c | 16 +++
 xen/drivers/char/mvebu-uart.c | 34 +++---
 xen/include/asm-arm/asm_defns.h   |  5 +++
 xen/include/asm-arm/bitops.h  |  2 -
 xen/include/asm-arm/gic_v3_defs.h |  4 +-
 xen/include/asm-arm/gic_v3_its.h  | 10 ++---
 xen/include/asm-arm/p2m.h |  4 +-
 xen/include/asm-arm/processor.h   | 93 ++-
 xen/include/xen/const.h   |  2 +
 24 files changed, 201 insertions(+), 188 deletions(-)

-- 
2.11.0


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

[Xen-devel] [PATCH MM-PART2 RESEND v2 09/19] xen/arm64: head: Correctly report the HW CPU ID

There are no reason to consider the HW CPU ID will be 0 when the
processor is part of a uniprocessor system. At best, this will result to
conflicting output as the rest of Xen use the value directly read from
MPIDR_EL1.

So remove the zeroing and logic to check if the CPU is part of a
uniprocessor system.

Signed-off-by: Julien Grall 
Reviewed-by: Andrii Anisov 

---
Changes in v2:
- Add Andrii's reviewed-by
---
 xen/arch/arm/arm64/head.S | 6 --
 1 file changed, 6 deletions(-)

diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index b957eb90fb..08094a273e 100644
--- a/xen/arch/arm/arm64/head.S
+++ b/xen/arch/arm/arm64/head.S
@@ -277,15 +277,9 @@ GLOBAL(init_secondary)
 mov   x26, #1/* X26 := skip_zero_bss */
 
 common_start:
-mov   x24, #0/* x24 := CPU ID. Initialy zero until we
-  * find that multiprocessor extensions are
-  * present and the system is SMP  */
 mrs   x0, mpidr_el1
-tbnz  x0, _MPIDR_UP, 1f  /* Uniprocessor system? */
-
 ldr   x13, =(~MPIDR_HWID_MASK)
 bic   x24, x0, x13   /* Mask out flags to get CPU ID */
-1:
 
 /* Non-boot CPUs wait here until __cpu_up is ready for them */
 cbz   x22, 1f
-- 
2.11.0


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

[Xen-devel] [PATCH MM-PART2 RESEND v2 02/19] xen/arm: Rename SCTLR_* defines and remove unused one

The SCTLR_* are currently used for SCTLR/HSCTLR (arm32) and
SCTLR_EL1/SCTLR_EL2 (arm64).

The naming scheme is actually quite confusing because they may only be
defined for an archicture (or even an exception level). So it is not easy
for the developer to know which one to use.

The naming scheme is reworked by adding Axx_ELx in each define:
* xx is replaced by 32 or 64 if specific to an architecture
* x is replaced by 2 (hypervisor) or 1 (kernel) if specific to an
exception level

While doing the renaming, remove the unused defines (or at least the ones
that are unlikely going to be used).

Signed-off-by: Julien Grall 
Reviewed-by: Andrii Anisov 

---
Changes in v2:
- Fix build on arm32
- Add Andrii's reviewed-by
---
 xen/arch/arm/arm32/head.S   |  5 +++--
 xen/arch/arm/arm64/head.S   |  4 ++--
 xen/arch/arm/guest_walk.c   |  2 +-
 xen/arch/arm/mm.c   |  2 +-
 xen/arch/arm/traps.c|  6 +++---
 xen/include/asm-arm/p2m.h   |  4 +++-
 xen/include/asm-arm/processor.h | 37 +
 7 files changed, 30 insertions(+), 30 deletions(-)

diff --git a/xen/arch/arm/arm32/head.S b/xen/arch/arm/arm32/head.S
index 390a505e05..454d24537c 100644
--- a/xen/arch/arm/arm32/head.S
+++ b/xen/arch/arm/arm32/head.S
@@ -244,7 +244,7 @@ cpu_init_done:
  * Alignment checking enabled,
  * MMU translation disabled (for now).
  */
-ldr   r0, =(HSCTLR_BASE|SCTLR_A)
+ldr   r0, =(HSCTLR_BASE|SCTLR_Axx_ELx_A)
 mcr   CP32(r0, HSCTLR)
 
 /*
@@ -369,7 +369,8 @@ virtphys_clash:
 
 ldr   r1, =paging/* Explicit vaddr, not RIP-relative */
 mrc   CP32(r0, HSCTLR)
-orr   r0, r0, #(SCTLR_M|SCTLR_C) /* Enable MMU and D-cache */
+/* Enable MMU and D-cache */
+orr   r0, r0, #(SCTLR_Axx_ELx_M|SCTLR_Axx_ELx_C)
 dsb  /* Flush PTE writes and finish reads */
 mcr   CP32(r0, HSCTLR)   /* now paging is enabled */
 isb  /* Now, flush the icache */
diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index 4589a37874..8a6be3352e 100644
--- a/xen/arch/arm/arm64/head.S
+++ b/xen/arch/arm/arm64/head.S
@@ -514,8 +514,8 @@ virtphys_clash:
 
 ldr   x1, =paging/* Explicit vaddr, not RIP-relative */
 mrs   x0, SCTLR_EL2
-orr   x0, x0, #SCTLR_M   /* Enable MMU */
-orr   x0, x0, #SCTLR_C   /* Enable D-cache */
+orr   x0, x0, #SCTLR_Axx_ELx_M  /* Enable MMU */
+orr   x0, x0, #SCTLR_Axx_ELx_C  /* Enable D-cache */
 dsb   sy /* Flush PTE writes and finish reads */
 msr   SCTLR_EL2, x0  /* now paging is enabled */
 isb  /* Now, flush the icache */
diff --git a/xen/arch/arm/guest_walk.c b/xen/arch/arm/guest_walk.c
index f10d2e9f76..c6d6e23bf5 100644
--- a/xen/arch/arm/guest_walk.c
+++ b/xen/arch/arm/guest_walk.c
@@ -612,7 +612,7 @@ bool guest_walk_tables(const struct vcpu *v, vaddr_t gva,
 *perms = GV2M_READ;
 
 /* If the MMU is disabled, there is no need to translate the gva. */
-if ( !(sctlr & SCTLR_M) )
+if ( !(sctlr & SCTLR_Axx_ELx_M) )
 {
 *ipa = gva;
 
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 9d584e4cbf..e090afb976 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -609,7 +609,7 @@ void __init remove_early_mappings(void)
  */
 static void xen_pt_enforce_wnx(void)
 {
-WRITE_SYSREG32(READ_SYSREG32(SCTLR_EL2) | SCTLR_WXN, SCTLR_EL2);
+WRITE_SYSREG32(READ_SYSREG32(SCTLR_EL2) | SCTLR_Axx_ELx_WXN, SCTLR_EL2);
 /*
  * The TLBs may cache SCTLR_EL2.WXN. So ensure it is synchronized
  * before flushing the TLBs.
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 1aba970415..6c757c12a8 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -392,9 +392,9 @@ static void cpsr_switch_mode(struct cpu_user_regs *regs, 
int mode)
 regs->cpsr |= PSR_IRQ_MASK;
 if ( mode == PSR_MODE_ABT )
 regs->cpsr |= PSR_ABT_MASK;
-if ( sctlr & SCTLR_TE )
+if ( sctlr & SCTLR_A32_ELx_TE )
 regs->cpsr |= PSR_THUMB;
-if ( sctlr & SCTLR_EE )
+if ( sctlr & SCTLR_Axx_ELx_EE )
 regs->cpsr |= PSR_BIG_ENDIAN;
 }
 
@@ -402,7 +402,7 @@ static vaddr_t exception_handler32(vaddr_t offset)
 {
 uint32_t sctlr = READ_SYSREG32(SCTLR_EL1);
 
-if ( sctlr & SCTLR_V )
+if ( sctlr & SCTLR_A32_EL1_V )
 return 0x + offset;
 else /* always have security exceptions */
 return READ_SYSREG(VBAR_EL1) + offset;
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index 041dea827c..2f89bb00c3 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -391,10 +391,12 @@ static inline int set_foreign_p2m_entry(struct domain *d, 
unsigned long gfn,
  */
 static inline bool

[Xen-devel] [PATCH MM-PART2 RESEND v2 04/19] xen/arm: Rework HSCTLR_BASE

The current value of HSCTLR_BASE for Arm64 is pretty wrong. It would
actually turn on SCTLR_EL2.nAA (bit 6) on hardware implementing
ARMv8.4-LSE.

Furthermore, the documentation of what is cleared/set in SCTLR_EL2 is
also not correct and looks like to be a verbatim copy from Arm32.

HSCTLR_BASE is replaced with a bunch of per-architecture new defines
helping to understand better what is the initialie value for
SCTLR_EL2/HSCTLR.

Note the defines *_CLEAR are only used to check the state of each bits
are known.

Lastly, the documentation is dropped from arm{32,64}/head.S as it would
be pretty easy to get out-of-sync with the definitions.

Signed-off-by: Julien Grall 

---
Changes in v2:
- Use BIT(..., UL) instead of _BITUL
---
 xen/arch/arm/arm32/head.S   | 12 +
 xen/arch/arm/arm64/head.S   | 10 +---
 xen/include/asm-arm/processor.h | 54 -
 3 files changed, 55 insertions(+), 21 deletions(-)

diff --git a/xen/arch/arm/arm32/head.S b/xen/arch/arm/arm32/head.S
index 454d24537c..8a98607459 100644
--- a/xen/arch/arm/arm32/head.S
+++ b/xen/arch/arm/arm32/head.S
@@ -234,17 +234,7 @@ cpu_init_done:
 ldr   r0, 
=(TCR_RES1|TCR_SH0_IS|TCR_ORGN0_WBWA|TCR_IRGN0_WBWA|TCR_T0SZ(0))
 mcr   CP32(r0, HTCR)
 
-/*
- * Set up the HSCTLR:
- * Exceptions in LE ARM,
- * Low-latency IRQs disabled,
- * Write-implies-XN disabled (for now),
- * D-cache disabled (for now),
- * I-cache enabled,
- * Alignment checking enabled,
- * MMU translation disabled (for now).
- */
-ldr   r0, =(HSCTLR_BASE|SCTLR_Axx_ELx_A)
+ldr   r0, =HSCTLR_SET
 mcr   CP32(r0, HSCTLR)
 
 /*
diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index 8a6be3352e..4fe904c51d 100644
--- a/xen/arch/arm/arm64/head.S
+++ b/xen/arch/arm/arm64/head.S
@@ -363,15 +363,7 @@ skip_bss:
 
 msr   tcr_el2, x0
 
-/* Set up the SCTLR_EL2:
- * Exceptions in LE ARM,
- * Low-latency IRQs disabled,
- * Write-implies-XN disabled (for now),
- * D-cache disabled (for now),
- * I-cache enabled,
- * Alignment checking disabled,
- * MMU translation disabled (for now). */
-ldr   x0, =(HSCTLR_BASE)
+ldr   x0, =SCTLR_EL2_SET
 msr   SCTLR_EL2, x0
 
 /* Ensure that any exceptions encountered at EL2
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index bbcba061ca..9afc3786c5 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -127,6 +127,9 @@
 #define SCTLR_A32_ELx_TEBIT(30, UL)
 #define SCTLR_A32_ELx_FIBIT(21, UL)
 
+/* Common bits for SCTLR_ELx for Arm64 */
+#define SCTLR_A64_ELx_SABIT(3, UL)
+
 /* Common bits for SCTLR_ELx on all architectures */
 #define SCTLR_Axx_ELx_EEBIT(25, UL)
 #define SCTLR_Axx_ELx_WXN   BIT(19, UL)
@@ -135,7 +138,56 @@
 #define SCTLR_Axx_ELx_A BIT(1, UL)
 #define SCTLR_Axx_ELx_M BIT(0, UL)
 
-#define HSCTLR_BASE _AC(0x30c51878,U)
+#ifdef CONFIG_ARM_32
+
+#define HSCTLR_RES1 (BIT( 3, UL) | BIT( 4, UL) | BIT( 5, UL) |\
+ BIT( 6, UL) | BIT(11, UL) | BIT(16, UL) |\
+ BIT(18, UL) | BIT(22, UL) | BIT(23, UL) |\
+ BIT(28, UL) | BIT(29, UL))
+
+#define HSCTLR_RES0 (BIT(7, UL)  | BIT(8, UL)  | BIT(9, UL)  | BIT(10, UL) 
|\
+ BIT(13, UL) | BIT(14, UL) | BIT(15, UL) | BIT(17, UL) 
|\
+ BIT(20, UL) | BIT(24, UL) | BIT(26, UL) | BIT(27, UL) 
|\
+ BIT(31, UL))
+
+/* Initial value for HSCTLR */
+#define HSCTLR_SET  (HSCTLR_RES1| SCTLR_Axx_ELx_A   | SCTLR_Axx_ELx_I)
+
+#define HSCTLR_CLEAR(HSCTLR_RES0| SCTLR_Axx_ELx_M   |\
+ SCTLR_Axx_ELx_C| SCTLR_Axx_ELx_WXN |\
+ SCTLR_A32_ELx_FI   | SCTLR_Axx_ELx_EE  |\
+ SCTLR_A32_ELx_TE)
+
+#if (HSCTLR_SET ^ HSCTLR_CLEAR) != 0xU
+#error "Inconsistent HSCTLR set/clear bits"
+#endif
+
+#else
+
+#define SCTLR_EL2_RES1  (BIT( 4, UL) | BIT( 5, UL) | BIT(11, UL) |\
+ BIT(16, UL) | BIT(18, UL) | BIT(22, UL) |\
+ BIT(23, UL) | BIT(28, UL) | BIT(29, UL))
+
+#define SCTLR_EL2_RES0  (BIT( 6, UL) | BIT( 7, UL) | BIT( 8, UL) |\
+ BIT( 9, UL) | BIT(10, UL) | BIT(13, UL) |\
+ BIT(14, UL) | BIT(15, UL) | BIT(17, UL) |\
+ BIT(20, UL) | BIT(21, UL) | BIT(24, UL) |\
+ BIT(26, UL) | BIT(27, UL) | BIT(30, UL) |\
+ BIT(31, UL) | (0xULL << 32))
+
+/* Initial value for SCTLR_EL2 */
+#define SCTLR_EL2_SET   (SCTLR_EL2_RES1 | SCTLR_A64_ELx_SA  |\
+ SCTLR_Axx_ELx_I)
+
+#define SCTLR_EL2_CLEAR (SCTLR_EL2_RES0 |

[Xen-devel] [PATCH MM-PART2 RESEND v2 14/19] xen/arm32: mm: Avoid cleaning the cache for secondary CPUs page-tables

The page-table walker is configured to use the same shareability and
cacheability as the access performed when updating the page-tables. This
means cleaning the cache for secondary CPUs runtime page-tables is
unnecessary.

Signed-off-by: Julien Grall 
Reviewed-by: Andrii Anisov 

---
Changes in v2:
- Add Andrii's reviewed-by
---
 xen/arch/arm/mm.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index cda2847d00..6db7dda0da 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -769,9 +769,6 @@ int init_secondary_pagetables(int cpu)
 write_pte([first_table_offset(DOMHEAP_VIRT_START+i*FIRST_SIZE)], 
pte);
 }
 
-clean_dcache_va_range(first, PAGE_SIZE);
-clean_dcache_va_range(domheap, DOMHEAP_SECOND_PAGES*PAGE_SIZE);
-
 per_cpu(xen_pgtable, cpu) = first;
 per_cpu(xen_dommap, cpu) = domheap;
 
-- 
2.11.0


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

[Xen-devel] [PATCH MM-PART2 RESEND v2 06/19] xen/arm: Rework secondary_start prototype

None of the parameters of secondary_start are actually used. So turn
secondary_start to a function with no parameters.

Also modify the assembly code to avoid setting-up the registers before
calling secondary_start.

Signed-off-by: Julien Grall 

- Re-order the patch with "xen/arm: Remove parameter cpuid from
start_xen".
---
 xen/arch/arm/arm32/head.S | 4 ++--
 xen/arch/arm/arm64/head.S | 3 ++-
 xen/arch/arm/smpboot.c| 4 +---
 3 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/arm32/head.S b/xen/arch/arm/arm32/head.S
index cb8a3bf829..9f40face98 100644
--- a/xen/arch/arm/arm32/head.S
+++ b/xen/arch/arm/arm32/head.S
@@ -445,9 +445,9 @@ launch:
 ldr   sp, [r0]
 add   sp, #STACK_SIZE/* (which grows down from the top). */
 sub   sp, #CPUINFO_sizeof/* Make room for CPU save record */
-mov   r0, r10/* Marshal args: - phys_offset */
-mov   r1, r8 /*   - DTB address */
 teq   r12, #0
+moveq r0, r10/* Marshal args: - phys_offset */
+moveq r1, r8 /*   - DTB address */
 beq   start_xen  /* and disappear into the land of C */
 b start_secondary/* (to the appropriate entry point) */
 
diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index 075013878e..cb30d6f22e 100644
--- a/xen/arch/arm/arm64/head.S
+++ b/xen/arch/arm/arm64/head.S
@@ -582,9 +582,10 @@ launch:
 sub   x0, x0, #CPUINFO_sizeof /* Make room for CPU save record */
 mov   sp, x0
 
+cbnz  x22, 1f
+
 mov   x0, x20/* Marshal args: - phys_offset */
 mov   x1, x21/*   - FDT */
-cbnz  x22, 1f
 b start_xen  /* and disappear into the land of C */
 1:
 b start_secondary/* (to the appropriate entry point) */
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index f756444362..00b64c3322 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -297,9 +297,7 @@ smp_prepare_cpus(void)
 }
 
 /* Boot the current CPU */
-void start_secondary(unsigned long boot_phys_offset,
- unsigned long fdt_paddr,
- unsigned long hwid)
+void start_secondary(void)
 {
 unsigned int cpuid = init_data.cpuid;
 
-- 
2.11.0


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

[Xen-devel] [PATCH MM-PART2 RESEND v2 17/19] xen/arm: mm: Initialize page-tables earlier

Since commit f60658c6ae "xen/arm: Stop relocating Xen", the function
setup_page_tables() does not require any information from the FDT.

So the initialization of the page-tables can be done much earlier in the
boot process. The earliest setup_page_tables() can be called is after
traps have been initialized, so we can get backtrace if an error
occurred.

Moving the initialization of the page-tables also avoid the dance to map
the FDT again in the new set of page-tables.

Signed-off-by: Julien Grall 
Reviewed-by: Andrii Anisov 

---
Changes in v2:
- Add Andrii's reviewed-by
---
 xen/arch/arm/mm.c| 12 +++-
 xen/arch/arm/setup.c |  4 ++--
 2 files changed, 5 insertions(+), 11 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 7502a14760..eacc1647e0 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -550,7 +550,7 @@ static inline lpae_t pte_of_xenaddr(vaddr_t va)
 return mfn_to_xen_entry(maddr_to_mfn(ma), MT_NORMAL);
 }
 
-/* Map the FDT in the early boot page table */
+/* Map the FDT in the runtime page table */
 void * __init early_fdt_map(paddr_t fdt_paddr)
 {
 /* We are using 2MB superpage for mapping the FDT */
@@ -573,7 +573,7 @@ void * __init early_fdt_map(paddr_t fdt_paddr)
 /* The FDT is mapped using 2MB superpage */
 BUILD_BUG_ON(BOOT_FDT_VIRT_START % SZ_2M);
 
-create_mappings(boot_second, BOOT_FDT_VIRT_START, paddr_to_pfn(base_paddr),
+create_mappings(xen_second, BOOT_FDT_VIRT_START, paddr_to_pfn(base_paddr),
 SZ_2M >> PAGE_SHIFT, SZ_2M);
 
 offset = fdt_paddr % SECOND_SIZE;
@@ -588,7 +588,7 @@ void * __init early_fdt_map(paddr_t fdt_paddr)
 
 if ( (offset + size) > SZ_2M )
 {
-create_mappings(boot_second, BOOT_FDT_VIRT_START + SZ_2M,
+create_mappings(xen_second, BOOT_FDT_VIRT_START + SZ_2M,
 paddr_to_pfn(base_paddr + SZ_2M),
 SZ_2M >> PAGE_SHIFT, SZ_2M);
 }
@@ -699,12 +699,6 @@ void __init setup_pagetables(unsigned long 
boot_phys_offset)
 pte.pt.table = 1;
 xen_second[second_table_offset(FIXMAP_ADDR(0))] = pte;
 
-/* ... DTB */
-pte = boot_second[second_table_offset(BOOT_FDT_VIRT_START)];
-xen_second[second_table_offset(BOOT_FDT_VIRT_START)] = pte;
-pte = boot_second[second_table_offset(BOOT_FDT_VIRT_START + SZ_2M)];
-xen_second[second_table_offset(BOOT_FDT_VIRT_START + SZ_2M)] = pte;
-
 #ifdef CONFIG_ARM_64
 ttbr = (uintptr_t) xen_pgtable + phys_offset;
 #else
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 2f714d8b37..889da40d8d 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -759,6 +759,8 @@ void __init start_xen(unsigned long boot_phys_offset,
 /* Initialize traps early allow us to get backtrace when an error occurred 
*/
 init_traps();
 
+setup_pagetables(boot_phys_offset);
+
 smp_clear_cpu_maps();
 
 device_tree_flattened = early_fdt_map(fdt_paddr);
@@ -780,8 +782,6 @@ void __init start_xen(unsigned long boot_phys_offset,
  (paddr_t)(uintptr_t)(_end - _start + 1), false);
 BUG_ON(!xen_bootmodule);
 
-setup_pagetables(boot_phys_offset);
-
 setup_mm(fdt_paddr, fdt_size);
 
 /* Parse the ACPI tables for possible boot-time configuration */
-- 
2.11.0


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

[Xen-devel] [PATCH MM-PART2 RESEND v2 19/19] xen/arm: Pair call to set_fixmap with call to clear_fixmap in copy_from_paddr

At the moment, set_fixmap may replace a valid entry without following
the break-before-make sequence. This may result to TLB conflict abort.

Rather than dealing with Break-Before-Make in set_fixmap, every call to
set_fixmap is paired with a call to clear_fixmap.

Signed-off-by: Julien Grall 
Reviewed-by: Andrii Anisov 

---
Changes in v2:
- Add Andrii's reviewed-by
---
 xen/arch/arm/kernel.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index e3ffdb2fa1..389bef2afa 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -58,13 +58,12 @@ void __init copy_from_paddr(void *dst, paddr_t paddr, 
unsigned long len)
 set_fixmap(FIXMAP_MISC, maddr_to_mfn(paddr), PAGE_HYPERVISOR_WC);
 memcpy(dst, src + s, l);
 clean_dcache_va_range(dst, l);
+clear_fixmap(FIXMAP_MISC);
 
 paddr += l;
 dst += l;
 len -= l;
 }
-
-clear_fixmap(FIXMAP_MISC);
 }
 
 static void __init place_modules(struct kernel_info *info,
-- 
2.11.0


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

[Xen-devel] [PATCH MM-PART2 RESEND v2 07/19] xen/arm64: head: Remove unnecessary comment

So far, we don't have specific core initialization at boot. So remove
the comment.

Signed-off-by: Julien Grall 
Reviewed-by: Andrii Anisov 

---
Changes in v2:
- Fix typo in the commit message
- Add Andrii's reviewed-by
---
 xen/arch/arm/arm64/head.S | 2 --
 1 file changed, 2 deletions(-)

diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index cb30d6f22e..ad446e7345 100644
--- a/xen/arch/arm/arm64/head.S
+++ b/xen/arch/arm/arm64/head.S
@@ -344,8 +344,6 @@ el2:PRINT("- Xen starting at EL2 -\r\n")
 skip_bss:
 PRINT("- Setting up control registers -\r\n")
 
-/*  call PROCINFO_cpu_init here */
-
 /* Set up memory attribute type tables */
 ldr   x0, =MAIRVAL
 msr   mair_el2, x0
-- 
2.11.0


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

[Xen-devel] [PATCH MM-PART2 RESEND v2 13/19] xen/arm32: mm: Avoid to zero and clean cache for CPU0 domheap

The page-table walker is configured to use the same shareability and
cacheability as the access performed when updating the page-tables. This
means cleaning the cache for CPU0 domheap is unnecessary.

Furthermore, CPU0 page-tables are part of Xen binary and will already be
zeroed before been used. So it is pointless to zero the domheap again.

Signed-off-by: Julien Grall 
Reviewed-by: Andrii Anisov 

---
Changes in v2:
- Tweak a bit the commit message
- Add Andrii's reviewed-by
---
 xen/arch/arm/mm.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index e090afb976..cda2847d00 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -724,11 +724,6 @@ void __init setup_pagetables(unsigned long 
boot_phys_offset)
 #ifdef CONFIG_ARM_32
 per_cpu(xen_pgtable, 0) = cpu0_pgtable;
 per_cpu(xen_dommap, 0) = cpu0_dommap;
-
-/* Make sure it is clear */
-memset(this_cpu(xen_dommap), 0, DOMHEAP_SECOND_PAGES*PAGE_SIZE);
-clean_dcache_va_range(this_cpu(xen_dommap),
-  DOMHEAP_SECOND_PAGES*PAGE_SIZE);
 #endif
 }
 
-- 
2.11.0


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

[Xen-devel] [PATCH MM-PART2 RESEND v2 08/19] xen/arm64: head: Move earlyprintk messages in .rodata.str

At the moment, the earlyprintk messages are interleaved with the
instructions. This makes more difficult to read the objdump output.

Introduce a new macro to add a string in .rodata.str and use it for all
the earlyprintk messages.

Signed-off-by: Julien Grall 
Reviewed-by: Andrii Anisov 

---

I haven't done a similar change in arm32 yet because the compiler will
throw an error when using 'adr' when load an address from a different
section (see A5-200 in ARM DDI 0406C.a for the technical reason).
The change is likely to be more elaborate.

Changes in v2:
- Add Andrii's reviewed-by
---
 xen/arch/arm/arm64/head.S   | 14 +-
 xen/include/asm-arm/asm_defns.h |  5 +
 2 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index ad446e7345..b957eb90fb 100644
--- a/xen/arch/arm/arm64/head.S
+++ b/xen/arch/arm/arm64/head.S
@@ -81,13 +81,10 @@
 /* Macro to print a string to the UART, if there is one.
  * Clobbers x0-x3. */
 #ifdef CONFIG_EARLY_PRINTK
-#define PRINT(_s)   \
-adr   x0, 98f ; \
-blputs; \
-b 99f ; \
-98: .asciz _s ; \
-.align 2  ; \
-99:
+#define PRINT(_s)   \
+adr   x0, 98f ; \
+blputs; \
+RODATA_STR(98, _s)
 #else /* CONFIG_EARLY_PRINTK */
 #define PRINT(s)
 #endif /* !CONFIG_EARLY_PRINTK */
@@ -633,8 +630,7 @@ init_uart:
 #endif
 adr   x0, 1f
 b puts
-1:  .asciz "- UART enabled -\r\n"
-.align 4
+RODATA_STR(1, "- UART enabled -\r\n")
 
 /* Print early debug messages.
  * x0: Nul-terminated string to print.
diff --git a/xen/include/asm-arm/asm_defns.h b/xen/include/asm-arm/asm_defns.h
index 02be83e2b3..3f21def0ab 100644
--- a/xen/include/asm-arm/asm_defns.h
+++ b/xen/include/asm-arm/asm_defns.h
@@ -16,6 +16,11 @@
 # error "unknown ARM variant"
 #endif
 
+#define RODATA_STR(label, msg)  \
+.pushsection .rodata.str, "aMS", %progbits, 1 ; \
+label:  .asciz msg; \
+.popsection
+
 #endif /* __ARM_ASM_DEFNS_H__ */
 /*
  * Local variables:
-- 
2.11.0


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

[Xen-devel] [PATCH MM-PART2 RESEND v2 16/19] xen/arm: mm: Protect Xen page-table update with a spinlock

The function create_xen_entries() may be called concurrently. For
instance, while the vmap allocation is protected by a spinlock, the
mapping is not.

The implementation create_xen_entries() contains quite a few TOCTOU
races such as when allocating the 3rd-level page-tables.

Thankfully, they are pretty hard to reach as page-tables are allocated
once and never released. Yet it is possible, so we need to protect with
a spinlock to avoid corrupting the page-tables.

Signed-off-by: Julien Grall 

---
Changes in v2:
- Rework the commit message
---
 xen/arch/arm/mm.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 9a5f2e1c3f..7502a14760 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -974,6 +974,8 @@ enum xenmap_operation {
 RESERVE
 };
 
+static DEFINE_SPINLOCK(xen_pt_lock);
+
 static int create_xen_entries(enum xenmap_operation op,
   unsigned long virt,
   mfn_t mfn,
@@ -985,6 +987,8 @@ static int create_xen_entries(enum xenmap_operation op,
 lpae_t pte, *entry;
 lpae_t *third = NULL;
 
+spin_lock(_pt_lock);
+
 for(; addr < addr_end; addr += PAGE_SIZE, mfn = mfn_add(mfn, 1))
 {
 entry = _second[second_linear_offset(addr)];
@@ -1059,6 +1063,8 @@ out:
  */
 flush_xen_tlb_range_va(virt, PAGE_SIZE * nr_mfns);
 
+spin_unlock(_pt_lock);
+
 return rc;
 }
 
-- 
2.11.0


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

[Xen-devel] [PATCH MM-PART2 RESEND v2 18/19] xen/arm: mm: Check start is always before end in {destroy, modify}_xen_mappings

The two helpers {destroy, modify}_xen_mappings don't check that the
start is always before the end. This should never happen but if it
happens, it will result to unexpected behavior.

Catch such issues earlier on by adding an ASSERT in destroy_xen_mappings
and modify_xen_mappings.

Signed-off-by: Julien Grall 
Reviewed-by: Andrii Anisov 

---
Changes in v2:
- Add Andrii's reviewed-by
---
 xen/arch/arm/mm.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index eacc1647e0..b408de7c75 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -1077,11 +1077,13 @@ int populate_pt_range(unsigned long virt, unsigned long 
nr_mfns)
 
 int destroy_xen_mappings(unsigned long v, unsigned long e)
 {
+ASSERT(v <= e);
 return create_xen_entries(REMOVE, v, INVALID_MFN, (e - v) >> PAGE_SHIFT, 
0);
 }
 
 int modify_xen_mappings(unsigned long s, unsigned long e, unsigned int flags)
 {
+ASSERT(s <= e);
 return create_xen_entries(MODIFY, s, INVALID_MFN, (e - s) >> PAGE_SHIFT,
   flags);
 }
-- 
2.11.0


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

[Xen-devel] [PATCH MM-PART2 RESEND v2 10/19] xen/arm32: head: Correctly report the HW CPU ID

There are no reason to consider the HW CPU ID will be 0 when the
processor is part of a uniprocessor system. At best, this will result to
conflicting output as the rest of Xen use the value directly read from
MPIDR.

So remove the zeroing and logic to check if the CPU is part of a
uniprocessor system.

Signed-off-by: Julien Grall 
Reviewed-by: Andrii Anisov 

---
Changes in v2:
- Add Andrii's reviewed-by
---
 xen/arch/arm/arm32/head.S | 8 
 1 file changed, 8 deletions(-)

diff --git a/xen/arch/arm/arm32/head.S b/xen/arch/arm/arm32/head.S
index 9f40face98..d42a13556c 100644
--- a/xen/arch/arm/arm32/head.S
+++ b/xen/arch/arm/arm32/head.S
@@ -124,16 +124,8 @@ GLOBAL(init_secondary)
 mov   r12, #1/* r12 := is_secondary_cpu */
 
 common_start:
-mov   r7, #0 /* r7 := CPU ID. Initialy zero until we
-  * find that multiprocessor extensions are
-  * present and the system is SMP */
 mrc   CP32(r1, MPIDR)
-tst   r1, #MPIDR_SMP /* Multiprocessor extension supported? */
-beq   1f
-tst   r1, #MPIDR_UP  /* Uniprocessor system? */
-bne   1f
 bic   r7, r1, #(~MPIDR_HWID_MASK) /* Mask out flags to get CPU ID */
-1:
 
 /* Non-boot CPUs wait here until __cpu_up is ready for them */
 teq   r12, #0
-- 
2.11.0


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

[Xen-devel] [PATCH MM-PART2 RESEND v2 11/19] xen/arm32: head: Don't set MAIR0 and MAIR1

The co-processor registers MAIR0 and MAIR1 are managed by EL1. So there
are no need to initialize them during Xen boot.

Signed-off-by: Julien Grall 
Reviewed-by: Andrii Anisov 

---
Changes in v2
- Add Andrii's reviewed-by
---
 xen/arch/arm/arm32/head.S | 2 --
 1 file changed, 2 deletions(-)

diff --git a/xen/arch/arm/arm32/head.S b/xen/arch/arm/arm32/head.S
index d42a13556c..3448817aab 100644
--- a/xen/arch/arm/arm32/head.S
+++ b/xen/arch/arm/arm32/head.S
@@ -212,8 +212,6 @@ cpu_init_done:
 /* Set up memory attribute type tables */
 ldr   r0, =MAIR0VAL
 ldr   r1, =MAIR1VAL
-mcr   CP32(r0, MAIR0)
-mcr   CP32(r1, MAIR1)
 mcr   CP32(r0, HMAIR0)
 mcr   CP32(r1, HMAIR1)
 
-- 
2.11.0


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

[Xen-devel] [PATCH MM-PART2 RESEND v2 12/19] xen/arm32: head: Always zero r3 before update a page-table entry

The boot code is using r2 and r3 to hold the page-table entry value.
While r2 is always updated before storing the value, this is not always
the case for r3.

Thankfully today, r3 will always be zero when we care. But this is
difficult to track and error-prone.

So always zero r3 within the few instructions before the write the
page-table entry.

Signed-off-by: Julien Grall 

---
Changes in v2:
- Use 0x0 instead of 0
- Remove a duplicate mov r3, #0
---
 xen/arch/arm/arm32/head.S | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/arm32/head.S b/xen/arch/arm/arm32/head.S
index 3448817aab..18ded49a04 100644
--- a/xen/arch/arm/arm32/head.S
+++ b/xen/arch/arm/arm32/head.S
@@ -270,6 +270,7 @@ cpu_init_done:
 orr   r2, r2, #PT_UPPER(MEM) /* r2:r3 := section map */
 orr   r2, r2, #PT_LOWER(MEM)
 lsl   r1, r1, #3 /* r1 := Slot offset */
+mov   r3, #0x0
 strd  r2, r3, [r4, r1]   /* Mapping of paddr(start) */
 mov   r6, #1 /* r6 := identity map now in place */
 
@@ -372,11 +373,11 @@ paging:
 
 /* Add UART to the fixmap table */
 ldr   r1, =xen_fixmap/* r1 := vaddr (xen_fixmap) */
-mov   r3, #0
 lsr   r2, r11, #THIRD_SHIFT
 lsl   r2, r2, #THIRD_SHIFT   /* 4K aligned paddr of UART */
 orr   r2, r2, #PT_UPPER(DEV_L3)
 orr   r2, r2, #PT_LOWER(DEV_L3) /* r2:r3 := 4K dev map including UART 
*/
+mov   r3, #0x0
 strd  r2, r3, [r1, #(FIXMAP_CONSOLE*8)] /* Map it in the first 
fixmap's slot */
 1:
 
@@ -388,6 +389,7 @@ paging:
 orr   r2, r2, #PT_LOWER(PT)  /* r2:r3 := table map of xen_fixmap */
 ldr   r4, =FIXMAP_ADDR(0)
 mov   r4, r4, lsr #(SECOND_SHIFT - 3)   /* r4 := Slot for FIXMAP(0) */
+mov   r3, #0x0
 strd  r2, r3, [r1, r4]   /* Map it in the fixmap's slot */
 
 /* Use a virtual address to access the UART. */
-- 
2.11.0


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

[Xen-devel] [PATCH MM-PART2 RESEND v2 05/19] xen/arm: Remove parameter cpuid from start_xen

The parameter cpuid is not used by start_xen. So remove it.

Signed-off-by: Julien Grall 

---
- Re-order the patch with "xen/arm: Rework secondary_start
prototype"
---
 xen/arch/arm/arm32/head.S | 1 -
 xen/arch/arm/arm64/head.S | 1 -
 xen/arch/arm/setup.c  | 3 +--
 3 files changed, 1 insertion(+), 4 deletions(-)

diff --git a/xen/arch/arm/arm32/head.S b/xen/arch/arm/arm32/head.S
index 8a98607459..cb8a3bf829 100644
--- a/xen/arch/arm/arm32/head.S
+++ b/xen/arch/arm/arm32/head.S
@@ -447,7 +447,6 @@ launch:
 sub   sp, #CPUINFO_sizeof/* Make room for CPU save record */
 mov   r0, r10/* Marshal args: - phys_offset */
 mov   r1, r8 /*   - DTB address */
-mov   r2, r7 /*   - CPU ID */
 teq   r12, #0
 beq   start_xen  /* and disappear into the land of C */
 b start_secondary/* (to the appropriate entry point) */
diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index 4fe904c51d..075013878e 100644
--- a/xen/arch/arm/arm64/head.S
+++ b/xen/arch/arm/arm64/head.S
@@ -584,7 +584,6 @@ launch:
 
 mov   x0, x20/* Marshal args: - phys_offset */
 mov   x1, x21/*   - FDT */
-mov   x2, x24/*   - CPU ID */
 cbnz  x22, 1f
 b start_xen  /* and disappear into the land of C */
 1:
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index faaf029b99..2f714d8b37 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -733,8 +733,7 @@ size_t __read_mostly dcache_line_bytes;
 
 /* C entry point for boot CPU */
 void __init start_xen(unsigned long boot_phys_offset,
-  unsigned long fdt_paddr,
-  unsigned long cpuid)
+  unsigned long fdt_paddr)
 {
 size_t fdt_size;
 int cpus, i;
-- 
2.11.0


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

[Xen-devel] [PATCH MM-PART2 RESEND v2 03/19] xen/arm: processor: Use BIT(.., UL) instead of _AC(1, U) in SCTLR_ defines

Use the pattern BIT(..., UL) to make the code more readable. Note that
unsigned long is used instead of unsigned because SCTLR is technically
32-bit on Arm32 and 64-bit on Arm64.

Signed-off-by: Julien Grall 

---
Changes in v2:
- Rework the patch to use BIT(..., UL) instead of _BITUL(...).
---
 xen/include/asm-arm/processor.h | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index f3b68185eb..bbcba061ca 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -120,20 +120,20 @@
 
 /* Bits specific to SCTLR_EL1 for Arm32 */
 
-#define SCTLR_A32_EL1_V (_AC(1,U)<<13)
+#define SCTLR_A32_EL1_V BIT(13, UL)
 
 /* Common bits for SCTLR_ELx for Arm32 */
 
-#define SCTLR_A32_ELx_TE(_AC(1,U)<<30)
-#define SCTLR_A32_ELx_FI(_AC(1,U)<<21)
+#define SCTLR_A32_ELx_TEBIT(30, UL)
+#define SCTLR_A32_ELx_FIBIT(21, UL)
 
 /* Common bits for SCTLR_ELx on all architectures */
-#define SCTLR_Axx_ELx_EE(_AC(1,U)<<25)
-#define SCTLR_Axx_ELx_WXN   (_AC(1,U)<<19)
-#define SCTLR_Axx_ELx_I (_AC(1,U)<<12)
-#define SCTLR_Axx_ELx_C (_AC(1,U)<<2)
-#define SCTLR_Axx_ELx_A (_AC(1,U)<<1)
-#define SCTLR_Axx_ELx_M (_AC(1,U)<<0)
+#define SCTLR_Axx_ELx_EEBIT(25, UL)
+#define SCTLR_Axx_ELx_WXN   BIT(19, UL)
+#define SCTLR_Axx_ELx_I BIT(12, UL)
+#define SCTLR_Axx_ELx_C BIT(2, UL)
+#define SCTLR_Axx_ELx_A BIT(1, UL)
+#define SCTLR_Axx_ELx_M BIT(0, UL)
 
 #define HSCTLR_BASE _AC(0x30c51878,U)
 
-- 
2.11.0


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

Re: [Xen-devel] [PATCH MM-PART2 v2 00/19] xen/arm: Clean-up & fixes in boot/mm code


Hi all,

I forgot to remove the patches for part1 before sending the part2. I will resend 
the series properly.


Sorry for the noise.

Cheers,

On 14/05/2019 13:21, Julien Grall wrote:

Hi all,

This is the second part of the boot/memory rework for Xen on Arm. This
part contains mostly clean-up & fixes found during the rework.

The first part of the rework is "xen/arm: TLB flush helpers rework" [1].

For convenience, I provided a branch with all the patches applied based
on staging:

 git://xenbits.xen.org/people/julieng/xen-unstable.git branch mm/part2/v2

Cheers,

[1] https://lists.xenproject.org/archives/html/xen-devel/2019-05/msg01109.html

Julien Grall (19):
   xen/const: Extend the existing macro BIT to take a suffix in parameter
   xen/arm: Rename SCTLR_* defines and remove unused one
   xen/arm: processor: Use BIT(.., UL) instead of _AC(1, U) in SCTLR_
 defines
   xen/arm: Rework HSCTLR_BASE
   xen/arm: Remove parameter cpuid from start_xen
   xen/arm: Rework secondary_start prototype
   xen/arm64: head: Remove unnecessary comment
   xen/arm64: head: Move earlyprintk messages in .rodata.str
   xen/arm64: head: Correctly report the HW CPU ID
   xen/arm32: head: Correctly report the HW CPU ID
   xen/arm32: head: Don't set MAIR0 and MAIR1
   xen/arm32: head: Always zero r3 before update a page-table entry
   xen/arm32: mm: Avoid to zero and clean cache for CPU0 domheap
   xen/arm32: mm: Avoid cleaning the cache for secondary CPUs page-tables
   xen/arm: mm: Introduce DEFINE_PAGE_TABLE{,S} and use it
   xen/arm: mm: Protect Xen page-table update with a spinlock
   xen/arm: mm: Initialize page-tables earlier
   xen/arm: mm: Check start is always before end in {destroy,
 modify}_xen_mappings
   xen/arm: Pair call to set_fixmap with call to clear_fixmap in
 copy_from_paddr

  xen/arch/arm/arm32/head.S | 34 --
  xen/arch/arm/arm32/insn.c |  2 +-
  xen/arch/arm/arm64/head.S | 40 +
  xen/arch/arm/arm64/insn.c | 18 
  xen/arch/arm/gic-v3-its.c | 13 +++---
  xen/arch/arm/gic-v3-lpi.c |  4 +-
  xen/arch/arm/guest_walk.c | 10 ++---
  xen/arch/arm/kernel.c |  3 +-
  xen/arch/arm/mm.c | 62 +-
  xen/arch/arm/setup.c  |  7 ++-
  xen/arch/arm/smpboot.c|  4 +-
  xen/arch/arm/traps.c  |  6 +--
  xen/arch/arm/vgic-v3-its.c| 12 ++---
  xen/arch/arm/vgic-v3.c|  2 +-
  xen/arch/arm/vgic.c   |  2 +-
  xen/drivers/char/meson-uart.c | 16 +++
  xen/drivers/char/mvebu-uart.c | 34 +++---
  xen/include/asm-arm/asm_defns.h   |  5 +++
  xen/include/asm-arm/bitops.h  |  2 -
  xen/include/asm-arm/gic_v3_defs.h |  4 +-
  xen/include/asm-arm/gic_v3_its.h  | 10 ++---
  xen/include/asm-arm/p2m.h |  4 +-
  xen/include/asm-arm/processor.h   | 93 ++-
  xen/include/xen/const.h   |  2 +
  24 files changed, 201 insertions(+), 188 deletions(-)



--
Julien Grall

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

[Xen-devel] [PATCH MM-PART2 v2 16/19] xen/arm: mm: Protect Xen page-table update with a spinlock

The function create_xen_entries() may be called concurrently. For
instance, while the vmap allocation is protected by a spinlock, the
mapping is not.

The implementation create_xen_entries() contains quite a few TOCTOU
races such as when allocating the 3rd-level page-tables.

Thankfully, they are pretty hard to reach as page-tables are allocated
once and never released. Yet it is possible, so we need to protect with
a spinlock to avoid corrupting the page-tables.

Signed-off-by: Julien Grall 

---
Changes in v2:
- Rework the commit message
---
 xen/arch/arm/mm.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 9a5f2e1c3f..7502a14760 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -974,6 +974,8 @@ enum xenmap_operation {
 RESERVE
 };
 
+static DEFINE_SPINLOCK(xen_pt_lock);
+
 static int create_xen_entries(enum xenmap_operation op,
   unsigned long virt,
   mfn_t mfn,
@@ -985,6 +987,8 @@ static int create_xen_entries(enum xenmap_operation op,
 lpae_t pte, *entry;
 lpae_t *third = NULL;
 
+spin_lock(_pt_lock);
+
 for(; addr < addr_end; addr += PAGE_SIZE, mfn = mfn_add(mfn, 1))
 {
 entry = _second[second_linear_offset(addr)];
@@ -1059,6 +1063,8 @@ out:
  */
 flush_xen_tlb_range_va(virt, PAGE_SIZE * nr_mfns);
 
+spin_unlock(_pt_lock);
+
 return rc;
 }
 
-- 
2.11.0


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

[Xen-devel] [PATCH MM-PART2 v2 11/19] xen/arm32: head: Don't set MAIR0 and MAIR1

The co-processor registers MAIR0 and MAIR1 are managed by EL1. So there
are no need to initialize them during Xen boot.

Signed-off-by: Julien Grall 
Reviewed-by: Andrii Anisov 

---
Changes in v2
- Add Andrii's reviewed-by
---
 xen/arch/arm/arm32/head.S | 2 --
 1 file changed, 2 deletions(-)

diff --git a/xen/arch/arm/arm32/head.S b/xen/arch/arm/arm32/head.S
index d42a13556c..3448817aab 100644
--- a/xen/arch/arm/arm32/head.S
+++ b/xen/arch/arm/arm32/head.S
@@ -212,8 +212,6 @@ cpu_init_done:
 /* Set up memory attribute type tables */
 ldr   r0, =MAIR0VAL
 ldr   r1, =MAIR1VAL
-mcr   CP32(r0, MAIR0)
-mcr   CP32(r1, MAIR1)
 mcr   CP32(r0, HMAIR0)
 mcr   CP32(r1, HMAIR1)
 
-- 
2.11.0


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

[Xen-devel] [PATCH MM-PART2 v2 15/19] xen/arm: mm: Introduce DEFINE_PAGE_TABLE{, S} and use it

We have multiple static page-tables defined in arch/arm/mm.c. The
current way to define them is difficult to read and does not help when
making modification.

Two new helpers DEFINE_PAGE_TABLES (to define multiple page-tables) and
DEFINE_PAGE_TABLE (alias of DEFINE_PAGE_TABLES(..., 1)) are introduced
and now used to define static page-tables.

Note that DEFINE_PAGE_TABLES() alignment differs from what is currently
used for allocating page-tables. This is fine because page-tables are
only required to be aligned to a page-size.

Signed-off-by: Julien Grall 

---
Changes in v2:
- Patch in replacement of "Use the shorter version
__aligned(PAGE_SIZE) to align page-tables".
---
 xen/arch/arm/mm.c | 32 ++--
 1 file changed, 18 insertions(+), 14 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 6db7dda0da..9a5f2e1c3f 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -50,6 +50,11 @@ struct domain *dom_xen, *dom_io, *dom_cow;
 #undef mfn_to_virt
 #define mfn_to_virt(mfn) __mfn_to_virt(mfn_x(mfn))
 
+#define DEFINE_PAGE_TABLES(name, nr)\
+lpae_t __aligned(PAGE_SIZE) name[LPAE_ENTRIES * (nr)]
+
+#define DEFINE_PAGE_TABLE(name) DEFINE_PAGE_TABLES(name, 1)
+
 /* Static start-of-day pagetables that we use before the allocators
  * are up. These are used by all CPUs during bringup before switching
  * to the CPUs own pagetables.
@@ -73,13 +78,13 @@ struct domain *dom_xen, *dom_io, *dom_cow;
  * Finally, if EARLY_PRINTK is enabled then xen_fixmap will be mapped
  * by the CPU once it has moved off the 1:1 mapping.
  */
-lpae_t boot_pgtable[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
+DEFINE_PAGE_TABLE(boot_pgtable);
 #ifdef CONFIG_ARM_64
-lpae_t boot_first[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
-lpae_t boot_first_id[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
+DEFINE_PAGE_TABLE(boot_first);
+DEFINE_PAGE_TABLE(boot_first_id);
 #endif
-lpae_t boot_second[LPAE_ENTRIES]  __attribute__((__aligned__(4096)));
-lpae_t boot_third[LPAE_ENTRIES]  __attribute__((__aligned__(4096)));
+DEFINE_PAGE_TABLE(boot_second);
+DEFINE_PAGE_TABLE(boot_third);
 
 /* Main runtime page tables */
 
@@ -93,8 +98,8 @@ lpae_t boot_third[LPAE_ENTRIES]  
__attribute__((__aligned__(4096)));
 
 #ifdef CONFIG_ARM_64
 #define HYP_PT_ROOT_LEVEL 0
-lpae_t xen_pgtable[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
-lpae_t xen_first[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
+static DEFINE_PAGE_TABLE(xen_pgtable);
+static DEFINE_PAGE_TABLE(xen_first);
 #define THIS_CPU_PGTABLE xen_pgtable
 #else
 #define HYP_PT_ROOT_LEVEL 1
@@ -107,17 +112,16 @@ static DEFINE_PER_CPU(lpae_t *, xen_pgtable);
  * DOMHEAP_VIRT_START...DOMHEAP_VIRT_END in 2MB chunks. */
 static DEFINE_PER_CPU(lpae_t *, xen_dommap);
 /* Root of the trie for cpu0, other CPU's PTs are dynamically allocated */
-lpae_t cpu0_pgtable[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
+static DEFINE_PAGE_TABLE(cpu0_pgtable);
 /* cpu0's domheap page tables */
-lpae_t cpu0_dommap[LPAE_ENTRIES*DOMHEAP_SECOND_PAGES]
-__attribute__((__aligned__(4096*DOMHEAP_SECOND_PAGES)));
+static DEFINE_PAGE_TABLES(cpu0_dommap, DOMHEAP_SECOND_PAGES);
 #endif
 
 #ifdef CONFIG_ARM_64
 /* The first page of the first level mapping of the xenheap. The
  * subsequent xenheap first level pages are dynamically allocated, but
  * we need this one to bootstrap ourselves. */
-lpae_t xenheap_first_first[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
+static DEFINE_PAGE_TABLE(xenheap_first_first);
 /* The zeroeth level slot which uses xenheap_first_first. Used because
  * setup_xenheap_mappings otherwise relies on mfn_to_virt which isn't
  * valid for a non-xenheap mapping. */
@@ -131,12 +135,12 @@ static __initdata int xenheap_first_first_slot = -1;
  * addresses from 0 to 0x7fff. Offsets into it are calculated
  * with second_linear_offset(), not second_table_offset().
  */
-lpae_t xen_second[LPAE_ENTRIES*2] __attribute__((__aligned__(4096*2)));
+static DEFINE_PAGE_TABLES(xen_second, 2);
 /* First level page table used for fixmap */
-lpae_t xen_fixmap[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
+DEFINE_PAGE_TABLE(xen_fixmap);
 /* First level page table used to map Xen itself with the XN bit set
  * as appropriate. */
-static lpae_t xen_xenmap[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
+static DEFINE_PAGE_TABLE(xen_xenmap);
 
 /* Non-boot CPUs use this to find the correct pagetables. */
 uint64_t init_ttbr;
-- 
2.11.0


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

[Xen-devel] [PATCH MM-PART2 v2 08/19] xen/arm64: head: Move earlyprintk messages in .rodata.str

At the moment, the earlyprintk messages are interleaved with the
instructions. This makes more difficult to read the objdump output.

Introduce a new macro to add a string in .rodata.str and use it for all
the earlyprintk messages.

Signed-off-by: Julien Grall 
Reviewed-by: Andrii Anisov 

---

I haven't done a similar change in arm32 yet because the compiler will
throw an error when using 'adr' when load an address from a different
section (see A5-200 in ARM DDI 0406C.a for the technical reason).
The change is likely to be more elaborate.

Changes in v2:
- Add Andrii's reviewed-by
---
 xen/arch/arm/arm64/head.S   | 14 +-
 xen/include/asm-arm/asm_defns.h |  5 +
 2 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index ad446e7345..b957eb90fb 100644
--- a/xen/arch/arm/arm64/head.S
+++ b/xen/arch/arm/arm64/head.S
@@ -81,13 +81,10 @@
 /* Macro to print a string to the UART, if there is one.
  * Clobbers x0-x3. */
 #ifdef CONFIG_EARLY_PRINTK
-#define PRINT(_s)   \
-adr   x0, 98f ; \
-blputs; \
-b 99f ; \
-98: .asciz _s ; \
-.align 2  ; \
-99:
+#define PRINT(_s)   \
+adr   x0, 98f ; \
+blputs; \
+RODATA_STR(98, _s)
 #else /* CONFIG_EARLY_PRINTK */
 #define PRINT(s)
 #endif /* !CONFIG_EARLY_PRINTK */
@@ -633,8 +630,7 @@ init_uart:
 #endif
 adr   x0, 1f
 b puts
-1:  .asciz "- UART enabled -\r\n"
-.align 4
+RODATA_STR(1, "- UART enabled -\r\n")
 
 /* Print early debug messages.
  * x0: Nul-terminated string to print.
diff --git a/xen/include/asm-arm/asm_defns.h b/xen/include/asm-arm/asm_defns.h
index 02be83e2b3..3f21def0ab 100644
--- a/xen/include/asm-arm/asm_defns.h
+++ b/xen/include/asm-arm/asm_defns.h
@@ -16,6 +16,11 @@
 # error "unknown ARM variant"
 #endif
 
+#define RODATA_STR(label, msg)  \
+.pushsection .rodata.str, "aMS", %progbits, 1 ; \
+label:  .asciz msg; \
+.popsection
+
 #endif /* __ARM_ASM_DEFNS_H__ */
 /*
  * Local variables:
-- 
2.11.0


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

[Xen-devel] [PATCH MM-PART2 v2 10/19] xen/arm32: head: Correctly report the HW CPU ID

There are no reason to consider the HW CPU ID will be 0 when the
processor is part of a uniprocessor system. At best, this will result to
conflicting output as the rest of Xen use the value directly read from
MPIDR.

So remove the zeroing and logic to check if the CPU is part of a
uniprocessor system.

Signed-off-by: Julien Grall 
Reviewed-by: Andrii Anisov 

---
Changes in v2:
- Add Andrii's reviewed-by
---
 xen/arch/arm/arm32/head.S | 8 
 1 file changed, 8 deletions(-)

diff --git a/xen/arch/arm/arm32/head.S b/xen/arch/arm/arm32/head.S
index 9f40face98..d42a13556c 100644
--- a/xen/arch/arm/arm32/head.S
+++ b/xen/arch/arm/arm32/head.S
@@ -124,16 +124,8 @@ GLOBAL(init_secondary)
 mov   r12, #1/* r12 := is_secondary_cpu */
 
 common_start:
-mov   r7, #0 /* r7 := CPU ID. Initialy zero until we
-  * find that multiprocessor extensions are
-  * present and the system is SMP */
 mrc   CP32(r1, MPIDR)
-tst   r1, #MPIDR_SMP /* Multiprocessor extension supported? */
-beq   1f
-tst   r1, #MPIDR_UP  /* Uniprocessor system? */
-bne   1f
 bic   r7, r1, #(~MPIDR_HWID_MASK) /* Mask out flags to get CPU ID */
-1:
 
 /* Non-boot CPUs wait here until __cpu_up is ready for them */
 teq   r12, #0
-- 
2.11.0


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

[Xen-devel] [PATCH MM-PART2 v2 19/19] xen/arm: Pair call to set_fixmap with call to clear_fixmap in copy_from_paddr

At the moment, set_fixmap may replace a valid entry without following
the break-before-make sequence. This may result to TLB conflict abort.

Rather than dealing with Break-Before-Make in set_fixmap, every call to
set_fixmap is paired with a call to clear_fixmap.

Signed-off-by: Julien Grall 
Reviewed-by: Andrii Anisov 

---
Changes in v2:
- Add Andrii's reviewed-by
---
 xen/arch/arm/kernel.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index e3ffdb2fa1..389bef2afa 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -58,13 +58,12 @@ void __init copy_from_paddr(void *dst, paddr_t paddr, 
unsigned long len)
 set_fixmap(FIXMAP_MISC, maddr_to_mfn(paddr), PAGE_HYPERVISOR_WC);
 memcpy(dst, src + s, l);
 clean_dcache_va_range(dst, l);
+clear_fixmap(FIXMAP_MISC);
 
 paddr += l;
 dst += l;
 len -= l;
 }
-
-clear_fixmap(FIXMAP_MISC);
 }
 
 static void __init place_modules(struct kernel_info *info,
-- 
2.11.0


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

[Xen-devel] [PATCH MM-PART2 v2 17/19] xen/arm: mm: Initialize page-tables earlier

Since commit f60658c6ae "xen/arm: Stop relocating Xen", the function
setup_page_tables() does not require any information from the FDT.

So the initialization of the page-tables can be done much earlier in the
boot process. The earliest setup_page_tables() can be called is after
traps have been initialized, so we can get backtrace if an error
occurred.

Moving the initialization of the page-tables also avoid the dance to map
the FDT again in the new set of page-tables.

Signed-off-by: Julien Grall 
Reviewed-by: Andrii Anisov 

---
Changes in v2:
- Add Andrii's reviewed-by
---
 xen/arch/arm/mm.c| 12 +++-
 xen/arch/arm/setup.c |  4 ++--
 2 files changed, 5 insertions(+), 11 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 7502a14760..eacc1647e0 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -550,7 +550,7 @@ static inline lpae_t pte_of_xenaddr(vaddr_t va)
 return mfn_to_xen_entry(maddr_to_mfn(ma), MT_NORMAL);
 }
 
-/* Map the FDT in the early boot page table */
+/* Map the FDT in the runtime page table */
 void * __init early_fdt_map(paddr_t fdt_paddr)
 {
 /* We are using 2MB superpage for mapping the FDT */
@@ -573,7 +573,7 @@ void * __init early_fdt_map(paddr_t fdt_paddr)
 /* The FDT is mapped using 2MB superpage */
 BUILD_BUG_ON(BOOT_FDT_VIRT_START % SZ_2M);
 
-create_mappings(boot_second, BOOT_FDT_VIRT_START, paddr_to_pfn(base_paddr),
+create_mappings(xen_second, BOOT_FDT_VIRT_START, paddr_to_pfn(base_paddr),
 SZ_2M >> PAGE_SHIFT, SZ_2M);
 
 offset = fdt_paddr % SECOND_SIZE;
@@ -588,7 +588,7 @@ void * __init early_fdt_map(paddr_t fdt_paddr)
 
 if ( (offset + size) > SZ_2M )
 {
-create_mappings(boot_second, BOOT_FDT_VIRT_START + SZ_2M,
+create_mappings(xen_second, BOOT_FDT_VIRT_START + SZ_2M,
 paddr_to_pfn(base_paddr + SZ_2M),
 SZ_2M >> PAGE_SHIFT, SZ_2M);
 }
@@ -699,12 +699,6 @@ void __init setup_pagetables(unsigned long 
boot_phys_offset)
 pte.pt.table = 1;
 xen_second[second_table_offset(FIXMAP_ADDR(0))] = pte;
 
-/* ... DTB */
-pte = boot_second[second_table_offset(BOOT_FDT_VIRT_START)];
-xen_second[second_table_offset(BOOT_FDT_VIRT_START)] = pte;
-pte = boot_second[second_table_offset(BOOT_FDT_VIRT_START + SZ_2M)];
-xen_second[second_table_offset(BOOT_FDT_VIRT_START + SZ_2M)] = pte;
-
 #ifdef CONFIG_ARM_64
 ttbr = (uintptr_t) xen_pgtable + phys_offset;
 #else
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 2f714d8b37..889da40d8d 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -759,6 +759,8 @@ void __init start_xen(unsigned long boot_phys_offset,
 /* Initialize traps early allow us to get backtrace when an error occurred 
*/
 init_traps();
 
+setup_pagetables(boot_phys_offset);
+
 smp_clear_cpu_maps();
 
 device_tree_flattened = early_fdt_map(fdt_paddr);
@@ -780,8 +782,6 @@ void __init start_xen(unsigned long boot_phys_offset,
  (paddr_t)(uintptr_t)(_end - _start + 1), false);
 BUG_ON(!xen_bootmodule);
 
-setup_pagetables(boot_phys_offset);
-
 setup_mm(fdt_paddr, fdt_size);
 
 /* Parse the ACPI tables for possible boot-time configuration */
-- 
2.11.0


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

[Xen-devel] [PATCH MM-PART2 v2 14/19] xen/arm32: mm: Avoid cleaning the cache for secondary CPUs page-tables

The page-table walker is configured to use the same shareability and
cacheability as the access performed when updating the page-tables. This
means cleaning the cache for secondary CPUs runtime page-tables is
unnecessary.

Signed-off-by: Julien Grall 
Reviewed-by: Andrii Anisov 

---
Changes in v2:
- Add Andrii's reviewed-by
---
 xen/arch/arm/mm.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index cda2847d00..6db7dda0da 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -769,9 +769,6 @@ int init_secondary_pagetables(int cpu)
 write_pte([first_table_offset(DOMHEAP_VIRT_START+i*FIRST_SIZE)], 
pte);
 }
 
-clean_dcache_va_range(first, PAGE_SIZE);
-clean_dcache_va_range(domheap, DOMHEAP_SECOND_PAGES*PAGE_SIZE);
-
 per_cpu(xen_pgtable, cpu) = first;
 per_cpu(xen_dommap, cpu) = domheap;
 
-- 
2.11.0


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

[Xen-devel] [PATCH MM-PART2 v2 00/19] xen/arm: Clean-up & fixes in boot/mm code

Hi all,

This is the second part of the boot/memory rework for Xen on Arm. This
part contains mostly clean-up & fixes found during the rework.

The first part of the rework is "xen/arm: TLB flush helpers rework" [1].

For convenience, I provided a branch with all the patches applied based
on staging:

git://xenbits.xen.org/people/julieng/xen-unstable.git branch mm/part2/v2

Cheers,

[1] https://lists.xenproject.org/archives/html/xen-devel/2019-05/msg01109.html

Julien Grall (19):
  xen/const: Extend the existing macro BIT to take a suffix in parameter
  xen/arm: Rename SCTLR_* defines and remove unused one
  xen/arm: processor: Use BIT(.., UL) instead of _AC(1, U) in SCTLR_
defines
  xen/arm: Rework HSCTLR_BASE
  xen/arm: Remove parameter cpuid from start_xen
  xen/arm: Rework secondary_start prototype
  xen/arm64: head: Remove unnecessary comment
  xen/arm64: head: Move earlyprintk messages in .rodata.str
  xen/arm64: head: Correctly report the HW CPU ID
  xen/arm32: head: Correctly report the HW CPU ID
  xen/arm32: head: Don't set MAIR0 and MAIR1
  xen/arm32: head: Always zero r3 before update a page-table entry
  xen/arm32: mm: Avoid to zero and clean cache for CPU0 domheap
  xen/arm32: mm: Avoid cleaning the cache for secondary CPUs page-tables
  xen/arm: mm: Introduce DEFINE_PAGE_TABLE{,S} and use it
  xen/arm: mm: Protect Xen page-table update with a spinlock
  xen/arm: mm: Initialize page-tables earlier
  xen/arm: mm: Check start is always before end in {destroy,
modify}_xen_mappings
  xen/arm: Pair call to set_fixmap with call to clear_fixmap in
copy_from_paddr

 xen/arch/arm/arm32/head.S | 34 --
 xen/arch/arm/arm32/insn.c |  2 +-
 xen/arch/arm/arm64/head.S | 40 +
 xen/arch/arm/arm64/insn.c | 18 
 xen/arch/arm/gic-v3-its.c | 13 +++---
 xen/arch/arm/gic-v3-lpi.c |  4 +-
 xen/arch/arm/guest_walk.c | 10 ++---
 xen/arch/arm/kernel.c |  3 +-
 xen/arch/arm/mm.c | 62 +-
 xen/arch/arm/setup.c  |  7 ++-
 xen/arch/arm/smpboot.c|  4 +-
 xen/arch/arm/traps.c  |  6 +--
 xen/arch/arm/vgic-v3-its.c| 12 ++---
 xen/arch/arm/vgic-v3.c|  2 +-
 xen/arch/arm/vgic.c   |  2 +-
 xen/drivers/char/meson-uart.c | 16 +++
 xen/drivers/char/mvebu-uart.c | 34 +++---
 xen/include/asm-arm/asm_defns.h   |  5 +++
 xen/include/asm-arm/bitops.h  |  2 -
 xen/include/asm-arm/gic_v3_defs.h |  4 +-
 xen/include/asm-arm/gic_v3_its.h  | 10 ++---
 xen/include/asm-arm/p2m.h |  4 +-
 xen/include/asm-arm/processor.h   | 93 ++-
 xen/include/xen/const.h   |  2 +
 24 files changed, 201 insertions(+), 188 deletions(-)

-- 
2.11.0


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

[Xen-devel] [PATCH MM-PART2 v2 18/19] xen/arm: mm: Check start is always before end in {destroy, modify}_xen_mappings

The two helpers {destroy, modify}_xen_mappings don't check that the
start is always before the end. This should never happen but if it
happens, it will result to unexpected behavior.

Catch such issues earlier on by adding an ASSERT in destroy_xen_mappings
and modify_xen_mappings.

Signed-off-by: Julien Grall 
Reviewed-by: Andrii Anisov 

---
Changes in v2:
- Add Andrii's reviewed-by
---
 xen/arch/arm/mm.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index eacc1647e0..b408de7c75 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -1077,11 +1077,13 @@ int populate_pt_range(unsigned long virt, unsigned long 
nr_mfns)
 
 int destroy_xen_mappings(unsigned long v, unsigned long e)
 {
+ASSERT(v <= e);
 return create_xen_entries(REMOVE, v, INVALID_MFN, (e - v) >> PAGE_SHIFT, 
0);
 }
 
 int modify_xen_mappings(unsigned long s, unsigned long e, unsigned int flags)
 {
+ASSERT(s <= e);
 return create_xen_entries(MODIFY, s, INVALID_MFN, (e - s) >> PAGE_SHIFT,
   flags);
 }
-- 
2.11.0


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

[Xen-devel] [PATCH MM-PART2 v2 12/19] xen/arm32: head: Always zero r3 before update a page-table entry

The boot code is using r2 and r3 to hold the page-table entry value.
While r2 is always updated before storing the value, this is not always
the case for r3.

Thankfully today, r3 will always be zero when we care. But this is
difficult to track and error-prone.

So always zero r3 within the few instructions before the write the
page-table entry.

Signed-off-by: Julien Grall 

---
Changes in v2:
- Use 0x0 instead of 0
- Remove a duplicate mov r3, #0
---
 xen/arch/arm/arm32/head.S | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/arm32/head.S b/xen/arch/arm/arm32/head.S
index 3448817aab..18ded49a04 100644
--- a/xen/arch/arm/arm32/head.S
+++ b/xen/arch/arm/arm32/head.S
@@ -270,6 +270,7 @@ cpu_init_done:
 orr   r2, r2, #PT_UPPER(MEM) /* r2:r3 := section map */
 orr   r2, r2, #PT_LOWER(MEM)
 lsl   r1, r1, #3 /* r1 := Slot offset */
+mov   r3, #0x0
 strd  r2, r3, [r4, r1]   /* Mapping of paddr(start) */
 mov   r6, #1 /* r6 := identity map now in place */
 
@@ -372,11 +373,11 @@ paging:
 
 /* Add UART to the fixmap table */
 ldr   r1, =xen_fixmap/* r1 := vaddr (xen_fixmap) */
-mov   r3, #0
 lsr   r2, r11, #THIRD_SHIFT
 lsl   r2, r2, #THIRD_SHIFT   /* 4K aligned paddr of UART */
 orr   r2, r2, #PT_UPPER(DEV_L3)
 orr   r2, r2, #PT_LOWER(DEV_L3) /* r2:r3 := 4K dev map including UART 
*/
+mov   r3, #0x0
 strd  r2, r3, [r1, #(FIXMAP_CONSOLE*8)] /* Map it in the first 
fixmap's slot */
 1:
 
@@ -388,6 +389,7 @@ paging:
 orr   r2, r2, #PT_LOWER(PT)  /* r2:r3 := table map of xen_fixmap */
 ldr   r4, =FIXMAP_ADDR(0)
 mov   r4, r4, lsr #(SECOND_SHIFT - 3)   /* r4 := Slot for FIXMAP(0) */
+mov   r3, #0x0
 strd  r2, r3, [r1, r4]   /* Map it in the fixmap's slot */
 
 /* Use a virtual address to access the UART. */
-- 
2.11.0


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

[Xen-devel] [PATCH MM-PART1 v3 1/8] xen/arm: Don't boot Xen on platform using AIVIVT instruction caches

The AIVIVT is a type of instruction cache available on Armv7. This is
the only cache not implementing the IVIPT extension and therefore
requiring specific care.

To simplify maintenance requirements, Xen will not boot on platform
using AIVIVT cache.

This should not be an issue because Xen Arm32 can only boot on a small
number of processors (see arch/arm/arm32/proc-v7.S). All of them are
not using AIVIVT cache.

Signed-off-by: Julien Grall 

---

Changes in v3:
- Patch added
---
 xen/arch/arm/setup.c| 5 +
 xen/include/asm-arm/processor.h | 5 +
 2 files changed, 10 insertions(+)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index ccb0f181ea..faaf029b99 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -526,10 +526,15 @@ static void __init setup_mm(unsigned long dtb_paddr, 
size_t dtb_size)
 unsigned long boot_mfn_start, boot_mfn_end;
 int i;
 void *fdt;
+const uint32_t ctr = READ_CP32(CTR);
 
 if ( !bootinfo.mem.nr_banks )
 panic("No memory bank\n");
 
+/* We only supports instruction caches implementing the IVIPT extension. */
+if ( ((ctr >> CTR_L1Ip_SHIFT) & CTR_L1Ip_MASK) == CTR_L1Ip_AIVIVT )
+panic("AIVIVT instruction cache not supported\n");
+
 init_pdx();
 
 ram_start = bootinfo.mem.bank[0].start;
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index b5f515805d..04b05b3f39 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -6,6 +6,11 @@
 #endif
 #include 
 
+/* CTR Cache Type Register */
+#define CTR_L1Ip_MASK   0x3
+#define CTR_L1Ip_SHIFT  14
+#define CTR_L1Ip_AIVIVT 0x1
+
 /* MIDR Main ID Register */
 #define MIDR_REVISION_MASK  0xf
 #define MIDR_RESIVION(midr) ((midr) & MIDR_REVISION_MASK)
-- 
2.11.0


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

[Xen-devel] [PATCH MM-PART2 v2 13/19] xen/arm32: mm: Avoid to zero and clean cache for CPU0 domheap