Re: [Xen-devel] [PATCH v1 0/7] tools: add linker table userspace sandbox

[Rob Landley]

On 08/19/2016 04:41 PM, mcg...@kernel.org wrote:
> Please let me know if there are any issue or questions.

Only that this has been the majority of the traffic on the linux-sh
mailing list for over a month and I'm still not sure why anyone should care.

I have no idea what problem it solves, despite reading a couple dozen
messages in the thread, and the most recent two 0/x intro messages. Its
purpose seems to be ensuring that lld.llvm.org has more work to do if it
ever wants to build the kernel without binutils?

I also am not certain why every revision of it is cc'd to linux-sh. Is
it generic linker infrastructure change, or is it something that affects
this architecture specifically? As far as I can tell nothing in this
most recent 7-patch series touches arch/sh at all, you just cc'd our
list because you think the work you're doing is _important_, not that
it's specifically relevant to us.

Rob

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-xsm  4 host-ping-check-native   fail REGR. vs. 100557

Regressions which are regarded as allowable (not blocking):
 build-amd64-rumpuserxen   6 xen-buildfail  like 100557
 build-i386-rumpuserxen6 xen-buildfail  like 100557
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100557
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100557
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 100557
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100557
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 100557

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

version targeted for testing:
 xen  f8992212c9ee537e67f30841e3232b982d74af2b
baseline version:
 xen  830f177d920bdb4fda4fcdcd3b8ac0928cb579fb

Last test of basis   100557  2016-08-19 08:30:41 Z0 days
Testing same since   100565  2016-08-19 18:14:43 Z0 days1 attempts


People who touched revisions under test:
  Derek Straka 
  Jan Beulich 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-oldkern  pass
 build-i386-oldkern   pass
 build-amd64-prev   

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

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

version targeted for testing:
 qemuu5f9f818ea88a013b2464563be354dd2f0f316407
baseline version:
 qemuu02b1ad881cbb1795029737a9077db60267dc0c6f

Last test of basis   100546  2016-08-18 15:18:29 Z1 days
Failing since100559  2016-08-19 10:42:44 Z0 days2 attempts
Testing same since   100562  2016-08-19 16:12:36 Z0 days1 attempts


People who touched revisions under test:
  Michal Privoznik 
  Peter Maydell 
  Sascha Silbe 

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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Regressions :-(

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

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

version targeted for testing:
 ovmf 35dc964bf1eab3f0725389811d2316b1331d6cee
baseline version:
 ovmf 00bcb5c27a5bb781099482c5763937334be91e76

Last test of basis67561  2016-08-19 05:19:21 Z0 days
Testing same since67564  2016-08-19 19:22:16 Z0 days1 attempts


People who touched revisions under test:
  Jeff Fan 
  Jiewen Yao 
  Shi, Steven 
  Steven Shi 
  Yonghong Zhu 

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



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

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

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


Push not applicable.


commit 35dc964bf1eab3f0725389811d2316b1331d6cee
Author: Yonghong Zhu 
Date:   Wed Aug 17 18:52:51 2016 +0800

BaseTools: Fix a bug use 'COMMON' as CodeBase in BuildOptions section

Current BaseTools query the BuildOptions not cover the case that use
'COMMON' as CodeBase, while DSC spec allow this usage. This Patch add
support for such 'common.DXE_RUNTIME_DRIVER' as the Scope2 in the query
Condition.

Cc: Liming Gao 
Cc: Kurt Kennett 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu 
Reviewed-by: Liming Gao 

commit 91ae2988c62f03987fe02159d26b001a5201d812
Author: Yonghong Zhu 
Date:   Mon Aug 15 13:52:12 2016 +0800

BaseTools: FMP capsule add the support to generate auth info

Current BaseTools cannot generate EFI_FIRMWARE_IMAGE_AUTHENTICATION
for FMP capsule. this patch fix it by FDF spec's update to add the
definition for CERTIFICATE_GUID and  MONOTONIC_COUNT. BaseTools call
the tool by CERTIFICATE_GUID to generate the certdata and fill the header
info.

Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu 
Reviewed-by: Liming Gao 

commit 9b98c4164013845ba80befd66fd38ce827a4c034
Author: Yonghong Zhu 
Date:   Mon Aug 15 13:39:32 2016 +0800

BaseTools: Rsa2048Sha256Sign add new option to support Monotonic count

the EFI_FIRMWARE_IMAGE_AUTHENTICATION struct require the AuthInfo which
is a signature across the image data and the Monotonic Count value, so we
add the new option to support Monotonic count.

Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu 
Reviewed-by: Liming Gao 

commit cd1c96046968581cc87d306ca8b06cc97784554b
Author: Yonghong Zhu 
Date:   Mon Aug 15 17:12:12 2016 +0800

BaseTools: Add the PKCS7 tool

Provide the PKCS7 Tool to support the CertType - EFI_CERT_TYPE_PKCS7_GUID,
then user can use this tool to add 

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  2a99aa99fc84a45f505f84802af56b006d14c52e
baseline version:
 xen  f8992212c9ee537e67f30841e3232b982d74af2b

Last test of basis   100561  2016-08-19 16:01:07 Z0 days
Testing same since   100564  2016-08-19 18:01:31 Z0 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 

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



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=2a99aa99fc84a45f505f84802af56b006d14c52e
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
2a99aa99fc84a45f505f84802af56b006d14c52e
+ branch=xen-unstable-smoke
+ revision=2a99aa99fc84a45f505f84802af56b006d14c52e
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.7-testing
+ '[' x2a99aa99fc84a45f505f84802af56b006d14c52e = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' 

[Xen-devel] [PATCH v5 15/16] x86: make Xen early boot code relocatable

[Daniel Kiper]

Every multiboot protocol (regardless of version) compatible image must
specify its load address (in ELF or multiboot header). Multiboot protocol
compatible loader have to load image at specified address. However, there
is no guarantee that the requested memory region (in case of Xen it starts
at 1 MiB and ends at 17 MiB) where image should be loaded initially is a RAM
and it is free (legacy BIOS platforms are merciful for Xen but I found at
least one EFI platform on which Xen load address conflicts with EFI boot
services; it is Dell PowerEdge R820 with latest firmware). To cope with that
problem we must make Xen early boot code relocatable and help boot loader to
relocate image in proper way by suggesting, not requesting specific load
addresses as it is right now, allowed address ranges. This patch does former.
It does not add multiboot2 protocol interface which is done in "x86: add
multiboot2 protocol support for relocatable images" patch.

This patch changes following things:
  - default load address is changed from 1 MiB to 2 MiB; I did that because
initial page tables are using 2 MiB huge pages and this way required
updates for them are quite easy; it means that e.g. we avoid spacial
cases for start and end of required memory region if it live at address
not aligned to 2 MiB,
  - %esi and %r15d registers are used as a storage for Xen image load base
address (%r15d shortly because %rsi is used for EFI SystemTable address
in 64-bit code); both registers are (%esi is mostly) unused in early
boot code and preserved during C functions calls,
  - %fs is used as base for Xen data relative addressing in 32-bit code
if it is possible; %esi is used for that thing during error printing
because it is not always possible to properly and efficiently
initialize %fs.

PS I am still not convinced that move to %fs relative addressing is good
   idea. As you can see code grows larger due to GDT initialization stuff,
   etc. However, I cannot see potential gains for now and future (probably
   it would be if whole Xen code, not early boot one, played segment registers
   games). Well, maybe in one or two places where base register is not used
   in full SIB addressing mode. So, question is: does it pay? Does gains
   overweight all efforts related to %fs games? Maybe we should stay with
   %esi relative addressing? Of course I am aware that it is not perfect.
   However, IMO, it is much simpler and clearer.
   This is my suggestion. If you agree with me I can change code once again
   and back to %esi. This is not big problem. If not I am not going to argue
   longer. I will do what you request. Well, it will be nice if you convince
   me that your idea is good and I am wrong then...  ;-)))

Signed-off-by: Daniel Kiper 
---
v4 - suggestions/fixes:
   - do not relocate Xen image if boot loader did work for us
 (suggested by Andrew Cooper and Jan Beulich),
   - initialize xen_img_load_base_addr in EFI boot code too,
   - properly initialize trampoline_xen_phys_start,
   - calculate Xen image load base address in
 x86_64 code ourselves,
 (suggested by Jan Beulich),
   - change how and when Xen image base address is printed,
   - use %fs instead of %esi for relative addressing
 (suggested by Andrew Cooper and Jan Beulich),
   - create esi_offset and fs_offset() macros in assembly,
   - calculate  mkelf32 argument automatically,
   - optimize and cleanup code,
   - improve comments,
   - improve commit message.

v3 - suggestions/fixes:
   - improve segment registers initialization
 (suggested by Jan Beulich),
   - simplify Xen image load base address calculation
 (suggested by Jan Beulich),
   - use %esi and %r15d instead of %ebp to store
 Xen image load base address,
   - use %esi instead of %fs for relative addressing;
 this way we get shorter and simpler code,
   - rename some variables and constants
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Konrad Rzeszutek Wilk),
   - improve commit message
 (suggested by Jan Beulich).
---
 xen/arch/x86/Makefile  |4 +-
 xen/arch/x86/Rules.mk  |4 +
 xen/arch/x86/boot/head.S   |  204 +++-
 xen/arch/x86/boot/trampoline.S |   10 +-
 xen/arch/x86/boot/wakeup.S |4 +-
 xen/arch/x86/boot/x86_64.S |   51 --
 xen/arch/x86/efi/efi-boot.h|3 +-
 xen/arch/x86/setup.c   |   31 +++---
 xen/arch/x86/xen.lds.S |8 +-
 xen/include/asm-x86/config.h   |1 +
 xen/include/asm-x86/page.h |2 +-
 11 files changed, 217 insertions(+), 105 deletions(-)

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 9464b7b..df899c1 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -89,8 +89,8 @@ all_symbols =
 endif
 
 $(TARGET): $(TARGET)-syms $(efi-y) boot/mkelf32
-   ./boot/mkelf32 $(notes_phdrs) $(TARGET)-syms $(TARGET) 0x10 \
-   

[Xen-devel] [PATCH v5 16/16] x86: add multiboot2 protocol support for relocatable images

[Daniel Kiper]

Add multiboot2 protocol support for relocatable images. Only GRUB2 with
"multiboot2: Add support for relocatable images" patch understands
that feature. Older multiboot protocol (regardless of version)
compatible loaders ignore it and everything works as usual.

Signed-off-by: Daniel Kiper 
---
v4 - suggestions/fixes:
   - do not get Xen image load base address from
 multiboot2 information in x86_64 code
 (suggested by Jan Beulich),
   - improve label names
 (suggested by Jan Beulich),
   - improve comments,
 (suggested by Jan Beulich).

v3 - suggestions/fixes:
   - use %esi and %r15d instead of %ebp to store
 Xen image load base address,
   - rename some types and constants,
   - reformat xen/include/xen/multiboot2.h
 (suggested by Konrad Rzeszutek Wilk),
   - improve comments,
   - improve commit message
 (suggested by Konrad Rzeszutek Wilk).
---
 xen/arch/x86/boot/head.S  |   19 ++-
 xen/arch/x86/x86_64/asm-offsets.c |1 +
 xen/include/xen/multiboot2.h  |   13 +
 3 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index a1b0c05..25a92e0 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -82,6 +82,13 @@ multiboot2_header_start:
 /* Align modules at page boundry. */
 mb2ht_init MB2_HT(MODULE_ALIGN), MB2_HT(REQUIRED)
 
+/* Load address preference. */
+mb2ht_init MB2_HT(RELOCATABLE), MB2_HT(OPTIONAL), \
+   sym_offset(start), /* Min load address. */ \
+   0x, /* The end of image max load address (4 GiB - 
1). */ \
+   0x20, /* Load address alignment (2 MiB). */ \
+   MULTIBOOT2_LOAD_PREFERENCE_HIGH
+
 /* Console flags tag. */
 mb2ht_init MB2_HT(CONSOLE_FLAGS), MB2_HT(OPTIONAL), \
MULTIBOOT2_CONSOLE_FLAGS_EGA_TEXT_SUPPORTED
@@ -372,10 +379,19 @@ __start:
 cmp %edi,MB2_fixed_total_size(%ebx)
 jbe trampoline_bios_setup
 
+/* Get Xen image load base address from Multiboot2 information. */
+cmpl$MULTIBOOT2_TAG_TYPE_LOAD_BASE_ADDR,MB2_tag_type(%ecx)
+jne 1f
+
+mov MB2_load_base_addr(%ecx),%esi
+sub $XEN_IMG_OFFSET,%esi
+jmp 9f
+
+1:
 /* Get mem_lower from Multiboot2 information. */
 cmpl$MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO,MB2_tag_type(%ecx)
 cmove   MB2_mem_lower(%ecx),%edx
-je  trampoline_bios_setup
+je  9f
 
 /* EFI IA-32 platforms are not supported. */
 cmpl$MULTIBOOT2_TAG_TYPE_EFI32,MB2_tag_type(%ecx)
@@ -389,6 +405,7 @@ __start:
 cmpl$MULTIBOOT2_TAG_TYPE_END,MB2_tag_type(%ecx)
 je  trampoline_bios_setup
 
+9:
 /* Go to next Multiboot2 information tag. */
 add MB2_tag_size(%ecx),%ecx
 add $(MULTIBOOT2_TAG_ALIGN-1),%ecx
diff --git a/xen/arch/x86/x86_64/asm-offsets.c 
b/xen/arch/x86/x86_64/asm-offsets.c
index 9695ea6..022c280 100644
--- a/xen/arch/x86/x86_64/asm-offsets.c
+++ b/xen/arch/x86/x86_64/asm-offsets.c
@@ -175,6 +175,7 @@ void __dummy__(void)
 OFFSET(MB2_fixed_total_size, multiboot2_fixed_t, total_size);
 OFFSET(MB2_tag_type, multiboot2_tag_t, type);
 OFFSET(MB2_tag_size, multiboot2_tag_t, size);
+OFFSET(MB2_load_base_addr, multiboot2_tag_load_base_addr_t, 
load_base_addr);
 OFFSET(MB2_mem_lower, multiboot2_tag_basic_meminfo_t, mem_lower);
 OFFSET(MB2_efi64_st, multiboot2_tag_efi64_t, pointer);
 OFFSET(MB2_efi64_ih, multiboot2_tag_efi64_ih_t, pointer);
diff --git a/xen/include/xen/multiboot2.h b/xen/include/xen/multiboot2.h
index 8dd5800..feb4297 100644
--- a/xen/include/xen/multiboot2.h
+++ b/xen/include/xen/multiboot2.h
@@ -59,11 +59,17 @@
 #define MULTIBOOT2_HEADER_TAG_EFI_BS   7
 #define MULTIBOOT2_HEADER_TAG_ENTRY_ADDRESS_EFI32  8
 #define MULTIBOOT2_HEADER_TAG_ENTRY_ADDRESS_EFI64  9
+#define MULTIBOOT2_HEADER_TAG_RELOCATABLE  10
 
 /* Header tag flags. */
 #define MULTIBOOT2_HEADER_TAG_REQUIRED 0
 #define MULTIBOOT2_HEADER_TAG_OPTIONAL 1
 
+/* Where image should be loaded (suggestion not requirement). */
+#define MULTIBOOT2_LOAD_PREFERENCE_NONE0
+#define MULTIBOOT2_LOAD_PREFERENCE_LOW 1
+#define MULTIBOOT2_LOAD_PREFERENCE_HIGH2
+
 /* Header console tag console_flags. */
 #define MULTIBOOT2_CONSOLE_FLAGS_CONSOLE_REQUIRED  1
 #define MULTIBOOT2_CONSOLE_FLAGS_EGA_TEXT_SUPPORTED2
@@ -90,6 +96,7 @@
 #define MULTIBOOT2_TAG_TYPE_EFI_BS 18
 #define MULTIBOOT2_TAG_TYPE_EFI32_IH   19
 #define MULTIBOOT2_TAG_TYPE_EFI64_IH   20
+#define MULTIBOOT2_TAG_TYPE_LOAD_BASE_ADDR 21
 
 /* Multiboot 2 tag alignment. */
 #define MULTIBOOT2_TAG_ALIGN  

[Xen-devel] [PATCH v5 13/16] x86: add multiboot2 protocol support for EFI platforms

[Daniel Kiper]

This way Xen can be loaded on EFI platforms using GRUB2 and
other boot loaders which support multiboot2 protocol.

Signed-off-by: Daniel Kiper 
---
v4 - suggestions/fixes:
   - remove redundant BSS alignment,
   - update BSS alignment check,
   - use __set_bit() instead of set_bit() if possible
 (suggested by Jan Beulich),
   - call efi_arch_cpu() from efi_multiboot2()
 even if the same work is done later in
 other place right now
 (suggested by Jan Beulich),
   - xen/arch/x86/efi/stub.c:efi_multiboot2()
 fail properly on EFI platforms,
   - do not read data beyond the end of multiboot2
 information in xen/arch/x86/boot/head.S
 (suggested by Jan Beulich),
   - use 32-bit registers in x86_64 code if possible
 (suggested by Jan Beulich),
   - multiboot2 information address is 64-bit
 in x86_64 code, so, treat it is as is
 (suggested by Jan Beulich),
   - use cmovcc if possible,
   - leave only one space between rep and stosq
 (suggested by Jan Beulich),
   - improve error handling,
   - improve early error messages,
 (suggested by Jan Beulich),
   - improve early error messages printing code,
   - improve label names
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Jan Beulich),
   - various minor cleanups.

v3 - suggestions/fixes:
   - take into account alignment when skipping multiboot2 fixed part
 (suggested by Konrad Rzeszutek Wilk),
   - improve segment registers initialization
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Jan Beulich and Konrad Rzeszutek Wilk),
   - improve commit message
 (suggested by Jan Beulich).

v2 - suggestions/fixes:
   - generate multiboot2 header using macros
 (suggested by Jan Beulich),
   - switch CPU to x86_32 mode before
 jumping to 32-bit code
 (suggested by Andrew Cooper),
   - reduce code changes to increase patch readability
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Jan Beulich),
   - ignore MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO tag on EFI platform
 and find on my own multiboot2.mem_lower value,
   - stop execution if EFI platform is detected
 in legacy BIOS path.
---
 xen/arch/x86/boot/head.S  |  243 ++---
 xen/arch/x86/efi/efi-boot.h   |   49 +++-
 xen/arch/x86/efi/stub.c   |   24 
 xen/arch/x86/x86_64/asm-offsets.c |2 +
 xen/arch/x86/xen.lds.S|4 +-
 xen/common/efi/boot.c |   11 ++
 6 files changed, 312 insertions(+), 21 deletions(-)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 5e61854..aca5370 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -89,6 +89,13 @@ multiboot2_header_start:
0, /* Number of the lines - no preference. */ \
0  /* Number of bits per pixel - no preference. */
 
+/* Inhibit bootloader from calling ExitBootServices(). */
+mb2ht_init MB2_HT(EFI_BS), MB2_HT(OPTIONAL)
+
+/* EFI64 entry point. */
+mb2ht_init MB2_HT(ENTRY_ADDRESS_EFI64), MB2_HT(OPTIONAL), \
+   sym_phys(__efi64_start)
+
 /* Multiboot2 header end tag. */
 mb2ht_init MB2_HT(END), MB2_HT(REQUIRED)
 .Lmultiboot2_header_end:
@@ -100,19 +107,45 @@ multiboot2_header_start:
 gdt_boot_descr:
 .word   6*8-1
 .long   sym_phys(trampoline_gdt)
+.long   0 /* Needed for 64-bit lgdt */
+
+cs32_switch_addr:
+.long   sym_phys(cs32_switch)
+.word   BOOT_CS32
+
+vga_text_buffer:
+.long   0xb8000
 
 .Lbad_cpu_msg: .asciz "ERR: Not a 64-bit CPU!"
 .Lbad_ldr_msg: .asciz "ERR: Not a Multiboot bootloader!"
+.Lbad_ldr_nbs: .asciz "ERR: Bootloader shutdown EFI x64 boot services!"
+.Lbad_ldr_nst: .asciz "ERR: EFI SystemTable is not provided by bootloader!"
+.Lbad_ldr_nih: .asciz "ERR: EFI ImageHandle is not provided by bootloader!"
+.Lbad_efi_msg: .asciz "ERR: EFI IA-32 platforms are not supported!"
 
 .section .init.text, "ax", @progbits
 
 bad_cpu:
 mov $(sym_phys(.Lbad_cpu_msg)),%esi # Error message
-jmp print_err
+jmp 0f
 not_multiboot:
 mov $(sym_phys(.Lbad_ldr_msg)),%esi # Error message
-print_err:
-mov $0xB8000,%edi  # VGA framebuffer
+jmp 0f
+mb2_no_st:
+mov $(sym_phys(.Lbad_ldr_nst)),%esi # Error message
+jmp 0f
+mb2_no_ih:
+mov $(sym_phys(.Lbad_ldr_nih)),%esi # Error message
+jmp 0f
+mb2_no_bs:
+mov $(sym_phys(.Lbad_ldr_nbs)),%esi # Error message
+xor %edi,%edi   # No VGA text buffer
+jmp 1f
+mb2_efi_ia_32:
+mov $(sym_phys(.Lbad_efi_msg)),%esi # Error message
+xor %edi,%edi   # No VGA text buffer
+jmp 1f
+0:  mov sym_phys(vga_text_buffer),%edi
 1:  mov (%esi),%bl
 test

[Xen-devel] [PATCH v5 14/16] x86/boot: implement early command line parser in C

[Daniel Kiper]

Current early command line parser implementation in assembler
is very difficult to change to relocatable stuff using segment
registers. This requires a lot of changes in very weird and
fragile code. So, reimplement this functionality in C. This
way code will be relocatable out of the box (without playing
with segment registers) and much easier to maintain.

Suggested-by: Andrew Cooper 
Signed-off-by: Daniel Kiper 
---
v4 - suggestions/fixes:
   - move to stdcall calling convention
 (suggested by Jan Beulich),
   - define bool_t and use it properly
 (suggested by Jan Beulich),
   - put list of delimiter chars into
 static const char[]
 (suggested by Jan Beulich),
   - use strlen() instead of strlen_opt()
 (suggested by Jan Beulich),
   - change strtoi() to strtoui() and
 optimize it a bit
 (suggested by Jan Beulich),
   - define strchr() and use it in strtoui()
 (suggested by Jan Beulich),
   - optimize vga_parse()
 (suggested by Jan Beulich),
   - move !cmdline check from assembly to C
 (suggested by Jan Beulich),
   - remove my name from copyright (Oracle requirement)
 (suggested by Konrad Rzeszutek Wilk).

v3 - suggestions/fixes:
   - optimize some code
 (suggested by Jan Beulich),
   - put VESA data into early_boot_opts_t members
 (suggested by Jan Beulich),
   - rename some functions and variables
 (suggested by Jan Beulich),
   - move around video.h include in xen/arch/x86/boot/trampoline.S
 (suggested by Jan Beulich),
   - fix coding style
 (suggested by Jan Beulich),
   - fix build with older GCC
 (suggested by Konrad Rzeszutek Wilk),
   - remove redundant comments
 (suggested by Jan Beulich),
   - add some comments
   - improve commit message
 (suggested by Jan Beulich).
---
 .gitignore |5 +-
 xen/arch/x86/Makefile  |2 +-
 xen/arch/x86/boot/Makefile |7 +-
 xen/arch/x86/boot/build32.mk   |2 +
 xen/arch/x86/boot/cmdline.S|  367 ---
 xen/arch/x86/boot/cmdline.c|  376 
 xen/arch/x86/boot/edd.S|3 -
 xen/arch/x86/boot/head.S   |8 +
 xen/arch/x86/boot/trampoline.S |   12 ++
 xen/arch/x86/boot/video.S  |7 -
 10 files changed, 408 insertions(+), 381 deletions(-)
 delete mode 100644 xen/arch/x86/boot/cmdline.S
 create mode 100644 xen/arch/x86/boot/cmdline.c

diff --git a/.gitignore b/.gitignore
index d193820..23637d8 100644
--- a/.gitignore
+++ b/.gitignore
@@ -248,9 +248,10 @@ xen/arch/arm/xen.lds
 xen/arch/x86/asm-offsets.s
 xen/arch/x86/boot/mkelf32
 xen/arch/x86/xen.lds
+xen/arch/x86/boot/cmdline.S
 xen/arch/x86/boot/reloc.S
-xen/arch/x86/boot/reloc.bin
-xen/arch/x86/boot/reloc.lnk
+xen/arch/x86/boot/*.bin
+xen/arch/x86/boot/*.lnk
 xen/arch/x86/efi.lds
 xen/arch/x86/efi/check.efi
 xen/arch/x86/efi/disabled
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 71ec34e..9464b7b 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -212,6 +212,6 @@ clean::
rm -f asm-offsets.s *.lds boot/*.o boot/*~ boot/core boot/mkelf32
rm -f $(BASEDIR)/.xen-syms.[0-9]* boot/.*.d
rm -f $(BASEDIR)/.xen.efi.[0-9]* efi/*.efi efi/disabled efi/mkreloc
-   rm -f boot/reloc.S boot/reloc.lnk boot/reloc.bin
+   rm -f boot/cmdline.S boot/reloc.S boot/*.lnk boot/*.bin
rm -f note.o
$(MAKE) -f $(BASEDIR)/Rules.mk -C test clean
diff --git a/xen/arch/x86/boot/Makefile b/xen/arch/x86/boot/Makefile
index 06893d8..d73cc76 100644
--- a/xen/arch/x86/boot/Makefile
+++ b/xen/arch/x86/boot/Makefile
@@ -1,9 +1,14 @@
 obj-bin-y += head.o
 
+CMDLINE_DEPS = video.h
+
 RELOC_DEPS = $(BASEDIR)/include/asm-x86/config.h 
$(BASEDIR)/include/xen/multiboot.h \
 $(BASEDIR)/include/xen/multiboot2.h
 
-head.o: reloc.S
+head.o: cmdline.S reloc.S
+
+cmdline.S: cmdline.c $(CMDLINE_DEPS)
+   $(MAKE) -f build32.mk $@ CMDLINE_DEPS="$(CMDLINE_DEPS)"
 
 reloc.S: reloc.c $(RELOC_DEPS)
$(MAKE) -f build32.mk $@ RELOC_DEPS="$(RELOC_DEPS)"
diff --git a/xen/arch/x86/boot/build32.mk b/xen/arch/x86/boot/build32.mk
index 39e6453..3d01698 100644
--- a/xen/arch/x86/boot/build32.mk
+++ b/xen/arch/x86/boot/build32.mk
@@ -32,6 +32,8 @@ CFLAGS := $(filter-out -flto,$(CFLAGS))
 %.o: %.c
$(CC) $(CFLAGS) -c -fpic $< -o $@
 
+cmdline.o: cmdline.c $(CMDLINE_DEPS)
+
 reloc.o: reloc.c $(RELOC_DEPS)
 
 .PRECIOUS: %.bin %.lnk
diff --git a/xen/arch/x86/boot/cmdline.S b/xen/arch/x86/boot/cmdline.S
deleted file mode 100644
index 00687eb..000
--- a/xen/arch/x86/boot/cmdline.S
+++ /dev/null
@@ -1,367 +0,0 @@
-/**
- * cmdline.S
- *
- * Early command-line parsing.
- */
-
-.code32
-
-#include "video.h"
-
-# NB. String pointer on stack is modified to point past parsed digits.
-.Latoi:
-push%ebx
-push%ecx

[Xen-devel] [PATCH v5 12/16] x86/efi: create new early memory allocator

[Daniel Kiper]

There is a problem with place_string() which is used as early memory
allocator. It gets memory chunks starting from start symbol and goes
down. Sadly this does not work when Xen is loaded using multiboot2
protocol because then the start lives on 1 MiB address and we should
not allocate a memory from below of it. So, I tried to use mem_lower
address calculated by GRUB2. However, this solution works only on some
machines. There are machines in the wild (e.g. Dell PowerEdge R820)
which uses first ~640 KiB for boot services code or data... :-(((
Hence, we need new memory allocator for Xen EFI boot code which is
quite simple and generic and could be used by place_string() and
efi_arch_allocate_mmap_buffer(). I think about following solutions:

1) We could use native EFI allocation functions (e.g. AllocatePool()
   or AllocatePages()) to get memory chunk. However, later (somewhere
   in __start_xen()) we must copy its contents to safe place or reserve
   it in e820 memory map and map it in Xen virtual address space. This
   means that the code referring to Xen command line, loaded modules and
   EFI memory map, mostly in __start_xen(), will be further complicated
   and diverge from legacy BIOS cases. Additionally, both former things
   have to be placed below 4 GiB because their addresses are stored in
   multiboot_info_t structure which has 32-bit relevant members.

2) We may allocate memory area statically somewhere in Xen code which
   could be used as memory pool for early dynamic allocations. Looks
   quite simple. Additionally, it would not depend on EFI at all and
   could be used on legacy BIOS platforms if we need it. However, we
   must carefully choose size of this pool. We do not want increase Xen
   binary size too much and waste too much memory but also we must fit
   at least memory map on x86 EFI platforms. As I saw on small machine,
   e.g. IBM System x3550 M2 with 8 GiB RAM, memory map may contain more
   than 200 entries. Every entry on x86-64 platform is 40 bytes in size.
   So, it means that we need more than 8 KiB for EFI memory map only.
   Additionally, if we use this memory pool for Xen and modules command
   line storage (it would be used when xen.efi is executed as EFI application)
   then we should add, I think, about 1 KiB. In this case, to be on safe
   side, we should assume at least 64 KiB pool for early memory allocations.
   Which is about 4 times of our earlier calculations. However, during
   discussion on Xen-devel Jan Beulich suggested that just in case we should
   use 1 MiB memory pool like it is in original place_string() implementation.
   So, let's use 1 MiB as it was proposed. If we think that we should not
   waste unallocated memory in the pool on running system then we can mark
   this region as __initdata and move all required data to dynamically
   allocated places somewhere in __start_xen().

2a) We could put memory pool into .bss.page_aligned section. Then allocate
memory chunks starting from the lowest address. After init phase we can
free unused portion of the memory pool as in case of .init.text or 
.init.data
sections. This way we do not need to allocate any space in image file and
freeing of unused area in the memory pool is very simple.

Now #2a solution is implemented because it is quite simple and requires
limited number of changes, especially in __start_xen().

Signed-off-by: Daniel Kiper 
---
v4 - suggestions/fixes:
   - move from #2 solution to #2a solution,
   - improve commit message.
---
 xen/arch/x86/efi/efi-boot.h |   58 +--
 xen/arch/x86/efi/stub.c |2 ++
 xen/arch/x86/setup.c|5 ++--
 xen/include/xen/efi.h   |1 +
 4 files changed, 56 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h
index 1fa9e47..3f87b7c 100644
--- a/xen/arch/x86/efi/efi-boot.h
+++ b/xen/arch/x86/efi/efi-boot.h
@@ -103,9 +103,56 @@ static void __init relocate_trampoline(unsigned long phys)
 *(u16 *)(*trampoline_ptr + (long)trampoline_ptr) = phys >> 4;
 }
 
+#define EBMALLOC_SIZE  MB(1)
+
+static char __section(".bss.page_aligned") ebmalloc_mem[EBMALLOC_SIZE];
+static char __initdata *ebmalloc_free = NULL;
+
+/* EFI boot allocator. */
+static void __init *ebmalloc(size_t size)
+{
+void *ptr;
+
+/*
+ * Init ebmalloc_free on runtime. Static initialization
+ * will not work because it puts virtual address there.
+ */
+if ( ebmalloc_free == NULL )
+ebmalloc_free = ebmalloc_mem;
+
+ptr = ebmalloc_free;
+
+ebmalloc_free += size;
+
+if ( ebmalloc_free - ebmalloc_mem > sizeof(ebmalloc_mem) )
+blexit(L"Out of static memory\r\n");
+
+return ptr;
+}
+
+void __init free_ebmalloc_unused_mem(void)
+{
+unsigned long start, end;
+
+if ( ebmalloc_free )
+{
+start = (unsigned long)ebmalloc_free - xen_phys_start;
+start = PAGE_ALIGN(start + 

[Xen-devel] [PATCH v5 08/16] x86/boot/reloc: rename some variables and rearrange code a bit

[Daniel Kiper]

Replace mbi with mbi_out and mbi_old with mbi_in and rearrange code
a bit to make it more readable. Additionally, this way multiboot (v1)
protocol implementation and future multiboot2 protocol implementation
will use the same variable naming convention.

Signed-off-by: Daniel Kiper 
Acked-by: Jan Beulich 
---
v4 - suggestions/fixes:
   - move to stdcall calling convention.

v3 - suggestions/fixes:
   - improve commit message
 (suggested by Konrad Rzeszutek Wilk).

v2 - suggestions/fixes:
   - extract this change from main mutliboot2
 protocol implementation
 (suggested by Jan Beulich).
---
 xen/arch/x86/boot/reloc.c |   39 ---
 1 file changed, 20 insertions(+), 19 deletions(-)

diff --git a/xen/arch/x86/boot/reloc.c b/xen/arch/x86/boot/reloc.c
index 21b1f32..dc6a435 100644
--- a/xen/arch/x86/boot/reloc.c
+++ b/xen/arch/x86/boot/reloc.c
@@ -63,45 +63,46 @@ static u32 copy_string(u32 src)
 return copy_mem(src, p - src + 1);
 }
 
-multiboot_info_t __stdcall *reloc(u32 mbi_old, u32 trampoline)
+multiboot_info_t __stdcall *reloc(u32 mbi_in, u32 trampoline)
 {
-multiboot_info_t *mbi;
 int i;
+multiboot_info_t *mbi_out;
 
 alloc = trampoline;
 
-mbi = (multiboot_info_t *)copy_mem(mbi_old, sizeof(*mbi));
+mbi_out = (multiboot_info_t *)copy_mem(mbi_in, sizeof(*mbi_out));
 
-if ( mbi->flags & MBI_CMDLINE )
-mbi->cmdline = copy_string(mbi->cmdline);
+if ( mbi_out->flags & MBI_CMDLINE )
+mbi_out->cmdline = copy_string(mbi_out->cmdline);
 
-if ( mbi->flags & MBI_MODULES )
+if ( mbi_out->flags & MBI_MODULES )
 {
 module_t *mods;
 
-mbi->mods_addr = copy_mem(mbi->mods_addr, mbi->mods_count * 
sizeof(module_t));
+mbi_out->mods_addr = copy_mem(mbi_out->mods_addr,
+  mbi_out->mods_count * sizeof(module_t));
 
-mods = (module_t *)mbi->mods_addr;
+mods = (module_t *)mbi_out->mods_addr;
 
-for ( i = 0; i < mbi->mods_count; i++ )
+for ( i = 0; i < mbi_out->mods_count; i++ )
 {
 if ( mods[i].string )
 mods[i].string = copy_string(mods[i].string);
 }
 }
 
-if ( mbi->flags & MBI_MEMMAP )
-mbi->mmap_addr = copy_mem(mbi->mmap_addr, mbi->mmap_length);
+if ( mbi_out->flags & MBI_MEMMAP )
+mbi_out->mmap_addr = copy_mem(mbi_out->mmap_addr, 
mbi_out->mmap_length);
 
-if ( mbi->flags & MBI_LOADERNAME )
-mbi->boot_loader_name = copy_string(mbi->boot_loader_name);
+if ( mbi_out->flags & MBI_LOADERNAME )
+mbi_out->boot_loader_name = copy_string(mbi_out->boot_loader_name);
 
 /* Mask features we don't understand or don't relocate. */
-mbi->flags &= (MBI_MEMLIMITS |
-   MBI_CMDLINE |
-   MBI_MODULES |
-   MBI_MEMMAP |
-   MBI_LOADERNAME);
+mbi_out->flags &= (MBI_MEMLIMITS |
+   MBI_CMDLINE |
+   MBI_MODULES |
+   MBI_MEMMAP |
+   MBI_LOADERNAME);
 
-return mbi;
+return mbi_out;
 }
-- 
1.7.10.4


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

[Xen-devel] [PATCH v5 09/16] x86: add multiboot2 protocol support

[Daniel Kiper]

Add multiboot2 protocol support. Alter min memory limit handling as we
now may not find it from either multiboot (v1) or multiboot2.

This way we are laying the foundation for EFI + GRUB2 + Xen development.

Signed-off-by: Daniel Kiper 
---
v5 - suggestions/fixes:
   - check multiboot2_tag_mmap_t.entry_size before
 multiboot2_tag_mmap_t.entries[] use
 (suggested by Jan Beulich),
   - properly index multiboot2_tag_mmap_t.entries[]
 (suggested by Jan Beulich),
   - use "type name[]" instad of "type name[0]"
 in xen/include/xen/multiboot2.h
 (suggested by Jan Beulich),
   - remove unneeded comment
 (suggested by Jan Beulich).

v4 - suggestions/fixes:
   - avoid assembly usage in xen/arch/x86/boot/reloc.c,
   - fix boundary check issue and optimize
 for() loops in mbi2_mbi(),
   - move to stdcall calling convention,
   - remove unneeded typeof() from ALIGN_UP() macro
 (suggested by Jan Beulich),
   - add and use NULL definition in xen/arch/x86/boot/reloc.c
 (suggested by Jan Beulich),
   - do not read data beyond the end of multiboot2
 information in xen/arch/x86/boot/head.S
 (suggested by Jan Beulich),
   - add :req to some .macro arguments
 (suggested by Jan Beulich),
   - use cmovcc if possible,
   - add .L to multiboot2_header_end label
 (suggested by Jan Beulich),
   - add .L to multiboot2_proto label
 (suggested by Jan Beulich),
   - improve label names
 (suggested by Jan Beulich).

v3 - suggestions/fixes:
   - reorder reloc() arguments
 (suggested by Jan Beulich),
   - remove .L from multiboot2 header labels
 (suggested by Andrew Cooper, Jan Beulich and Konrad Rzeszutek Wilk),
   - take into account alignment when skipping multiboot2 fixed part
 (suggested by Konrad Rzeszutek Wilk),
   - create modules data if modules count != 0
 (suggested by Jan Beulich),
   - improve macros
 (suggested by Jan Beulich),
   - reduce number of casts
 (suggested by Jan Beulich),
   - use const if possible
 (suggested by Jan Beulich),
   - drop static and __used__ attribute from reloc()
 (suggested by Jan Beulich),
   - remove isolated/stray __packed attribute from
 multiboot2_memory_map_t type definition
 (suggested by Jan Beulich),
   - reformat xen/include/xen/multiboot2.h
 (suggested by Konrad Rzeszutek Wilk),
   - improve comments
 (suggested by Konrad Rzeszutek Wilk),
   - remove hard tabs
 (suggested by Jan Beulich and Konrad Rzeszutek Wilk).

v2 - suggestions/fixes:
   - generate multiboot2 header using macros
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Jan Beulich),
   - simplify assembly in xen/arch/x86/boot/head.S
 (suggested by Jan Beulich),
   - do not include include/xen/compiler.h
 in xen/arch/x86/boot/reloc.c
 (suggested by Jan Beulich),
   - do not read data beyond the end of multiboot2 information
 (suggested by Jan Beulich).

v2 - not fixed yet:
   - dynamic dependency generation for xen/arch/x86/boot/reloc.S;
 this requires more work; I am not sure that it pays because
 potential patch requires more changes than addition of just
 multiboot2.h to Makefile
 (suggested by Jan Beulich),
   - isolated/stray __packed attribute usage for multiboot2_memory_map_t
 (suggested by Jan Beulich).
---
 xen/arch/x86/boot/Makefile|3 +-
 xen/arch/x86/boot/head.S  |  107 ++-
 xen/arch/x86/boot/reloc.c |  144 +--
 xen/arch/x86/x86_64/asm-offsets.c |9 ++
 xen/include/xen/multiboot2.h  |  169 +
 5 files changed, 422 insertions(+), 10 deletions(-)
 create mode 100644 xen/include/xen/multiboot2.h

diff --git a/xen/arch/x86/boot/Makefile b/xen/arch/x86/boot/Makefile
index 5fdb5ae..06893d8 100644
--- a/xen/arch/x86/boot/Makefile
+++ b/xen/arch/x86/boot/Makefile
@@ -1,6 +1,7 @@
 obj-bin-y += head.o
 
-RELOC_DEPS = $(BASEDIR)/include/asm-x86/config.h 
$(BASEDIR)/include/xen/multiboot.h
+RELOC_DEPS = $(BASEDIR)/include/asm-x86/config.h 
$(BASEDIR)/include/xen/multiboot.h \
+$(BASEDIR)/include/xen/multiboot2.h
 
 head.o: reloc.S
 
diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index ffafcb5..5e61854 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -1,5 +1,6 @@
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -19,6 +20,28 @@
 #define BOOT_PSEUDORM_CS 0x0020
 #define BOOT_PSEUDORM_DS 0x0028
 
+#define MB2_HT(name)  (MULTIBOOT2_HEADER_TAG_##name)
+#define MB2_TT(name)  (MULTIBOOT2_TAG_TYPE_##name)
+
+.macro mb2ht_args arg:req, args:vararg
+.long \arg
+.ifnb \args
+mb2ht_args \args
+.endif
+.endm
+
+.macro mb2ht_init type:req, req:req, args:vararg
+.align MULTIBOOT2_TAG_ALIGN
+.Lmb2ht_init_start\@:
+.short \type
+.short \req
+.long .Lmb2ht_init_end\@ - 

Re: [Xen-devel] unable start xen in hikey

[Kamenee Arumugam]

Hi Julien/Chen,

Thanks, it is working for me after setting CONFIG_ARCH_HISI = y in config
file. So, when i tried to boot linux thru startup.sh, it seems to hangs and
below are the traces of log:

Press ESC in 1 seconds to skip startup.nsh or any other key to continue.
Shell> FS0:
FS0:\> Image console=ttyAMA3,115200 root=/dev/mmcblk1p4 rootwait rw
efi=noruntime
EFI stub: Booting Linux Kernel...
EFI stub: Generating empty DTB
EFI stub: Exiting boot services and installing virtual address map...

Am I missing some configuration in my kernel or patches to handle virtual
address map?


Thanks,
Kamenee

On Fri, Aug 19, 2016 at 10:02 AM, Julien Grall  wrote:

> Hello,
>
> On 18/08/16 22:11, Kamenee Arumugam wrote:
>
>> I am using linux kernel from 96 boards repo:
>>  https://github.com/96boards/linux.git
>>  and I compile using this command
>> as below:
>>
>> make Image -j24 arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
>>
>
> What is your .config? Have you enabled the related option for XEN?
>
> Below a list of Xen specific options I have enabled in my kernel:
>
> CONFIG_XEN_DOM0=y
> CONFIG_XEN=y
> CONFIG_XEN_BLKDEV_FRONTEND=y
> CONFIG_XEN_BLKDEV_BACKEND=y
> CONFIG_XEN_NETDEV_FRONTEND=y
> CONFIG_XEN_NETDEV_BACKEND=y
> CONFIG_HVC_XEN=y
> CONFIG_HVC_XEN_FRONTEND=y
> CONFIG_XEN_FBDEV_FRONTEND=y
> CONFIG_XEN_BALLOON=y
> CONFIG_XEN_SCRUB_PAGES=y
> CONFIG_XEN_DEV_EVTCHN=y
> CONFIG_XEN_BACKEND=y
> CONFIG_XENFS=y
> CONFIG_XEN_COMPAT_XENFS=y
> CONFIG_XEN_SYS_HYPERVISOR=y
> CONFIG_XEN_XENBUS_FRONTEND=y
> CONFIG_XEN_GNTDEV=y
> CONFIG_XEN_GRANT_DEV_ALLOC=y
> CONFIG_SWIOTLB_XEN=y
> CONFIG_XEN_PRIVCMD=y
> CONFIG_XEN_EFI=y
> CONFIG_XEN_AUTO_XLATE=y
>
> Regards,
>
> --
> Julien Grall
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v5 10/16] efi: create efi_enabled()

[Daniel Kiper]

First of all we need to differentiate between legacy BIOS
and EFI platforms during runtime, not during build, because
one image will have legacy and EFI code and can be executed
on both platforms. Additionally, we need more fine grained
knowledge about EFI environment and check for EFI platform
and EFI loader separately to properly support multiboot2
protocol. In general Xen loaded by this protocol uses memory
mappings and loaded modules in similar way to Xen loaded by
multiboot (v1) protocol. Hence, create efi_enabled() which
checks available features in efi_flags. This patch defines
EFI_BOOT, EFI_LOADER and EFI_RS features. EFI_BOOT is equal
to old efi_enabled == 1. EFI_RS ease control on runtime
services usage. EFI_LOADER tells that Xen was loaded
directly from EFI as PE executable.

Suggested-by: Jan Beulich 
Signed-off-by: Daniel Kiper 
---
v5 - suggestions/fixes:
   - squash three patches into one
 (suggested by Jan Beulich),
   - introduce all features at once
 (suggested by Jan Beulich),
   - efi_enabled() returns bool_t
 instead of unsigned int
 (suggested by Jan Beulich),
   - update commit message.

v4 - suggestions/fixes:
   - rename EFI_PLATFORM to EFI_BOOT
 (suggested by Jan Beulich),
   - move EFI_BOOT definition to efi struct definition
 (suggested by Jan Beulich),
   - remove unneeded efi.flags initialization
 (suggested by Jan Beulich),
   - use __set_bit() instead of set_bit() if possible
 (suggested by Jan Beulich),
   - do efi_enabled() cleanup
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Jan Beulich),
   - improve commit message.

v3 - suggestions/fixes:
   - define efi struct in xen/arch/x86/efi/stub.c
 in earlier patch
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Jan Beulich),
   - improve commit message
 (suggested by Jan Beulich).
---
 xen/arch/x86/dmi_scan.c|4 ++--
 xen/arch/x86/domain_page.c |2 +-
 xen/arch/x86/efi/stub.c|7 ---
 xen/arch/x86/mpparse.c |4 ++--
 xen/arch/x86/setup.c   |   14 --
 xen/arch/x86/shutdown.c|4 ++--
 xen/arch/x86/time.c|2 +-
 xen/common/efi/boot.c  |   17 +
 xen/common/efi/runtime.c   |   15 +--
 xen/drivers/acpi/osl.c |2 +-
 xen/include/xen/efi.h  |9 +++--
 11 files changed, 50 insertions(+), 30 deletions(-)

diff --git a/xen/arch/x86/dmi_scan.c b/xen/arch/x86/dmi_scan.c
index b049e31..8dcb640 100644
--- a/xen/arch/x86/dmi_scan.c
+++ b/xen/arch/x86/dmi_scan.c
@@ -238,7 +238,7 @@ const char *__init dmi_get_table(paddr_t *base, u32 *len)
 {
static unsigned int __initdata instance;
 
-   if (efi_enabled) {
+   if (efi_enabled(EFI_BOOT)) {
if (efi_smbios3_size && !(instance & 1)) {
*base = efi_smbios3_address;
*len = efi_smbios3_size;
@@ -696,7 +696,7 @@ static void __init dmi_decode(struct dmi_header *dm)
 
 void __init dmi_scan_machine(void)
 {
-   if ((!efi_enabled ? dmi_iterate(dmi_decode) :
+   if ((!efi_enabled(EFI_BOOT) ? dmi_iterate(dmi_decode) :
dmi_efi_iterate(dmi_decode)) == 0)
dmi_check_system(dmi_blacklist);
else
diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c
index d86f8fe..7541b91 100644
--- a/xen/arch/x86/domain_page.c
+++ b/xen/arch/x86/domain_page.c
@@ -36,7 +36,7 @@ static inline struct vcpu *mapcache_current_vcpu(void)
  * domain's page tables but current may point at another domain's VCPU.
  * Return NULL as though current is not properly set up yet.
  */
-if ( efi_enabled && efi_rs_using_pgtables() )
+if ( efi_enabled(EFI_RS) && efi_rs_using_pgtables() )
 return NULL;
 
 /*
diff --git a/xen/arch/x86/efi/stub.c b/xen/arch/x86/efi/stub.c
index 07c2bd0..f087023 100644
--- a/xen/arch/x86/efi/stub.c
+++ b/xen/arch/x86/efi/stub.c
@@ -4,9 +4,10 @@
 #include 
 #include 
 
-#ifndef efi_enabled
-const bool_t efi_enabled = 0;
-#endif
+bool_t efi_enabled(int feature)
+{
+return false;
+}
 
 void __init efi_init_memory(void) { }
 
diff --git a/xen/arch/x86/mpparse.c b/xen/arch/x86/mpparse.c
index ef6557c..c3d5bdc 100644
--- a/xen/arch/x86/mpparse.c
+++ b/xen/arch/x86/mpparse.c
@@ -564,7 +564,7 @@ static inline void __init construct_default_ISA_mptable(int 
mpc_default_type)
 
 static __init void efi_unmap_mpf(void)
 {
-   if (efi_enabled)
+   if (efi_enabled(EFI_BOOT))
clear_fixmap(FIX_EFI_MPF);
 }
 
@@ -722,7 +722,7 @@ void __init find_smp_config (void)
 {
unsigned int address;
 
-   if (efi_enabled) {
+   if (efi_enabled(EFI_BOOT)) {
efi_check_config();
return;
}
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 8ae897a..360ca59 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -439,8 

[Xen-devel] [PATCH v5 11/16] efi: build xen.gz with EFI code

[Daniel Kiper]

Build xen.gz with EFI code. We need this to support multiboot2
protocol on EFI platforms.

If we wish to load non-ELF file using multiboot (v1) or multiboot2 then
it must contain "linear" (or "flat") representation of code and data.
This is requirement of both boot protocols. Currently, PE file contains
many sections which are not "linear" (one after another without any holes)
or even do not have representation in a file (e.g. BSS). From EFI point
of view everything is OK and works. However, this file layout cannot be
properly interpreted by multiboot protocols family. In theory there is
a chance that we could build proper PE file (from multiboot protocols POV)
using current build system. However, it means that xen.efi further diverge
from Xen ELF file (in terms of contents and build method). On the other
hand ELF has all needed properties. So, it means that this is good starting
point for further development. Additionally, I think that this is also good
starting point for further xen.efi code and build optimizations. It looks
that there is a chance that finally we can generate xen.efi directly from
Xen ELF using just simple objcopy or other tool. This way we will have one
Xen binary which can be loaded by three boot protocols: EFI native loader,
multiboot (v1) and multiboot2.

Signed-off-by: Daniel Kiper 
Acked-by: Jan Beulich 
---
v5 - suggestions/fixes:
   - properly calculate efi symbol address in
 xen/arch/x86/xen.lds.S (I hope that this
 change does not invalidate Jan's ACK).

v4 - suggestions/fixes:
   - functions should return -ENOSYS instead
 of -EOPNOTSUPP if EFI runtime services
 are not available
 (suggested by Jan Beulich),
   - remove stale bits from xen/arch/x86/Makefile
 (suggested by Jan Beulich).

v3 - suggestions/fixes:
   - check for EFI platform in EFI code
 (suggested by Jan Beulich),
   - fix Makefiles
 (suggested by Jan Beulich),
   - improve commit message
 (suggested by Jan Beulich).

v2 - suggestions/fixes:
   - build EFI code only if it is supported in a given build environment
 (suggested by Jan Beulich).
---
 xen/arch/x86/Makefile |2 +-
 xen/arch/x86/efi/Makefile |   11 +++
 xen/arch/x86/xen.lds.S|4 ++--
 xen/common/efi/boot.c |3 +++
 xen/common/efi/runtime.c  |6 ++
 5 files changed, 15 insertions(+), 11 deletions(-)

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index b18f033..71ec34e 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -211,7 +211,7 @@ efi/mkreloc: efi/mkreloc.c
 clean::
rm -f asm-offsets.s *.lds boot/*.o boot/*~ boot/core boot/mkelf32
rm -f $(BASEDIR)/.xen-syms.[0-9]* boot/.*.d
-   rm -f $(BASEDIR)/.xen.efi.[0-9]* efi/*.o efi/.*.d efi/*.efi 
efi/disabled efi/mkreloc
+   rm -f $(BASEDIR)/.xen.efi.[0-9]* efi/*.efi efi/disabled efi/mkreloc
rm -f boot/reloc.S boot/reloc.lnk boot/reloc.bin
rm -f note.o
$(MAKE) -f $(BASEDIR)/Rules.mk -C test clean
diff --git a/xen/arch/x86/efi/Makefile b/xen/arch/x86/efi/Makefile
index 5099430..2a7d3e5 100644
--- a/xen/arch/x86/efi/Makefile
+++ b/xen/arch/x86/efi/Makefile
@@ -1,14 +1,9 @@
 CFLAGS += -fshort-wchar
 
-obj-y += stub.o
-
-create = test -e $(1) || touch -t 19990101 $(1)
-
 efi := y$(shell rm -f disabled)
 efi := $(if $(efi),$(shell $(CC) $(filter-out $(CFLAGS-y) .%.d,$(CFLAGS)) -c 
check.c 2>disabled && echo y))
 efi := $(if $(efi),$(shell $(LD) -mi386pep --subsystem=10 -o check.efi check.o 
2>disabled && echo y))
-efi := $(if $(efi),$(shell rm disabled)y,$(shell $(call create,boot.init.o); 
$(call create,runtime.o)))
+efi := $(if $(efi),$(shell rm disabled)y)
 
-extra-$(efi) += boot.init.o relocs-dummy.o runtime.o compat.o
-
-stub.o: $(extra-y)
+obj-y := stub.o
+obj-$(efi) := boot.init.o compat.o relocs-dummy.o runtime.o
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 2d1d43d..40eb4c5 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -262,10 +262,10 @@ SECTIONS
   .pad : {
 . = ALIGN(MB(16));
   } :text
-#else
-  efi = .;
 #endif
 
+  efi = DEFINED(efi) ? efi : .;
+
   /* Sections to be discarded */
   /DISCARD/ : {
*(.exit.text)
diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index d7c484e..48ef8ad 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -1249,6 +1249,9 @@ void __init efi_init_memory(void)
 } *extra, *extra_head = NULL;
 #endif
 
+if ( !efi_enabled(EFI_BOOT) )
+return;
+
 printk(XENLOG_INFO "EFI memory map:%s\n",
map_bs ? " (mapping BootServices)" : "");
 for ( i = 0; i < efi_memmap_size; i += efi_mdesc_size )
diff --git a/xen/common/efi/runtime.c b/xen/common/efi/runtime.c
index 6bffda0..64c632c 100644
--- a/xen/common/efi/runtime.c
+++ b/xen/common/efi/runtime.c
@@ -175,6 +175,9 @@ int efi_get_info(uint32_t idx, union xenpf_efi_info *info)
 {
 unsigned int i, n;
 
+if ( 

[Xen-devel] [PATCH v5 07/16] x86/boot: use %ecx instead of %eax

[Daniel Kiper]

Use %ecx instead of %eax to store low memory upper limit from EBDA.
This way we do not wipe multiboot protocol identifier. It is needed
in reloc() to differentiate between multiboot (v1) and
multiboot2 protocol.

Signed-off-by: Daniel Kiper 
Reviewed-by: Andrew Cooper 
Reviewed-by: Konrad Rzeszutek Wilk 
---
 xen/arch/x86/boot/head.S |   24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 7e5ae12..ffafcb5 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -87,14 +87,14 @@ __start:
 jne not_multiboot
 
 /* Set up trampoline segment 64k below EBDA */
-movzwl  0x40e,%eax  /* EBDA segment */
-cmp $0xa000,%eax/* sanity check (high) */
+movzwl  0x40e,%ecx  /* EBDA segment */
+cmp $0xa000,%ecx/* sanity check (high) */
 jae 0f
-cmp $0x4000,%eax/* sanity check (low) */
+cmp $0x4000,%ecx/* sanity check (low) */
 jae 1f
 0:
-movzwl  0x413,%eax  /* use base memory size on failure */
-shl $10-4,%eax
+movzwl  0x413,%ecx  /* use base memory size on failure */
+shl $10-4,%ecx
 1:
 /*
  * Compare the value in the BDA with the information from the
@@ -106,20 +106,20 @@ __start:
 cmp $0x100,%edx /* is the multiboot value too small? */
 jb  2f  /* if so, do not use it */
 shl $10-4,%edx
-cmp %eax,%edx   /* compare with BDA value */
-cmovb   %edx,%eax   /* and use the smaller */
+cmp %ecx,%edx   /* compare with BDA value */
+cmovb   %edx,%ecx   /* and use the smaller */
 
 2:  /* Reserve 64kb for the trampoline */
-sub $0x1000,%eax
+sub $0x1000,%ecx
 
 /* From arch/x86/smpboot.c: start_eip had better be page-aligned! */
-xor %al, %al
-shl $4, %eax
-mov %eax,sym_phys(trampoline_phys)
+xor %cl, %cl
+shl $4, %ecx
+mov %ecx,sym_phys(trampoline_phys)
 
 /* Save the Multiboot info struct (after relocation) for later use. */
 mov $sym_phys(cpu0_stack)+1024,%esp
-push%eax/* Boot trampoline address. */
+push%ecx/* Boot trampoline address. */
 push%ebx/* Multiboot information address. */
 callreloc
 mov %eax,sym_phys(multiboot_ptr)
-- 
1.7.10.4


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

[Xen-devel] [PATCH v5 06/16] x86/boot/reloc: create generic alloc and copy functions

[Daniel Kiper]

Create generic alloc and copy functions. We need
separate tools for memory allocation and copy to
provide multiboot2 protocol support.

Signed-off-by: Daniel Kiper 
---
v4 - suggestions/fixes:
   - avoid assembly usage.

v3 - suggestions/fixes:
   - use "g" constraint instead of "r" for alloc_mem() bytes argument
 (suggested by Jan Beulich).

v2 - suggestions/fixes:
   - generalize new functions names
 (suggested by Jan Beulich),
   - reduce number of casts
 (suggested by Jan Beulich).
---
 xen/arch/x86/boot/reloc.c |   51 ++---
 1 file changed, 30 insertions(+), 21 deletions(-)

diff --git a/xen/arch/x86/boot/reloc.c b/xen/arch/x86/boot/reloc.c
index 28c6cea..21b1f32 100644
--- a/xen/arch/x86/boot/reloc.c
+++ b/xen/arch/x86/boot/reloc.c
@@ -32,60 +32,69 @@ typedef unsigned int u32;
 
 static u32 alloc;
 
-static void *reloc_mbi_struct(void *old, unsigned int bytes)
+static u32 alloc_mem(u32 bytes)
 {
-void *new;
+return alloc -= ALIGN_UP(bytes, 16);
+}
 
-alloc -= ALIGN_UP(bytes, 16);
-new = (void *)alloc;
+static u32 copy_mem(u32 src, u32 bytes)
+{
+u32 dst, dst_ret;
+
+dst = alloc_mem(bytes);
+dst_ret = dst;
 
 while ( bytes-- )
-*(char *)new++ = *(char *)old++;
+*(char *)dst++ = *(char *)src++;
 
-return (void *)alloc;
+return dst_ret;
 }
 
-static char *reloc_mbi_string(char *old)
+static u32 copy_string(u32 src)
 {
-char *p;
-for ( p = old; *p != '\0'; p++ )
+u32 p;
+
+if ( src == 0 )
+return 0;
+
+for ( p = src; *(char *)p != '\0'; p++ )
 continue;
-return reloc_mbi_struct(old, p - old + 1);
+
+return copy_mem(src, p - src + 1);
 }
 
-multiboot_info_t __stdcall *reloc(multiboot_info_t *mbi_old, u32 trampoline)
+multiboot_info_t __stdcall *reloc(u32 mbi_old, u32 trampoline)
 {
 multiboot_info_t *mbi;
 int i;
 
 alloc = trampoline;
 
-mbi = reloc_mbi_struct(mbi_old, sizeof(*mbi));
+mbi = (multiboot_info_t *)copy_mem(mbi_old, sizeof(*mbi));
 
 if ( mbi->flags & MBI_CMDLINE )
-mbi->cmdline = (u32)reloc_mbi_string((char *)mbi->cmdline);
+mbi->cmdline = copy_string(mbi->cmdline);
 
 if ( mbi->flags & MBI_MODULES )
 {
-module_t *mods = reloc_mbi_struct(
-(module_t *)mbi->mods_addr, mbi->mods_count * sizeof(module_t));
+module_t *mods;
 
-mbi->mods_addr = (u32)mods;
+mbi->mods_addr = copy_mem(mbi->mods_addr, mbi->mods_count * 
sizeof(module_t));
+
+mods = (module_t *)mbi->mods_addr;
 
 for ( i = 0; i < mbi->mods_count; i++ )
 {
 if ( mods[i].string )
-mods[i].string = (u32)reloc_mbi_string((char *)mods[i].string);
+mods[i].string = copy_string(mods[i].string);
 }
 }
 
 if ( mbi->flags & MBI_MEMMAP )
-mbi->mmap_addr = (u32)reloc_mbi_struct(
-(memory_map_t *)mbi->mmap_addr, mbi->mmap_length);
+mbi->mmap_addr = copy_mem(mbi->mmap_addr, mbi->mmap_length);
 
 if ( mbi->flags & MBI_LOADERNAME )
-mbi->boot_loader_name = (u32)reloc_mbi_string(
-(char *)mbi->boot_loader_name);
+mbi->boot_loader_name = copy_string(mbi->boot_loader_name);
 
 /* Mask features we don't understand or don't relocate. */
 mbi->flags &= (MBI_MEMLIMITS |
-- 
1.7.10.4


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

[Xen-devel] [PATCH v5 05/16] x86/boot: call reloc() using stdcall calling convention

[Daniel Kiper]

Current reloc() call method makes confusion and does not scale well
for more arguments. And subsequent patch adding multiboot2 protocol
support have to pass 3 arguments instead of 2. Hence, move reloc()
call to stdcall calling convention. One may argue that we should use
standard cdecl calling convention. However, stdcall is better here
than cdecl because we do not need to remove "manually" arguments from
stack in xen/arch/x86/boot/head.S assembly file.

Suggested-by: Jan Beulich 
Signed-off-by: Daniel Kiper 
Acked-by: Jan Beulich 
---
v5 - suggestions/fixes:
   - improve commit message
 (suggested by Jan Beulich).

v4 - suggestions/fixes:
   - move to stdcall calling convention
 (suggested by Jan Beulich).

v3 - suggestions/fixes:
   - simplify assembly in xen/arch/x86/boot/reloc.c file
 (suggested by Jan Beulich),
   - reorder arguments for reloc() call from xen/arch/x86/boot/head.S
 (suggested by Jan Beulich),
   - improve commit message
 (suggested by Jan Beulich).
---
 xen/arch/x86/boot/head.S  |3 ++-
 xen/arch/x86/boot/reloc.c |   11 ++-
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index e34351c..7e5ae12 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -119,7 +119,8 @@ __start:
 
 /* Save the Multiboot info struct (after relocation) for later use. */
 mov $sym_phys(cpu0_stack)+1024,%esp
-push%ebx
+push%eax/* Boot trampoline address. */
+push%ebx/* Multiboot information address. */
 callreloc
 mov %eax,sym_phys(multiboot_ptr)
 
diff --git a/xen/arch/x86/boot/reloc.c b/xen/arch/x86/boot/reloc.c
index 9ae42e2..28c6cea 100644
--- a/xen/arch/x86/boot/reloc.c
+++ b/xen/arch/x86/boot/reloc.c
@@ -10,15 +10,16 @@
  *Keir Fraser 
  */
 
-/* entered with %eax = BOOT_TRAMPOLINE */
+/*
+ * This entry point is entered from xen/arch/x86/boot/head.S with:
+ *   - 0x4(%esp) = MULTIBOOT_INFORMATION_ADDRESS,
+ *   - 0x8(%esp) = BOOT_TRAMPOLINE_ADDRESS.
+ */
 asm (
 ".text \n"
 ".globl _start \n"
 "_start:   \n"
-"push %eax \n"
-"push 0x8(%esp)\n"
-"call reloc\n"
-"ret  $0x4 \n"
+"jmp  reloc\n"
 );
 
 typedef unsigned int u32;
-- 
1.7.10.4


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

[Xen-devel] [PATCH v5 04/16] x86/boot/reloc: reduce assembly usage as much as possible

[Daniel Kiper]

..to increase code readability and ease its maintenance.

Signed-off-by: Daniel Kiper 
---
v5 - suggestions/fixes:
   - improve commit message
 (suggested by Jan Beulich).
---
 xen/arch/x86/boot/reloc.c |   52 ++---
 1 file changed, 25 insertions(+), 27 deletions(-)

diff --git a/xen/arch/x86/boot/reloc.c b/xen/arch/x86/boot/reloc.c
index 63045c0..9ae42e2 100644
--- a/xen/arch/x86/boot/reloc.c
+++ b/xen/arch/x86/boot/reloc.c
@@ -15,39 +15,33 @@ asm (
 ".text \n"
 ".globl _start \n"
 "_start:   \n"
-"call 1f   \n"
-"1:  pop  %ebx \n"
-"mov  %eax,alloc-1b(%ebx)  \n"
-"jmp  reloc\n"
-);
-
-/*
- * This is our data. Because the code must be relocatable, no BSS is
- * allowed. All data is accessed PC-relative with inline assembly.
- */
-asm (
-"alloc:\n"
-".long 0   \n"
+"push %eax \n"
+"push 0x8(%esp)\n"
+"call reloc\n"
+"ret  $0x4 \n"
 );
 
 typedef unsigned int u32;
 #include "../../../include/xen/multiboot.h"
 
+#define __stdcall  __attribute__((__stdcall__))
+
+#define ALIGN_UP(arg, align) \
+(((arg) + (align) - 1) & ~((typeof(arg))(align) - 1))
+
+static u32 alloc;
+
 static void *reloc_mbi_struct(void *old, unsigned int bytes)
 {
 void *new;
-asm(
-"call 1f  \n"
-"1:  pop  %%edx   \n"
-"mov  alloc-1b(%%edx),%0  \n"
-"sub  %1,%0   \n"
-"and  $~15,%0 \n"
-"mov  %0,alloc-1b(%%edx)  \n"
-"mov  %0,%%edi\n"
-"rep  movsb   \n"
-   : "=" (new), "+c" (bytes), "+S" (old)
-   : : "edx", "edi", "memory");
-return new;
+
+alloc -= ALIGN_UP(bytes, 16);
+new = (void *)alloc;
+
+while ( bytes-- )
+*(char *)new++ = *(char *)old++;
+
+return (void *)alloc;
 }
 
 static char *reloc_mbi_string(char *old)
@@ -58,11 +52,15 @@ static char *reloc_mbi_string(char *old)
 return reloc_mbi_struct(old, p - old + 1);
 }
 
-multiboot_info_t *reloc(multiboot_info_t *mbi_old)
+multiboot_info_t __stdcall *reloc(multiboot_info_t *mbi_old, u32 trampoline)
 {
-multiboot_info_t *mbi = reloc_mbi_struct(mbi_old, sizeof(*mbi));
+multiboot_info_t *mbi;
 int i;
 
+alloc = trampoline;
+
+mbi = reloc_mbi_struct(mbi_old, sizeof(*mbi));
+
 if ( mbi->flags & MBI_CMDLINE )
 mbi->cmdline = (u32)reloc_mbi_string((char *)mbi->cmdline);
 
-- 
1.7.10.4


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

[Xen-devel] [PATCH v5 02/16] x86/boot: remove multiboot1_header_end from symbol table

[Daniel Kiper]

Its visibility is not needed and just pollute symbol table.

Suggested-by: Jan Beulich 
Signed-off-by: Daniel Kiper 
---
 xen/arch/x86/boot/head.S |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 85770e8..e34351c 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -32,7 +32,7 @@ multiboot1_header_start:   /*** MULTIBOOT1 HEADER /
 .long   MULTIBOOT_HEADER_FLAGS
 /* Checksum: must be the negated sum of the first two fields. */
 .long   -(MULTIBOOT_HEADER_MAGIC + MULTIBOOT_HEADER_FLAGS)
-multiboot1_header_end:
+.Lmultiboot1_header_end:
 
 .section .init.rodata, "a", @progbits
 .align 4
-- 
1.7.10.4


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

[Xen-devel] [PATCH v5 01/16] x86: allow EFI reboot method neither on EFI platforms...

[Daniel Kiper]

..nor EFI platforms with runtime services enabled.

Suggested-by: Jan Beulich 
Signed-off-by: Daniel Kiper 
---
v5 - suggestions/fixes:
   - fix build error
 (suggested by Jan Beulich),
   - improve commit message.
---
 xen/arch/x86/shutdown.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/xen/arch/x86/shutdown.c b/xen/arch/x86/shutdown.c
index 0e1499d..972e20b 100644
--- a/xen/arch/x86/shutdown.c
+++ b/xen/arch/x86/shutdown.c
@@ -80,6 +80,9 @@ static void __init set_reboot_type(char *str)
 break;
 str++;
 }
+
+if ( reboot_type == BOOT_EFI && !efi_enabled )
+reboot_type = BOOT_INVALID;
 }
 custom_param("reboot", set_reboot_type);
 
-- 
1.7.10.4


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

[Xen-devel] [PATCH v5 00/16] x86: multiboot2 protocol support

[Daniel Kiper]

Hi,

I am sending fifth version of multiboot2 protocol support for
legacy BIOS and EFI platforms. This patch series release contains
fixes for all known issues (many of them were found by Jan Beulich;
thanks a lot!).

The final goal is xen.efi binary file which could be loaded by EFI
loader, multiboot (v1) protocol (only on legacy BIOS platforms) and
multiboot2 protocol. This way we will have:
  - smaller Xen code base,
  - one code base for xen.gz and xen.efi,
  - one build method for xen.gz and xen.efi;
xen.efi will be extracted from xen(-syms)
file using objcopy or special custom tool,
  - xen.efi build will not so strongly depend
on a given GCC and binutils version.

Here is short list of changes since v4:
  - changed patches: 01, 03, 04, 05, 09, 10, 11.

Patches 12-16 were reviewed by nobody last time.

This patch series was build with following tools:
  - gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
and binutils 2.17-3+etch1,
  - gcc version 4.4.7 20120313 (Red Hat 4.4.7-11) (GCC)
and binutils 2.23.2-2.el6,
  - gcc version 4.7.2 (Debian 4.7.2-5)
and binutils 2.22-8,
  - gcc version 5.1.1 20150618 (Red Hat 5.1.1-4) (GCC)
and binutils 2.25-9.fc22.

I hope that features provided by this patch series will be included
in Xen 4.8 release in one way or another.

If you are not interested in this patch series at all please
drop me a line and I will remove you from distribution list.

Daniel

PS FYI, I will be on vacation next week. It will be nice if
   you review my patches during that time.

 .gitignore|5 +-
 xen/arch/x86/Makefile |8 +-
 xen/arch/x86/Rules.mk |4 +
 xen/arch/x86/boot/Makefile|   10 +-
 xen/arch/x86/boot/build32.lds |   52 
 xen/arch/x86/boot/build32.mk  |   18 ++-
 xen/arch/x86/boot/cmdline.S   |  367 
-
 xen/arch/x86/boot/cmdline.c   |  376 
++
 xen/arch/x86/boot/edd.S   |3 -
 xen/arch/x86/boot/head.S  |  568 
+-
 xen/arch/x86/boot/reloc.c |  249 
 xen/arch/x86/boot/trampoline.S|   22 +++-
 xen/arch/x86/boot/video.S |7 -
 xen/arch/x86/boot/wakeup.S|4 +-
 xen/arch/x86/boot/x86_64.S|   51 +++-
 xen/arch/x86/dmi_scan.c   |4 +-
 xen/arch/x86/domain_page.c|2 +-
 xen/arch/x86/efi/Makefile |   11 +-
 xen/arch/x86/efi/efi-boot.h   |  108 ++--
 xen/arch/x86/efi/stub.c   |   33 -
 xen/arch/x86/mpparse.c|4 +-
 xen/arch/x86/setup.c  |   48 +++
 xen/arch/x86/shutdown.c   |5 +-
 xen/arch/x86/time.c   |2 +-
 xen/arch/x86/x86_64/asm-offsets.c |   12 ++
 xen/arch/x86/xen.lds.S|   16 ++-
 xen/common/efi/boot.c |   31 -
 xen/common/efi/runtime.c  |   21 ++-
 xen/drivers/acpi/osl.c|2 +-
 xen/include/asm-x86/config.h  |1 +
 xen/include/asm-x86/page.h|2 +-
 xen/include/xen/efi.h |   10 +-
 xen/include/xen/multiboot2.h  |  182 ++
 33 files changed, 1624 insertions(+), 614 deletions(-)

Daniel Kiper (16):
  x86: allow EFI reboot method neither on EFI platforms...
  x86/boot: remove multiboot1_header_end from symbol table
  x86/boot: create *.lnk files with linker script
  x86/boot/reloc: reduce assembly usage as much as possible
  x86/boot: call reloc() using stdcall calling convention
  x86/boot/reloc: create generic alloc and copy functions
  x86/boot: use %ecx instead of %eax
  x86/boot/reloc: rename some variables and rearrange code a bit
  x86: add multiboot2 protocol support
  efi: create efi_enabled()
  efi: build xen.gz with EFI code
  x86/efi: create new early memory allocator
  x86: add multiboot2 protocol support for EFI platforms
  x86/boot: implement early command line parser in C
  x86: make Xen early boot code relocatable
  x86: add multiboot2 protocol support for relocatable images


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

[Xen-devel] [PATCH v5 03/16] x86/boot: create *.lnk files with linker script

[Daniel Kiper]

Newer GCC (e.g. gcc version 5.1.1 20150618 (Red Hat 5.1.1-4) (GCC)) does
some code optimizations by creating data sections (e.g. jump addresses
for C switch/case are calculated using data in .rodata section). This
thing is not accepted by *.lnk build recipe which requires that only .text
section lives in output. Potentially we can inhibit this GCC behavior by
using special options, e.g. -fno-tree-switch-conversion. However, this
does not guarantee that in the future new similar optimizations or anything
else which creates not accepted sections will not break our build recipes
again. I do not mention that probably this is not good idea to just disable
random optimizations. So, take over full control on *.lnk linking process
by using linker script and merge all text and data sections into one
.text section.

Additionally, remove .got.plt section which is not used in our final code.

Signed-off-by: Daniel Kiper 
---
v5 - suggestions/fixes:
   - merge __ALL__ text and data sections into one .text section
 (suggested by Jan Beulich),
   - check that .got.plt size is correct
 (suggested by Jan Beulich),
   - reformat comments
 (suggested by Jan Beulich),
   - improve commit message.

v4 - suggestions/fixes:
   - remove my name from copyright (Oracle requirement)
 (suggested by Konrad Rzeszutek Wilk),
   - improve comments,
 (suggested by Jan Beulich),
   - improve commit message
 (suggested by Jan Beulich).
---
 xen/arch/x86/boot/build32.lds |   52 +
 xen/arch/x86/boot/build32.mk  |   16 +++--
 2 files changed, 61 insertions(+), 7 deletions(-)
 create mode 100644 xen/arch/x86/boot/build32.lds

diff --git a/xen/arch/x86/boot/build32.lds b/xen/arch/x86/boot/build32.lds
new file mode 100644
index 000..da35aee
--- /dev/null
+++ b/xen/arch/x86/boot/build32.lds
@@ -0,0 +1,52 @@
+/*
+ * Copyright (c) 2016 Oracle and/or its affiliates. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program.  If not, see .
+ */
+
+ENTRY(_start)
+
+SECTIONS
+{
+  /* Merge code and data into one section. */
+  .text : {
+*(.text)
+*(.text.*)
+*(.data)
+*(.data.*)
+*(.rodata)
+*(.rodata.*)
+*(.bss)
+*(.bss.*)
+  }
+
+  /DISCARD/ : {
+/*
+ * PIC/PIE executable contains .got.plt section even if it is not 
linked
+ * with dynamic libraries. In such case it is just placeholder for
+ * _GLOBAL_OFFSET_TABLE_ symbol and .PLT0. .PLT0 is filled by dynamic
+ * linker and our code is not supposed to be loaded by dynamic linker.
+ * So, from our point of view .PLT0 is unused. This means that there is
+ * pretty good chance that we can safely drop .got.plt as a whole here.
+ * Sadly this is not true. _GLOBAL_OFFSET_TABLE_ is used as a reference
+ * for relative addressing (and only for that thing) and ld complains 
if
+ * we remove .got.plt section here because it cannot find required 
symbol.
+ * However, _GLOBAL_OFFSET_TABLE_ is no longer needed in final output.
+ * So, drop .got.plt section during conversion to plain binary format.
+ *
+ * Please check build32.mk for more details.
+ */
+/* *(.got.plt) */
+  }
+}
diff --git a/xen/arch/x86/boot/build32.mk b/xen/arch/x86/boot/build32.mk
index 4a7d388..39e6453 100644
--- a/xen/arch/x86/boot/build32.mk
+++ b/xen/arch/x86/boot/build32.mk
@@ -12,20 +12,22 @@ CFLAGS := $(filter-out -flto,$(CFLAGS))
(od -v -t x $< | tr -s ' ' | awk 'NR > 1 {print s} {s=$$0}' | \
sed 's/ /,0x/g' | sed 's/,0x$$//' | sed 's/^[0-9]*,/ .long /') >$@
 
+# Drop .got.plt during conversion to plain binary format.
+# Please check build32.lds for more details.
 %.bin: %.lnk
-   $(OBJCOPY) -O binary $< $@
-
-%.lnk: %.o
-   $(OBJDUMP) -h $< | sed -n '/[0-9]/{s,00*,0,g;p;}' |\
+   $(OBJDUMP) -h $< | sed -n '/[0-9]/{s,00*,0,g;p;}' | \
while read idx name sz rest; do \
case "$$name" in \
-   .data|.data.*|.rodata|.rodata.*|.bss|.bss.*) \
-   test $$sz != 0 || continue; \
+   .got.plt) \
+   test $$sz != 0c || continue; \
echo "Error: non-empty $$name: 0x$$sz" 

Re: [Xen-devel] [PATCH v1 7/7] tools: add userspace linker table sandbox

[Kees Cook]

On Fri, Aug 19, 2016 at 2:41 PM,   wrote:
> From: "Luis R. Rodriguez" 
>
> Add a userspace sandbox to allow easy experimentation and
> test extensions with linker tables, section ranges and the
> new section core definitions.
>
> The userspace sandbox tries to mimic the Linux kernel development
> flow as much as possible, it however relies on and uses libc. Support
> is currently only provided to x86_64.
>
> v4: this patch is new in this series -- added to the kenrel as
> suggested by Boris, as otherwise it'd be really hard to keep
> an external userspace repository in sync.
>
> Signed-off-by: Luis R. Rodriguez 
> ---
>  Documentation/sections/linker-tables.rst   |   4 +-
>  MAINTAINERS|   1 +
>  include/linux/tables.h |   5 +-
>  tools/Makefile |   3 +-
>  .../arch/x86/include/generated/asm/section-core.h  |   1 +
>  tools/arch/x86/include/generated/ranges.h  |   1 +
>  tools/arch/x86/include/generated/tables.h  |   1 +
>  tools/include/asm-generic/ranges.h | 103 
>  tools/include/asm-generic/section-core.h   | 341 +++
>  tools/include/asm-generic/tables.h |  50 ++

Aren't a bunch of these files exact duplicates of the headers in include/linux?

-Kees

-- 
Kees Cook
Nexus Security

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

Re: [Xen-devel] [PATCH v4 00/16] linux: generalize sections, ranges and linker tables

[Kees Cook]

On Fri, Aug 19, 2016 at 2:32 PM,  <mcg...@kernel.org> wrote:
> From: "Luis R. Rodriguez" <mcg...@kernel.org>
>
> This v4 addresses feedback from the previous v3 series [0], and also
> addresses a huge array of additional tests against many architectures
> outside of what 0-day provides. As I mentioned in my last v3 series,
> 0-day had only found one issue with the series, a blackfin architecture
> linker issue with the last series. Guenter Rock was kind enough to give
> my series a test spin on his test bed and he found quite a bit of other
> oddball issues with obscure architectures, and even on x86 with an old
> toolchain. After a lot of work and coordinating with a few maintainers
> I'm happy to report all issues found so far through all possible testing
> I could do are now fixed, this series also addresses all feedback from
> the last series, as such this goes submitted as PATCH form.
>
> In addressing fixing this work on a few architectures some of the previous
> patches are further simplified. The kprobes port to linker tables is made
> much easier now that I've addressed moving out core kprobe declarations
> into asm-generic/kprobes.h. Refer to the patch "kprobes: move kprobe
> declarations to asm-generic/kprobes.h". This makes for a much cleaner
> solution across architectures.
>
> Boris feedback on making the code bit rot feature optional is addressed
> by using a new Kconfig symbol for this, CONFIG_BUILD_AVOID_BITROT,
> but given Greg's concerns over lack of clarity over what this was all about
> I've ripped that functionality out into its own patch with a bit more
> extensive documentation and re-wording. See the patch "kbuild: enable option
> to force compile force-obj-y and force-lib-y". I hope makes it clear how
> linker tables can help with avoiding code bit rot. I've gone with a new
> Kconfig symbol CONFIG_BUILD_AVOID_BITROT given CONFIG_COMPILE_TEST is
> not available on UML, this feature is desirable on all architectures.
>
> The documentation is revamped, now that the DocBook format is deprecated
> I ported the documention into the trendy hipster Sphinx documentation
> format.
>
> AT Boris' request I've adapated the userspace linker table application
> forintegration into the kernel under tools/ to make it easier to keep
> things in sync, however since this requires a bit of changes to some headers
> in tools/ I'll submit that separately.
>
> [0] 
> https://lkml.kernel.org/r/1469222687-1600-1-git-send-email-mcg...@kernel.org
>
> If you'd like this in git-form, you can get it on the 20160819-linker-table-v4
> branch of my linux-next tree on kernel.org, this also includes the series of
> the linker table userspace sandbox:
>
> https://git.kernel.org/cgit/linux/kernel/git/mcgrof/linux-next.git/log/?h=20160819-linker-table-v4
>
> Please let me know if there are any concerns or questions.

Thanks for the documentation and examples on this feature; I appreciate it! :)

While it seems like all the section declarations work in this series
is designed for assembler source, I'm curious if I've missed a way to
do this in .c source too. I'd love to avoid doing the crazy thing I'm
currently doing in lkdtm with section markings. Namely, I want to
write a function in .c and have it moved into the .rodata section. The
linkers get very very angry with me and I don't seem to be able to
override the progbits to lose "x". Right now I'm doing an objcopy in
drivers/misc/Makefile:

OBJCOPYFLAGS_lkdtm_rodata_objcopy.o := \
--set-section-flags .text=alloc,readonly \
--rename-section .text=.rodata
targets += lkdtm_rodata.o lkdtm_rodata_objcopy.o
$(obj)/lkdtm_rodata_objcopy.o: $(obj)/lkdtm_rodata.o FORCE
$(call if_changed,objcopy)

Thanks!

-Kees

>
> Luis R. Rodriguez (16):
>   x86: remove LTO_REFERENCE_INITCALL()
>   dell-smo8800: include uaccess.h
>   scripts/module-common.lds: enable generation
>   generic-sections: add section core helpers
>   xtensa: skip adding literal when SORT() is used
>   ranges.h: add helpers to build and identify Linux section ranges
>   tables.h: add linker table support
>   kbuild: enable option to force compile force-obj-y and force-lib-y
>   firmware/Makefile: force recompilation if makefile changes
>   firmware: port built-in section to linker table
>   jump_label: move guard #endif down where it belongs
>   jump_label: port __jump_table to linker tables
>   dynamic_debug: port to use linker tables
>   kprobes: move kprobe declarations to asm-generic/kprobes.h
>   kprobes: port .kprobes.text to section range
>   kprobes: port blacklist kprobes to linker table
>
>  .gitignore |   2 +
>  Documentation/index.rst 

Re: [Xen-devel] [PATCH v4 08/16] kbuild: enable option to force compile force-obj-y and force-lib-y

[Kees Cook]

On Fri, Aug 19, 2016 at 2:32 PM,   wrote:
> From: "Luis R. Rodriguez" 
>
> Linux provides a rich array of features, enabling each feature
> however increases the size of the kernel and there are many
> features which users often want disabled. The traditional
> solution to this problem is for each feature to have its own
> Kconfig symbol, followed by a series of #ifdef statements
> in C code and header files, allowing the feature to be compiled
> only when desirable. As the variability of Linux increases build
> tests can and are often done with random kernel configurations,
> allyesconfig, and allmodconfig to help find code issues. This
> however doesn't catch all errors and as a consequence code that
> is typically not enabled often can suffer from bit-rot over time.
>
> An alternative approach for subsystems, which refer to as the 'build-all
> link-selectively philosophy' is to keep the Kconfig symbols, replace
> the #ifdef approach by having each feature implemented it its own C file,
> and force compilation for all features to avoid the code bit-rot problem.
> With this strategy only features that are enabled via Kconfig get
> linked into the kernel, so the forced compilation has no size impact
> on the kernel. The practice of having each feature implemented in its own
> C file is already prevalent in many subsystems, however #ifdefs are still
> typically required during feature initialization. For instance in:
>
>   #ifdef CONFIG_FOO
>   foo_init();
>   #endif
>
> We cannot remove the #ifdef and leave foo_init() as we'd either
> need to always enable the feature or add a respective #ifdef in a
> foo.h which makes foo_init() do nothing when CONFIG_FOO is disabled.
>
> Linker tables enable lifting the requirement to use of #ifdefs during
> initialization. With linker tables initialization sequences can instead
> be aggregated into a custom ELF section at link time, during run time
> the table can be iterated over and each init sequence enabled can be called.
> A feature's init routine is only added to a table when its respective
> Kconfig symbols has been enabled and therefore linked in. Linker tables
> enable subsystems to completely do away with #ifdefs if one is comfortable
> in accepting all subsystem's feature's structural size implications.
>
> Subsystems which want to follow the 'build-all link-selectively
> philosophy' still need a way to easily express and annotate that they
> wish for all code to always be compiled to help avoid code bit rot,
> as such two new targets force-obj-y and force-lib-y are provided to
> help with this. Its not fair to require everyone to force compilation
> of all features of a subsystem though, so as a compromise, the new
> targets only force compilation when CONFIG_BUILD_AVOID_BITROT is
> enabled.
>
> Only built-in features are supported at the moment. Module support
> is expected to be added after a generic solution to add linker
> tables to modules more easily is developed.
>
> v4: this patch was added to this series, it was split off from the
> linker tables addition due to the confusion over the code bit
> rot alternatives that are possible with linker tables.
>
> Signed-off-by: Luis R. Rodriguez 
> ---
>  Documentation/kbuild/makefiles.txt   | 36 
>  Documentation/sections/linker-tables.rst | 15 +++
>  include/linux/tables.h   | 71 
> 
>  init/Kconfig | 22 ++
>  scripts/Makefile.build   |  7 ++--
>  scripts/Makefile.lib | 11 +
>  6 files changed, 159 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/kbuild/makefiles.txt 
> b/Documentation/kbuild/makefiles.txt
> index 385a5ef41c17..01c260913f5c 100644
> --- a/Documentation/kbuild/makefiles.txt
> +++ b/Documentation/kbuild/makefiles.txt
> @@ -1089,6 +1089,42 @@ When kbuild executes, the following steps are followed 
> (roughly):
> In this example, extra-y is used to list object files that
> shall be built, but shall not be linked as part of built-in.o.
>
> +force-obj-y force-lib-y
> +
> +   When CONFIG_BUILD_AVOID_BITROT is enabled using these targets for your
> +   kconfig symbols forces compilation of the associated objects if the
> +   kconfig's symbol's dependencies are met, the objects however are only
> +   linked into to the kernel if and only if the kconfig symbol was
> +   enabled. If CONFIG_BUILD_AVOID_BITROT is disabled the force-obj-y and
> +   force-lib-y targets are functionally equilvalent to obj-y and lib-y
> +   respectively.
> +
> +   Using force-obj-y and force-lib-y are part of a code architecture and
> +   build philosophy further enabled by linker tables, for more details
> +   refer to the documention in include/linux/tables.h, refer to the
> +   sections:
> +
> +   o The code bit-rot problem

Re: [Xen-devel] [PATCH v4 07/16] tables.h: add linker table support

[Kees Cook]

On Fri, Aug 19, 2016 at 2:32 PM,   wrote:
> From: "Luis R. Rodriguez" 
>
> A linker table is a data structure that is stitched together from items
> in multiple object files. Linux has historically implicitly used linker
> tables for ages, however they were all built in an adhoc manner which
> requires linker script modifications, per architecture. This adds a
> general linker table solution so that a new linker table can be
> implemented by changing C code only. The Linux linker table was
> inspired by Michael Brown's iPXE's linker table solution, it has been
> been completely re-written and adapted for integration and use on Linux.
>
> The same philosophy is borrowed, extended and further simplified:
>
> Linker tables enable an extremely light weight linker build time
> solution for feature ordering and selection, this can help to both
> simplify init sequences in a generic fashion and helps avoiding code
> bit-rotting when desirable. Further changes will be added later
> which will make more evident how code bit rot can be avoided using
> linker tables.
>
> v4:
>
> o Split out kbuild additions to help with code bit rot into
>   its own patch
> o tons of documentation love
> o fix arch/x86/tools/relocs.c typo - which caused compilation issues
>   on old toolchains
> o add c6x toolchain work around as discussed with Mark Salter
> o sprinkle a few more needed VMLINUX_SYMBOL() - fixes
>   compilation on blackfin
> o suggested name changes by boris:
> - %s/SECTION_TYPE_RANGES/rng/g
> - %s/SECTION_TYPE/SECTION_CORE/g
> - %s/section_type_asmtype/section_core_type/g
> - %s/section_type/section_core/g
> - %s/section_rng/set_section_rng/g
> - Drop DECLARE_SECTION_TBL() -- this is an asm equivalent
>   DEFINE_LINKTABLE() -- this however is not used yet, and it requires
>   a bit more work to match the C code definitions.
> o drop tools/include/linux/sections.h in favor of the more popular open
>   coding the names for tools
> o expand documentation to include module support
> o add maintaners
> o Use generic-y
> o move .text.tbl before unlikely to match the other sections
>
> v3:
>
> o addressed initial modular support test cases
> o added generic asm macros so linker tables can be used in
>   asm code / C asm calls
> o section ranges are now split up into their own set of files
> o use asm/sections.h instead of linux/sections.h for the linker
>   script
> o add a sections.h file for each architecture that was missing one,
>   this is needed now as we'll be relying on sections.h for custom
>   section types in code rather than custom architecture specific
>   linker script hacks.
> o full rewrite at this point, decided to pick copyleft-next license
>   for this work
>
> v2:
>
> o modified completely to match feedback by community, made equivalent
>   modifications to userspace solution. This is pretty much a complete
>   rewrite of how we present and use linker tables. By using standard
>   sections we no longer have to make custom linker script extensions
>   for each new linker table solution, you just pick a linker table
>   type by section type.
> o extend documention considerably, including use of kdoc
> o drop ICC hacks per popular request to ignore such issues for now
> o use sections.h - this lets us streamline a clean use case of
>   well documented sections. To help further with this make use of
>   SECTION_TBL() to allow use of these in code and SECTION_TBL_ALL()
>   on linker scripts, as well as SECTION_TBL_ALL_STR() on relocs.c
>   when needed.
>
> Cc: Michael Brown 
> Signed-off-by: Luis R. Rodriguez 
> ---
>  Documentation/sections/index.rst |   1 +
>  Documentation/sections/linker-tables.rst | 187 ++
>  MAINTAINERS  |  12 +
>  arch/alpha/include/asm/Kbuild|   1 +
>  arch/arc/include/asm/Kbuild  |   1 +
>  arch/arm/include/asm/Kbuild  |   1 +
>  arch/arm64/include/asm/Kbuild|   1 +
>  arch/avr32/include/asm/Kbuild|   1 +
>  arch/blackfin/include/asm/Kbuild |   1 +
>  arch/c6x/include/asm/tables.h|  26 ++
>  arch/cris/include/asm/Kbuild |   1 +
>  arch/frv/include/asm/Kbuild  |   1 +
>  arch/h8300/include/asm/Kbuild|   1 +
>  arch/hexagon/include/asm/Kbuild  |   1 +
>  arch/ia64/include/asm/Kbuild |   1 +
>  arch/m32r/include/asm/Kbuild |   1 +
>  arch/m68k/include/asm/Kbuild |   1 +
>  arch/metag/include/asm/Kbuild|   1 +
>  arch/microblaze/include/asm/Kbuild   |   1 +
>  arch/mips/include/asm/Kbuild |   1 +
>  arch/mn10300/include/asm/Kbuild  |   1 +
>  arch/nios2/include/asm/Kbuild|   1 +
>  arch/openrisc/include/asm/Kbuild |   1 +
>  arch/parisc/include/asm/Kbuild   |   1 +
>  arch/powerpc/include/asm/Kbuild  |   1 +
>  arch/s390/include/asm/Kbuild  

Re: [Xen-devel] [PATCH v4 06/16] ranges.h: add helpers to build and identify Linux section ranges

[Kees Cook]

On Fri, Aug 19, 2016 at 2:32 PM,   wrote:
> From: "Luis R. Rodriguez" 
>
> Section ranges are on one of the types of custom sections
> types used in Linux. This provides a series of helpers for
> defining them and using them. Most importantly this also
> enables us to avoid modifying the linker script when we
> add a new section range.
>
> It turns out a lot of custom sections are actually section ranges,
> and these are typically spelled out in their architecture specific
> asm/sections.h file -- we anable architectures to override what asm

Typo: anable -> enable

> is used for section ranges but start by default trusting the
> asm-generic version all around.

Can you explain the addition of the SORT() stuff in this patch? Its
purpose isn't clear to me and doesn't appear to be mentioned in the
commit log.

>
> v4:
>
> o tons of documentation love
> o fix arch/x86/tools/relocs.c typo - which caused compilation issues
>   on old toolchains
> o port to new shiny sphinx documentation
> o sprinkle a few more needed VMLINUX_SYMBOL() - fixes
>   compilation on blackfin
> o name changes as suggested by Boris:
> - %s/SECTION_TYPE_RANGES/rng/g
> - %s/SECTION_TYPE/SECTION_CORE/g
> - %s/section_type_asmtype/section_core_type/g
> - %s/section_type/section_core/g
> - %s/section_rng/set_section_rng/g
> - rebrand DECLARE_SECTION_RNG() as DEFINE_SECTION_RANGE() - this is
>   the asm version of the respective C version, this will have a
>   userspace C demo added later.
> o move __LINUX_RANGE() and __LINUX_RANGE_ORDER() - fixes builds
>   on sparc
> o adds section ranges to linker script
> o rename SECTION_RANGE_ALL()
> o use default alignment, fixes builds on powerpc and arm for both
>   __LINUX_RANGE() and __LINUX_RANGE_ORDER()
> o expand documentation to document modules support
> o add maintainers
> o use generic-y
>
> v3: new in this series, uses copyleft-next
>
> Signed-off-by: Luis R. Rodriguez 
> ---
>  Documentation/sections/index.rst   |   1 +
>  Documentation/sections/ranges.rst  |  49 ++
>  MAINTAINERS|  10 +++
>  arch/alpha/include/asm/Kbuild  |   1 +
>  arch/arc/include/asm/Kbuild|   1 +
>  arch/arm/include/asm/Kbuild|   1 +
>  arch/arm64/include/asm/Kbuild  |   1 +
>  arch/avr32/include/asm/Kbuild  |   1 +
>  arch/blackfin/include/asm/Kbuild   |   1 +
>  arch/c6x/include/asm/Kbuild|   1 +
>  arch/cris/include/asm/Kbuild   |   1 +
>  arch/frv/include/asm/Kbuild|   1 +
>  arch/h8300/include/asm/Kbuild  |   1 +
>  arch/hexagon/include/asm/Kbuild|   1 +
>  arch/ia64/include/asm/Kbuild   |   1 +
>  arch/m32r/include/asm/Kbuild   |   1 +
>  arch/m68k/include/asm/Kbuild   |   1 +
>  arch/metag/include/asm/Kbuild  |   1 +
>  arch/microblaze/include/asm/Kbuild |   1 +
>  arch/mips/include/asm/Kbuild   |   1 +
>  arch/mn10300/include/asm/Kbuild|   1 +
>  arch/nios2/include/asm/Kbuild  |   1 +
>  arch/openrisc/include/asm/Kbuild   |   1 +
>  arch/parisc/include/asm/Kbuild |   1 +
>  arch/powerpc/include/asm/Kbuild|   1 +
>  arch/s390/include/asm/Kbuild   |   1 +
>  arch/score/include/asm/Kbuild  |   1 +
>  arch/sh/include/asm/Kbuild |   1 +
>  arch/sparc/include/asm/Kbuild  |   1 +
>  arch/tile/include/asm/Kbuild   |   1 +
>  arch/um/include/asm/Kbuild |   1 +
>  arch/unicore32/include/asm/Kbuild  |   1 +
>  arch/x86/include/asm/Kbuild|   1 +
>  arch/x86/tools/relocs.c|   2 +
>  arch/xtensa/include/asm/Kbuild |   1 +
>  include/asm-generic/ranges.h   |  89 ++
>  include/asm-generic/vmlinux.lds.h  |  12 +++-
>  include/linux/ranges.h | 128 
> +
>  38 files changed, 320 insertions(+), 2 deletions(-)
>  create mode 100644 Documentation/sections/ranges.rst
>  create mode 100644 include/asm-generic/ranges.h
>  create mode 100644 include/linux/ranges.h
>
> diff --git a/Documentation/sections/index.rst 
> b/Documentation/sections/index.rst
> index d411e9b22eb3..6dd93ddd5dbe 100644
> --- a/Documentation/sections/index.rst
> +++ b/Documentation/sections/index.rst
> @@ -9,3 +9,4 @@ used throughout the kernel to help declare and define them.
> :maxdepth: 4
>
> section-core
> +   ranges
> diff --git a/Documentation/sections/ranges.rst 
> b/Documentation/sections/ranges.rst
> new file mode 100644
> index ..1293dcb3ab38
> --- /dev/null
> +++ b/Documentation/sections/ranges.rst
> @@ -0,0 +1,49 @@
> +
> +Linux section ranges
> +
> +
> +This documents Linux' use of section ranges, how you can use
> +them and how they work.
> +
> +About section ranges
> +
> +
> +Introduction
> +
> +.. kernel-doc:: include/linux/ranges.h
> +   :doc: Introduction
> +
> +Section range module support
> +
> +.. kernel-doc:: 

Re: [Xen-devel] [PATCH v4 04/16] generic-sections: add section core helpers

[Kees Cook]

On Fri, Aug 19, 2016 at 2:32 PM,   wrote:
> From: "Luis R. Rodriguez" 
>
> Linux makes extensive use of custom ELF header sections,
> documentation for these are well scatterred. Unify this
> documentation in a central place and provide helpers to
> build custom Linux sections.
>
> This also generalizes sections code to enable avoiding
> modifying the linker scripts when we want to add new
> custom Linux sections. In order to make this generally
> useful we need to ensure all architectures can make use of
> core section helpers but that they can also override should
> this be needed. Instead of relying on section.h this adds
> a sections-core.h since this will be targetted to be safe
> to be used on asm code, linker scripts and C code.
>
> v4:
>
> o Port to shiny new sphinx documentation format
>
> o fix a unicore32 build, turns out this actually fixes unicore32
>   defconfig builds which were failing for a long while. unicore32
>   does not seem to grok well the type passed on a section declaration,
>   this ignores it.
>
> o Use VMLINUX_SYMBOL() in more user symbols (extern C code), not doing
>   this was causing final linker issues with blackfin -- this is
>   a CONFIG_HAVE_UNDERSCORE_SYMBOL_PREFIX=y architecture. The other one
>   being metatag. metatag is not supported on 0-day so I cannot confirm
>   compilation there.
>
> o Added SECTION_CORE() for C code, used later by __LINUX_RANGE()
>
> o Since SECTION_CORE() is defined for linker script and C code, share
>   the same helper and just use a __stringify() for the C code as is done
>   for the other C helpers.
>
> o move generic sections to asm-generic/section-core.h instead.
>   PowerPC compilation blows up if asm/jump_labels.h gets
>   section.h included, fixing this is not in any way easy.
>   The list of issues are endless. Moving new data to a new
>   simple file resolves this.
>
> o since things are now in asm-generic/section-core.h the
>   guard changes on asm-generic/sections.h and each architecture
>   sections.h are no longer needed
>
> o Give generic sections some maintainer love, that change is
>   Acked-by Arnd Bergmann, Josh and hpa.
>
> o A few checkpatch.pl style fixes
>
> o As suggested by James Hogan use generic-y to copy generic
>   header files on architectures that do not have a sections.h
>   instead of writing a simple file only to include the generic one.
>
> v3:
>
> o add missing sections.h for architectures that did not
>   have it
>
> o move generic sections to asm-generic/sections.h
>
> o add generic asm helpers section_type(), section_type_asmtype(),
>   push_section_type() -- these helpers enable easy use for
>   for later declaring and using of custom linux sections using
>   more standard APIs in both C code, asm code (C asm calls, or
>   asm files), enabling future standardized section types to
>   be more immediately accessible to asm code, not just C code.
>   Note for ASM_CMD_SEP we use by default "\n", architectures needed
>   to override can do so on their own sections.h prior to inclusion
>   of asm-generic/sections.h
>
> Signed-off-by: Luis R. Rodriguez 
> ---
>  Documentation/index.rst   |   1 +
>  Documentation/sections/conf.py|   4 +
>  Documentation/sections/index.rst  |  11 +
>  Documentation/sections/section-core.rst   | 153 ++
>  MAINTAINERS   |  14 ++
>  arch/alpha/include/asm/Kbuild |   1 +
>  arch/arc/include/asm/Kbuild   |   1 +
>  arch/arm/include/asm/Kbuild   |   1 +
>  arch/arm64/include/asm/Kbuild |   1 +
>  arch/avr32/include/asm/Kbuild |   1 +
>  arch/blackfin/include/asm/Kbuild  |   1 +
>  arch/c6x/include/asm/Kbuild   |   1 +
>  arch/cris/include/asm/Kbuild  |   1 +
>  arch/frv/include/asm/Kbuild   |   1 +
>  arch/h8300/include/asm/Kbuild |   1 +
>  arch/hexagon/include/asm/Kbuild   |   1 +
>  arch/ia64/include/asm/Kbuild  |   1 +
>  arch/m32r/include/asm/Kbuild  |   1 +
>  arch/m68k/include/asm/Kbuild  |   1 +
>  arch/metag/include/asm/Kbuild |   1 +
>  arch/microblaze/include/asm/Kbuild|   1 +
>  arch/mips/include/asm/Kbuild  |   1 +
>  arch/mn10300/include/asm/Kbuild   |   1 +
>  arch/nios2/include/asm/Kbuild |   1 +
>  arch/openrisc/include/asm/Kbuild  |   1 +
>  arch/parisc/include/asm/Kbuild|   1 +
>  arch/powerpc/include/asm/Kbuild   |   1 +
>  arch/s390/include/asm/Kbuild  |   1 +
>  arch/score/include/asm/Kbuild |   1 +
>  arch/sh/include/asm/Kbuild|   1 +
>  arch/sparc/include/asm/Kbuild |   1 +
>  arch/tile/include/asm/Kbuild  |   1 +
>  arch/um/include/asm/Kbuild|   1 +
>  arch/unicore32/include/asm/section-core.h |  19 ++
>  

[Xen-devel] [PATCH v1 6/7] tools: add __section() to compiler.h

[mcgrof]

From: "Luis R. Rodriguez" 

This will be used later by the userspace linker table.

Signed-off-by: Luis R. Rodriguez 
---
 tools/include/linux/compiler.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/include/linux/compiler.h b/tools/include/linux/compiler.h
index 556c991de212..6321265df00a 100644
--- a/tools/include/linux/compiler.h
+++ b/tools/include/linux/compiler.h
@@ -132,4 +132,6 @@ static __always_inline void __write_once_size(volatile void 
*p, void *res, int s
 #define WRITE_ONCE(x, val) \
({ union { typeof(x) __val; char __c[1]; } __u = { .__val = (val) }; 
__write_once_size(&(x), __u.__c, sizeof(x)); __u.__val; })
 
+#define __section(S)   __attribute__ ((__section__(#S)))
+
 #endif /* _TOOLS_LINUX_COMPILER_H */
-- 
2.9.2


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

[Xen-devel] [PATCH v1 5/7] tools: expand export.h with VMLINUX_SYMBOL()

[mcgrof]

From: "Luis R. Rodriguez" 

This will be used later by the linker-table userspace sandbox.

Signed-off-by: Luis R. Rodriguez 
---
 tools/include/linux/export.h | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/tools/include/linux/export.h b/tools/include/linux/export.h
index d07e586b9ba0..cb7d6b490e08 100644
--- a/tools/include/linux/export.h
+++ b/tools/include/linux/export.h
@@ -1,6 +1,28 @@
 #ifndef _TOOLS_LINUX_EXPORT_H_
 #define _TOOLS_LINUX_EXPORT_H_
 
+/*
+ * Export symbols from the kernel to modules.  Forked from module.h
+ * to reduce the amount of pointless cruft we feed to gcc when only
+ * exporting a simple symbol or two.
+ *
+ * Try not to add #includes here.  It slows compilation and makes kernel
+ * hackers place grumpy comments in header files.
+ */
+
+/* Some toolchains use a `_' prefix for all user symbols. */
+#ifdef CONFIG_HAVE_UNDERSCORE_SYMBOL_PREFIX
+#define __VMLINUX_SYMBOL(x) _##x
+#define __VMLINUX_SYMBOL_STR(x) "_" #x
+#else
+#define __VMLINUX_SYMBOL(x) x
+#define __VMLINUX_SYMBOL_STR(x) #x
+#endif
+
+/* Indirect, so macros are expanded before pasting. */
+#define VMLINUX_SYMBOL(x) __VMLINUX_SYMBOL(x)
+#define VMLINUX_SYMBOL_STR(x) __VMLINUX_SYMBOL_STR(x)
+
 #define EXPORT_SYMBOL(sym)
 #define EXPORT_SYMBOL_GPL(sym)
 #define EXPORT_SYMBOL_GPL_FUTURE(sym)
-- 
2.9.2


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

[Xen-devel] [PATCH v1 3/7] tools: add init.h for tools

[mcgrof]

From: "Luis R. Rodriguez" 

Start off with just __ref -- we enalbe you to override, if you do
that then you can define your own. The way you'd use this, if you
do override, is define your own __ref and then use include_next.

Signed-off-by: Luis R. Rodriguez 
---
 tools/include/linux/init.h | 9 +
 1 file changed, 9 insertions(+)
 create mode 100644 tools/include/linux/init.h

diff --git a/tools/include/linux/init.h b/tools/include/linux/init.h
new file mode 100644
index ..6d970a360a05
--- /dev/null
+++ b/tools/include/linux/init.h
@@ -0,0 +1,9 @@
+#ifndef _TOOLS_LINUX_INIT_H
+#define _TOOLS_LINUX_INIT_H
+
+/* this means you can add your own to fit you own userspace needs */
+#ifndef __ref
+#define __ref
+#endif
+
+#endif /* _TOOLS_LINUX_INIT_H */
-- 
2.9.2


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

[Xen-devel] [PATCH v1 0/7] tools: add linker table userspace sandbox

[mcgrof]

From: "Luis R. Rodriguez" <mcg...@kernel.org>

The original v3 series for linker tables made reference only to
an external repository userspace sandbox application, however
Boris noted it'd be difficult ot keep this in sync with the
kernel so advised to consider integrate with the kernel. I've
taken steps in this direction.

A bit of prepping is done to help make use of the tools/include
and tools/arch/$(ARCH)/include/asm directories. For now the tool
only supports x86_64, however quite a bit of work was done to
help make it work with a cross compiler, and try to make as
architecture agnostic as possible. Adding suppor for another 
architecture should not require much work, mosty just generating
a userspace custom linker script, modifying it for linker tables,
section ranges, and finally testing this with its toolchain.

This is being submitted separately than the patches which adds
linker table support into the kernel. This should be considered
only if that gets merged.

If you'd like this in git-form, you can get it on the 20160819-linker-table-v4  
branch of my linux-next tree on kernel.org, this also includes the series of
that introduces linker tables into the kernel:

https://git.kernel.org/cgit/linux/kernel/git/mcgrof/linux-next.git/log/?h=20160819-linker-table-v4

Please let me know if there are any issue or questions.

Luis R. Rodriguez (7):
  tools: add a userspace tools bug.h
  tools: add a basic tools printk.h
  tools: add init.h for tools
  tools: add __used and enable to override
  tools: expand export.h with VMLINUX_SYMBOL()
  tools: add __section() to compiler.h
  tools: add userspace linker table sandbox

 Documentation/sections/linker-tables.rst   |   4 +-
 MAINTAINERS|   1 +
 include/linux/tables.h |   5 +-
 tools/Makefile |   3 +-
 .../arch/x86/include/generated/asm/section-core.h  |   1 +
 tools/arch/x86/include/generated/ranges.h  |   1 +
 tools/arch/x86/include/generated/tables.h  |   1 +
 tools/include/asm-generic/bug.h|  24 +
 tools/include/asm-generic/ranges.h | 103 
 tools/include/asm-generic/section-core.h   | 341 +++
 tools/include/asm-generic/tables.h |  50 ++
 tools/include/linux/bug.h  |   6 +
 tools/include/linux/compiler.h |   8 +
 tools/include/linux/export.h   |  22 +
 tools/include/linux/init.h |   9 +
 tools/include/linux/kernel.h   |   3 +
 tools/include/linux/printk.h   |  14 +
 tools/include/linux/ranges.h   | 128 
 tools/include/linux/sections.h | 111 
 tools/include/linux/string.h   |   1 +
 tools/include/linux/tables.h   | 664 +
 tools/linker-tables/.gitignore |   2 +
 tools/linker-tables/Makefile   | 184 ++
 tools/linker-tables/README | 114 
 tools/linker-tables/arch/x86/include/asm/asm.h |  17 +
 tools/linker-tables/arch/x86/include/asm/boot.h|   1 +
 .../linker-tables/arch/x86/include/asm/bootparam.h |  32 +
 tools/linker-tables/arch/x86/include/asm/kprobes.h |   7 +
 .../linker-tables/arch/x86/include/asm/ps_const.h  |  21 +
 tools/linker-tables/arch/x86/include/asm/ranges.h  |   6 +
 .../arch/x86/include/asm/section-core.h|   1 +
 tools/linker-tables/arch/x86/include/asm/setup.h   |   6 +
 tools/linker-tables/arch/x86/include/asm/tables.h  |   6 +
 tools/linker-tables/arch/x86/include/asm/x86.h |   4 +
 .../arch/x86/include/asm/x86_init_fn.h | 169 ++
 tools/linker-tables/arch/x86/kernel/alpha.c|   9 +
 tools/linker-tables/arch/x86/kernel/alternative.c  |  31 +
 tools/linker-tables/arch/x86/kernel/beta.c |   9 +
 tools/linker-tables/arch/x86/kernel/head64.c   |  58 ++
 tools/linker-tables/arch/x86/kernel/init.c |  42 ++
 tools/linker-tables/arch/x86/kernel/kasan.c|  10 +
 tools/linker-tables/arch/x86/kernel/kprobes.c  |  51 ++
 tools/linker-tables/arch/x86/kernel/vmlinux.lds.S  | 273 +
 tools/linker-tables/arch/x86/mm/init.c |  10 +
 tools/linker-tables/arch/x86/xen/init.c|  13 +
 tools/linker-tables/drivers/acme.c |  32 +
 tools/linker-tables/drivers/synth/common.c |  16 +
 tools/linker-tables/drivers/synth/common.h |   2 +
 tools/linker-tables/drivers/synth/main.c   |  35 ++
 tools/linker-tables/drivers/synth/or.S |  39 ++
 tools/linker-tables/drivers/synth/synth.h  |   2 +
 tools/linker-tables/drivers/xen-driver.c   |  11 +
 .../include/asm-generic/arch_init_fn.h |  50 

[Xen-devel] [PATCH v1 1/7] tools: add a userspace tools bug.h

[mcgrof]

From: "Luis R. Rodriguez" 

This will be used later by the userspace linker-tables sandbox.
As a convenience, include bug.h on kernel.h -- this is not done
on upstream kernel.h, however most header files do include bug.h
eventually, if we were to only add the ones that need it we'd
need to copy a lot of headers to tools for the ony purpose of
includeing bug.h. This simplifies that.

Signed-off-by: Luis R. Rodriguez 
---
 tools/include/asm-generic/bug.h | 24 
 tools/include/linux/bug.h   |  6 ++
 tools/include/linux/kernel.h|  2 ++
 3 files changed, 32 insertions(+)
 create mode 100644 tools/include/asm-generic/bug.h
 create mode 100644 tools/include/linux/bug.h

diff --git a/tools/include/asm-generic/bug.h b/tools/include/asm-generic/bug.h
new file mode 100644
index ..7b0f48b60dbe
--- /dev/null
+++ b/tools/include/asm-generic/bug.h
@@ -0,0 +1,24 @@
+#ifndef __TOOLS_ASM_GENERIC_BUG
+#define __TOOLS_ASM_GENERIC_BUG
+
+#include 
+#include 
+
+#define BUG() do { 
\
+   fprintf(stderr, 
"--\n");\
+   fprintf (stderr, "BUG on %s at %s: %i\n", __func__, __FILE__, 
__LINE__);\
+   abort();
\
+}  
\
+while (0)
+
+#define BUG_ON(cond) do { if (cond) BUG(); } while (0)
+
+#define WARN_ON(__test) do {   
\
+   if (__test) {   
\
+   fprintf(stderr, 
"--\n");\
+   fprintf (stderr, "WARN_ON on %s at %s: %i\n", __func__, 
__FILE__, __LINE__);\
+   }   
\
+}  
\
+while (0)
+
+#endif /* __TOOLS_ASM_GENERIC_BUG */
diff --git a/tools/include/linux/bug.h b/tools/include/linux/bug.h
new file mode 100644
index ..9be515b40b5c
--- /dev/null
+++ b/tools/include/linux/bug.h
@@ -0,0 +1,6 @@
+#ifndef _TOOLS_LINUX_BUG_H
+#define _TOOLS_LINUX_BUG_H
+
+#include 
+
+#endif /* _TOOLS_LINUX_BUG_H */
diff --git a/tools/include/linux/kernel.h b/tools/include/linux/kernel.h
index 28607db02bd3..3d385a6d4fc1 100644
--- a/tools/include/linux/kernel.h
+++ b/tools/include/linux/kernel.h
@@ -5,6 +5,8 @@
 #include 
 #include 
 
+#include 
+
 #define DIV_ROUND_UP(n,d) (((n) + (d) - 1) / (d))
 
 #define PERF_ALIGN(x, a)   __PERF_ALIGN_MASK(x, (typeof(x))(a)-1)
-- 
2.9.2


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

[Xen-devel] [PATCH v1 2/7] tools: add a basic tools printk.h

[mcgrof]

From: "Luis R. Rodriguez" 

This will be used later by the userspace linker-tables sandbox.
Since upstream kernel.h includes printk.h mimic this so we can
match and replicate C code as-is on userspace sandbox tools.

Signed-off-by: Luis R. Rodriguez 
---
 tools/include/linux/kernel.h |  1 +
 tools/include/linux/printk.h | 14 ++
 2 files changed, 15 insertions(+)
 create mode 100644 tools/include/linux/printk.h

diff --git a/tools/include/linux/kernel.h b/tools/include/linux/kernel.h
index 3d385a6d4fc1..afdf760bf35c 100644
--- a/tools/include/linux/kernel.h
+++ b/tools/include/linux/kernel.h
@@ -6,6 +6,7 @@
 #include 
 
 #include 
+#include 
 
 #define DIV_ROUND_UP(n,d) (((n) + (d) - 1) / (d))
 
diff --git a/tools/include/linux/printk.h b/tools/include/linux/printk.h
new file mode 100644
index ..7e34e9c817e8
--- /dev/null
+++ b/tools/include/linux/printk.h
@@ -0,0 +1,14 @@
+#ifndef __TOOLS_KERNEL_PRINTK__
+#define __TOOLS_KERNEL_PRINTK__
+
+#include 
+
+#ifndef pr_fmt
+#define pr_fmt(fmt)fmt
+#endif
+
+#define pr_info(fmt, ...)  printf(pr_fmt(fmt), ##__VA_ARGS__)
+#define pr_err(fmt, ...)   printf(pr_fmt(fmt), ##__VA_ARGS__)
+#define pr_debug(fmt, ...) printf(pr_fmt(fmt), ##__VA_ARGS__)
+
+#endif /* __TOOLS_KERNEL_PRINTK__ */
-- 
2.9.2


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

[Xen-devel] [PATCH v1 4/7] tools: add __used and enable to override

[mcgrof]

From: "Luis R. Rodriguez" 

This adds __used, to be used later in the userspace linker-tables
sandbox. If any userspace applicaiton wants to override they can
add their own definition and then use include_next.

This definition should probably suffice for most uses cases though.

Signed-off-by: Luis R. Rodriguez 
---
 tools/include/linux/compiler.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/tools/include/linux/compiler.h b/tools/include/linux/compiler.h
index e33fc1df3935..556c991de212 100644
--- a/tools/include/linux/compiler.h
+++ b/tools/include/linux/compiler.h
@@ -5,6 +5,12 @@
 /* The "volatile" is due to gcc bugs */
 #define barrier() __asm__ __volatile__("": : :"memory")
 
+
+/* You can override as you see fit on your userspace tool */
+#ifndef __used
+#define __used  __attribute__((__used__))
+#endif
+
 #ifndef __always_inline
 # define __always_inline   inline __attribute__((always_inline))
 #endif
-- 
2.9.2


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

[Xen-devel] [PATCH v4 15/16] kprobes: port .kprobes.text to section range

[mcgrof]

From: "Luis R. Rodriguez" 

kprobe makes use of two custom sections, each custom section
is folded into one of the standard Linux sections types as follows,
it currently relies on the linker script to fold the custom section
onto the respective Linux section:

type  Linux-section custom section name  beginend
table .init.data_kprobe_blacklist__start_kprobe_blacklist 
__stop_kprobe_blacklist
range .text .kprobes.text__kprobes_text_start 
__kprobes_text_end

This ports the .kprobes.text custom section to the standard
Linux ranges API allowing us remove all the custom kprobe section
declarations from the linker script.

Tested with CONFIG_KPROBES_SANITY_TEST, it passes with:

Kprobe smoke test: started
Kprobe smoke test: passed successfully

Then tested CONFIG_SAMPLE_KPROBES on do_fork, and the kprobe bites
and kicks as expected.

Also ran ./ftracetest with no issues:

$ sudo ./ftracetest
=== Ftrace unit tests ===
[1] Basic trace file check  [PASS]
[2] Basic test for tracers  [PASS]
[3] Basic trace clock test  [PASS]
[4] Basic event tracing check   [PASS]
[5] event tracing - enable/disable with event level files   [PASS]
[6] event tracing - restricts events based on pid   [PASS]
[7] event tracing - enable/disable with subsystem level files   [PASS]
[8] event tracing - enable/disable with top level files [PASS]
[9] ftrace - function graph filters with stack tracer   [PASS]
[10] ftrace - function graph filters[PASS]
[11] ftrace - function profiler with function tracing   [PASS]
[12] Test creation and deletion of trace instances while setting an event[PASS]
[13] Test creation and deletion of trace instances  [PASS]
[14] Kprobe dynamic event - adding and removing [PASS]
[15] Kprobe dynamic event - busy event check[PASS]
[16] Kprobe dynamic event with arguments[PASS]
[17] Kprobe dynamic event with function tracer  [PASS]
[18] Kretprobe dynamic event with arguments [PASS]
[19] event trigger - test event enable/disable trigger  [PASS]
[20] event trigger - test trigger filter[PASS]
[21] event trigger - test histogram modifiers   [PASS]
[22] event trigger - test histogram trigger [PASS]
[23] event trigger - test multiple histogram triggers   [PASS]
[24] event trigger - test snapshot-trigger  [PASS]
[25] event trigger - test stacktrace-trigger[PASS]
[26] event trigger - test traceon/off trigger   [PASS]

 # of passed:  26
 # of failed:  0
 # of unresolved:  0
 # of untested:  0
 # of unsupported:  0
 # of xfailed:  0
 # of undefined(test bug):  0

v4:

o arm64 build fixes with allmodconfig

o build fix suggested for avr32 with allnoconfig, otherwise we end up with:

arch/avr32/kernel/built-in.o: In function `save_full_context_ex':
(.ex.text+0x1c4): relocation truncated to fit: R_AVR32_16N_PCREL against
symbol `debug_trampoline' defined in .text.rng.kprobes.any section in
arch/avr32/kernel/built-in.o
arch/avr32/kernel/built-in.o: In function `debug_exit_work':
(.text.rng.kprobes.any+0xa8): relocation truncated to fit:
R_AVR32_16N_PCREL against `.ex.text'+3aa
make: *** [Makefile:953: vmlinux] Error 1

o open-code section use on scripts/ code -- folks to prefer the
  simplicity over dealing with having more tool code access kernel
  headers.

o NOPE: include #include  on compiler.h -- solves
  a few 0-day compilation issues

v3:

o after v2 arch/arm/kernel/vmlinux-xip.lds.S got kprobe support,
  this just removes the custom linker script reference to kprobes as
  that is no longer needed with linker tables.

o split kprobe linker table and kprobe section ranges use into
  two separate patches. This should make it easier to review and
  also demos both distinct use types, one a linker table another
  a simple section range.

v2: introduced this patch in this series

Signed-off-by: Luis R. Rodriguez 
---
 arch/arc/kernel/vmlinux.lds.S|  1 -
 arch/arm/kernel/entry-armv.S |  3 ++-
 arch/arm/kernel/vmlinux-xip.lds.S|  1 -
 arch/arm/kernel/vmlinux.lds.S|  1 -
 arch/arm64/kernel/armv8_deprecated.c |  1 +
 arch/arm64/kernel/probes/kprobes.c   |  4 ++--
 arch/arm64/kernel/vmlinux.lds.S  |  1 -
 arch/avr32/kernel/entry-avr32b.S | 13 +++--
 arch/avr32/kernel/vmlinux.lds.S  |  1 -
 arch/blackfin/kernel/vmlinux.lds.S   |  1 -
 arch/c6x/kernel/vmlinux.lds.S|  1 -
 arch/hexagon/kernel/vmlinux.lds.S|  1 -
 arch/ia64/kernel/jprobes.S   |  3 ++-
 arch/ia64/kernel/vmlinux.lds.S   |  1 -
 arch/ia64/lib/flush.S|  6 +++---
 arch/metag/kernel/vmlinux.lds.S  |  1 -
 arch/microblaze/kernel/vmlinux.lds.S |  1 -
 arch/mips/kernel/vmlinux.lds.S   |  1 -
 arch/mn10300/kernel/vmlinux.lds.S|  1 -
 arch/nios2/kernel/vmlinux.lds.S  |  1 -
 arch/openrisc/kernel/vmlinux.lds.S   |  1 -
 arch/parisc/kernel/vmlinux.lds.S |  1 -
 arch/powerpc/include/asm/ppc_asm.h   |  7 ---
 

[Xen-devel] [PATCH v4 09/16] firmware/Makefile: force recompilation if makefile changes

[mcgrof]

From: "Luis R. Rodriguez" 

If you modify the target asm we currently do not force the
recompilation of the firmware files. The target asm is in
the firmware/Makefile, peg this file as a dependency to
require re-compilation of firmware targets when the asm
changes.

v3: introduced in this series

Signed-off-by: Luis R. Rodriguez 
---
 firmware/Makefile | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/firmware/Makefile b/firmware/Makefile
index e297e1b52636..fa3e81c2a97b 100644
--- a/firmware/Makefile
+++ b/firmware/Makefile
@@ -176,7 +176,8 @@ quiet_cmd_fwbin = MK_FW   $@
 wordsize_deps := $(wildcard include/config/64bit.h include/config/32bit.h \
include/config/ppc32.h include/config/ppc64.h \
include/config/superh32.h include/config/superh64.h \
-   include/config/x86_32.h include/config/x86_64.h)
+   include/config/x86_32.h include/config/x86_64.h \
+   firmware/Makefile)
 
 $(patsubst %,$(obj)/%.gen.S, $(fw-shipped-y)): %: $(wordsize_deps)
$(call cmd,fwbin,$(patsubst %.gen.S,%,$@))
-- 
2.9.2


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

[Xen-devel] [PATCH v4 13/16] dynamic_debug: port to use linker tables

[mcgrof]

From: "Luis R. Rodriguez" 

This removes the custom vmlinux.lds.h hacks and uses
the generalized solution for .data (SECTION_DATA)
entries.

This is much more potential for further fine tuning here
though in the future. For instance, linker tables enable
an extra postfix for order level annotations, this could
easily be used as the KBUILD_MODNAME and with a bit of
linker table changes we may be able to get a direct O(1)
count of the entries for that KBUILD_MODNAME: it would
just be a count on the number of entries for the given
order level. This should help make dynamic_debug_init()
cleaner and also reduce the amount of time it takes at
boot time. Instead of iterating over each print until we
have all for a KBUILD_MODNAME, we'd instead directly
operate on each KBUILD_MODNAME directly.

Tested dynamic debug with dyndbg query ana debugfs control
and it works as expected, for both built-in code and modules.

v4: fix compilation on blackfin
v3: added modular support
v2: introduced this patch into the series

Cc: Barry Song 
Cc: Mike Frysinger 
Cc: Steven Miao 
Cc: Michael Matz 
Cc: Guenter Roeck 
Cc: Fengguang Wu 
Signed-off-by: Luis R. Rodriguez 
---
 include/asm-generic/vmlinux.lds.h |  5 -
 include/linux/dynamic_debug.h |  5 +++--
 lib/dynamic_debug.c   | 13 ++---
 scripts/module-common.lds.S   |  1 +
 4 files changed, 10 insertions(+), 14 deletions(-)

diff --git a/include/asm-generic/vmlinux.lds.h 
b/include/asm-generic/vmlinux.lds.h
index 140fbed4a817..ba49b7ad7af2 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -211,11 +211,6 @@
*(.data.unlikely)   \
STRUCT_ALIGN(); \
*(__tracepoints)\
-   /* implement dynamic printk debug */\
-   . = ALIGN(8);   \
-   VMLINUX_SYMBOL(__start___verbose) = .;  \
-   *(__verbose)\
-   VMLINUX_SYMBOL(__stop___verbose) = .;   \
LIKELY_PROFILE()\
BRANCH_PROFILE()\
TRACE_PRINTKS() \
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 546d68057e3b..a52618a77b09 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -4,6 +4,7 @@
 #if defined(CC_HAVE_ASM_GOTO) && defined(CONFIG_JUMP_LABEL)
 #include 
 #endif
+#include 
 
 /*
  * An instance of this structure is created in a special
@@ -50,6 +51,7 @@ int ddebug_add_module(struct _ddebug *tab, unsigned int n,
const char *modname);
 
 #if defined(CONFIG_DYNAMIC_DEBUG)
+DECLARE_LINKTABLE(struct _ddebug, __verbose);
 extern int ddebug_remove_module(const char *mod_name);
 extern __printf(2, 3)
 void __dynamic_pr_debug(struct _ddebug *descriptor, const char *fmt, ...);
@@ -71,8 +73,7 @@ void __dynamic_netdev_dbg(struct _ddebug *descriptor,
  const char *fmt, ...);
 
 #define DEFINE_DYNAMIC_DEBUG_METADATA_KEY(name, fmt, key, init)\
-   static struct _ddebug  __aligned(8) \
-   __attribute__((section("__verbose"))) name = {  \
+   static LINKTABLE(__verbose, SECTION_ORDER_ANY) name = { \
.modname = KBUILD_MODNAME,  \
.function = __func__,   \
.filename = __FILE__,   \
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index da796e2dc4f5..f0060c84c654 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -37,8 +37,7 @@
 #include 
 #include 
 
-extern struct _ddebug __start___verbose[];
-extern struct _ddebug __stop___verbose[];
+DEFINE_LINKTABLE(struct _ddebug, __verbose);
 
 struct ddebug_table {
struct list_head link;
@@ -978,14 +977,14 @@ static int __init dynamic_debug_init(void)
int n = 0, entries = 0, modct = 0;
int verbose_bytes = 0;
 
-   if (__start___verbose == __stop___verbose) {
-   pr_warn("_ddebug table is empty in a CONFIG_DYNAMIC_DEBUG 
build\n");
+   if (LINUX_SECTION_EMPTY(__verbose)) {
+   pr_warn("dynamic debug linker table empty on 
CONFIG_DYNAMIC_DEBUG build\n");
return 1;
}
-   iter = __start___verbose;
+   iter = LINUX_SECTION_START(__verbose);
modname = iter->modname;
iter_start = iter;
-   for (; iter < __stop___verbose; iter++) {
+   LINKTABLE_FOR_EACH(iter, __verbose) {

[Xen-devel] [PATCH v4 16/16] kprobes: port blacklist kprobes to linker table

[mcgrof]

From: "Luis R. Rodriguez" 

kprobe makes use of two sections, the one dealing with the actual
kprobes was recently ported using the standard section range API.
The blacklist functionality of kprobes is still using a custom
section and declaring its custom section using the linker script
as follows:

type  Linux-section custom section name  beginend
table .init.data_kprobe_blacklist__start_kprobe_blacklist 
__stop_kprobe_blacklist

This ports the _kprobe_blacklist custom section to the standard
Linux linker table API allowing us remove all the custom blacklist
kprobe section declarations from the linker script.

This has been tested by trying to register a kprobe on a blacklisted
symbol (these are declared with NOKPROBE_SYMBOL()), and confirms that
this fails to work as expected. This was tested with:

 # insmod samples/kprobes/kprobe_example.ko symbol="get_kprobe"

This fails to load as expected with:

insmod: ERROR: could not insert module samples/kprobes/kprobe_example.ko: 
Invalid parameters

v3: this patch was introduced in this series

Acked-by: Masami Hiramatsu 
Signed-off-by: Luis R. Rodriguez 
---
 include/asm-generic/kprobes.h |  4 ++--
 include/asm-generic/vmlinux.lds.h | 10 --
 include/linux/kprobes.h   |  2 ++
 kernel/kprobes.c  | 11 ---
 4 files changed, 8 insertions(+), 19 deletions(-)

diff --git a/include/asm-generic/kprobes.h b/include/asm-generic/kprobes.h
index 7b986f4b7ccd..23a49a4c7a38 100644
--- a/include/asm-generic/kprobes.h
+++ b/include/asm-generic/kprobes.h
@@ -3,14 +3,14 @@
 
 #if defined(__KERNEL__) && !defined(__ASSEMBLY__)
 #ifdef CONFIG_KPROBES
+#include 
 #include 
 /*
  * Blacklist ganerating macro. Specify functions which is not probed
  * by using this macro.
  */
 # define __NOKPROBE_SYMBOL(fname)  \
-static unsigned long __used\
-   __attribute__((__section__("_kprobe_blacklist")))   \
+static LINKTABLE_INIT_DATA(_kprobe_blacklist, all) \
_kbl_addr_##fname = (unsigned long)fname;
 # define NOKPROBE_SYMBOL(fname)__NOKPROBE_SYMBOL(fname)
 /* Use this to forbid a kprobes attach on very low level functions */
diff --git a/include/asm-generic/vmlinux.lds.h 
b/include/asm-generic/vmlinux.lds.h
index f2444d82d02a..47ef04de9958 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -114,15 +114,6 @@
 #define BRANCH_PROFILE()
 #endif
 
-#ifdef CONFIG_KPROBES
-#define KPROBE_BLACKLIST() . = ALIGN(8); \
-   VMLINUX_SYMBOL(__start_kprobe_blacklist) = .; \
-   *(_kprobe_blacklist)  \
-   VMLINUX_SYMBOL(__stop_kprobe_blacklist) = .;
-#else
-#define KPROBE_BLACKLIST()
-#endif
-
 #ifdef CONFIG_EVENT_TRACING
 #define FTRACE_EVENTS(). = ALIGN(8);   
\
VMLINUX_SYMBOL(__start_ftrace_events) = .;  \
@@ -525,7 +516,6 @@
*(SECTION_INIT_RODATA)  \
FTRACE_EVENTS() \
TRACE_SYSCALLS()\
-   KPROBE_BLACKLIST()  \
MEM_DISCARD(init.rodata)\
CLK_OF_TABLES() \
RESERVEDMEM_OF_TABLES() \
diff --git a/include/linux/kprobes.h b/include/linux/kprobes.h
index 445cc6fe7afa..2707820cbb56 100644
--- a/include/linux/kprobes.h
+++ b/include/linux/kprobes.h
@@ -44,8 +44,10 @@
 
 #ifdef CONFIG_KPROBES
 #include 
+#include 
 
 DECLARE_SECTION_RANGE(kprobes);
+DECLARE_LINKTABLE(unsigned long, _kprobe_blacklist);
 
 /* kprobe_status settings */
 #define KPROBE_HIT_ACTIVE  0x0001
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index 387605682622..4801aa3b4adf 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -2053,14 +2053,13 @@ NOKPROBE_SYMBOL(dump_kprobe);
  * since a kprobe need not necessarily be at the beginning
  * of a function.
  */
-static int __init populate_kprobe_blacklist(unsigned long *start,
-unsigned long *end)
+static int __init populate_kprobe_blacklist(void)
 {
unsigned long *iter;
struct kprobe_blacklist_entry *ent;
unsigned long entry, offset = 0, size = 0;
 
-   for (iter = start; iter < end; iter++) {
+   LINKTABLE_FOR_EACH(iter, _kprobe_blacklist) {
entry = arch_deref_entry_point((void *)*iter);
 
if (!kernel_text_address(entry) ||
@@ -2125,8 +2124,7 @@ static struct notifier_block kprobe_module_nb = {
 };
 
 /* Markers of _kprobe_blacklist section */

[Xen-devel] [PATCH v4 08/16] kbuild: enable option to force compile force-obj-y and force-lib-y

[mcgrof]

From: "Luis R. Rodriguez" 

Linux provides a rich array of features, enabling each feature
however increases the size of the kernel and there are many
features which users often want disabled. The traditional
solution to this problem is for each feature to have its own
Kconfig symbol, followed by a series of #ifdef statements
in C code and header files, allowing the feature to be compiled
only when desirable. As the variability of Linux increases build
tests can and are often done with random kernel configurations,
allyesconfig, and allmodconfig to help find code issues. This
however doesn't catch all errors and as a consequence code that
is typically not enabled often can suffer from bit-rot over time.

An alternative approach for subsystems, which refer to as the 'build-all
link-selectively philosophy' is to keep the Kconfig symbols, replace
the #ifdef approach by having each feature implemented it its own C file,
and force compilation for all features to avoid the code bit-rot problem.
With this strategy only features that are enabled via Kconfig get
linked into the kernel, so the forced compilation has no size impact
on the kernel. The practice of having each feature implemented in its own
C file is already prevalent in many subsystems, however #ifdefs are still
typically required during feature initialization. For instance in:

  #ifdef CONFIG_FOO
  foo_init();
  #endif

We cannot remove the #ifdef and leave foo_init() as we'd either
need to always enable the feature or add a respective #ifdef in a
foo.h which makes foo_init() do nothing when CONFIG_FOO is disabled.

Linker tables enable lifting the requirement to use of #ifdefs during
initialization. With linker tables initialization sequences can instead
be aggregated into a custom ELF section at link time, during run time
the table can be iterated over and each init sequence enabled can be called.
A feature's init routine is only added to a table when its respective
Kconfig symbols has been enabled and therefore linked in. Linker tables
enable subsystems to completely do away with #ifdefs if one is comfortable
in accepting all subsystem's feature's structural size implications.

Subsystems which want to follow the 'build-all link-selectively
philosophy' still need a way to easily express and annotate that they
wish for all code to always be compiled to help avoid code bit rot,
as such two new targets force-obj-y and force-lib-y are provided to
help with this. Its not fair to require everyone to force compilation
of all features of a subsystem though, so as a compromise, the new
targets only force compilation when CONFIG_BUILD_AVOID_BITROT is
enabled.

Only built-in features are supported at the moment. Module support
is expected to be added after a generic solution to add linker
tables to modules more easily is developed.

v4: this patch was added to this series, it was split off from the
linker tables addition due to the confusion over the code bit
rot alternatives that are possible with linker tables.

Signed-off-by: Luis R. Rodriguez 
---
 Documentation/kbuild/makefiles.txt   | 36 
 Documentation/sections/linker-tables.rst | 15 +++
 include/linux/tables.h   | 71 
 init/Kconfig | 22 ++
 scripts/Makefile.build   |  7 ++--
 scripts/Makefile.lib | 11 +
 6 files changed, 159 insertions(+), 3 deletions(-)

diff --git a/Documentation/kbuild/makefiles.txt 
b/Documentation/kbuild/makefiles.txt
index 385a5ef41c17..01c260913f5c 100644
--- a/Documentation/kbuild/makefiles.txt
+++ b/Documentation/kbuild/makefiles.txt
@@ -1089,6 +1089,42 @@ When kbuild executes, the following steps are followed 
(roughly):
In this example, extra-y is used to list object files that
shall be built, but shall not be linked as part of built-in.o.
 
+force-obj-y force-lib-y
+
+   When CONFIG_BUILD_AVOID_BITROT is enabled using these targets for your
+   kconfig symbols forces compilation of the associated objects if the
+   kconfig's symbol's dependencies are met, the objects however are only
+   linked into to the kernel if and only if the kconfig symbol was
+   enabled. If CONFIG_BUILD_AVOID_BITROT is disabled the force-obj-y and
+   force-lib-y targets are functionally equilvalent to obj-y and lib-y
+   respectively.
+
+   Using force-obj-y and force-lib-y are part of a code architecture and
+   build philosophy further enabled by linker tables, for more details
+   refer to the documention in include/linux/tables.h, refer to the
+   sections:
+
+   o The code bit-rot problem
+   o The build-all selective-link philosophy
+   o Avoiding the code bit-rot problem with linker tables
+   o Linker table module support
+
+   Modules support is expected to be enhanced in the 

[Xen-devel] [PATCH v4 06/16] ranges.h: add helpers to build and identify Linux section ranges

[mcgrof]

From: "Luis R. Rodriguez" 

Section ranges are on one of the types of custom sections
types used in Linux. This provides a series of helpers for
defining them and using them. Most importantly this also
enables us to avoid modifying the linker script when we
add a new section range.

It turns out a lot of custom sections are actually section ranges,
and these are typically spelled out in their architecture specific
asm/sections.h file -- we anable architectures to override what asm
is used for section ranges but start by default trusting the
asm-generic version all around.

v4:

o tons of documentation love
o fix arch/x86/tools/relocs.c typo - which caused compilation issues
  on old toolchains
o port to new shiny sphinx documentation
o sprinkle a few more needed VMLINUX_SYMBOL() - fixes
  compilation on blackfin
o name changes as suggested by Boris:
- %s/SECTION_TYPE_RANGES/rng/g
- %s/SECTION_TYPE/SECTION_CORE/g
- %s/section_type_asmtype/section_core_type/g
- %s/section_type/section_core/g
- %s/section_rng/set_section_rng/g
- rebrand DECLARE_SECTION_RNG() as DEFINE_SECTION_RANGE() - this is
  the asm version of the respective C version, this will have a
  userspace C demo added later.
o move __LINUX_RANGE() and __LINUX_RANGE_ORDER() - fixes builds
  on sparc
o adds section ranges to linker script
o rename SECTION_RANGE_ALL()
o use default alignment, fixes builds on powerpc and arm for both
  __LINUX_RANGE() and __LINUX_RANGE_ORDER()
o expand documentation to document modules support
o add maintainers
o use generic-y

v3: new in this series, uses copyleft-next

Signed-off-by: Luis R. Rodriguez 
---
 Documentation/sections/index.rst   |   1 +
 Documentation/sections/ranges.rst  |  49 ++
 MAINTAINERS|  10 +++
 arch/alpha/include/asm/Kbuild  |   1 +
 arch/arc/include/asm/Kbuild|   1 +
 arch/arm/include/asm/Kbuild|   1 +
 arch/arm64/include/asm/Kbuild  |   1 +
 arch/avr32/include/asm/Kbuild  |   1 +
 arch/blackfin/include/asm/Kbuild   |   1 +
 arch/c6x/include/asm/Kbuild|   1 +
 arch/cris/include/asm/Kbuild   |   1 +
 arch/frv/include/asm/Kbuild|   1 +
 arch/h8300/include/asm/Kbuild  |   1 +
 arch/hexagon/include/asm/Kbuild|   1 +
 arch/ia64/include/asm/Kbuild   |   1 +
 arch/m32r/include/asm/Kbuild   |   1 +
 arch/m68k/include/asm/Kbuild   |   1 +
 arch/metag/include/asm/Kbuild  |   1 +
 arch/microblaze/include/asm/Kbuild |   1 +
 arch/mips/include/asm/Kbuild   |   1 +
 arch/mn10300/include/asm/Kbuild|   1 +
 arch/nios2/include/asm/Kbuild  |   1 +
 arch/openrisc/include/asm/Kbuild   |   1 +
 arch/parisc/include/asm/Kbuild |   1 +
 arch/powerpc/include/asm/Kbuild|   1 +
 arch/s390/include/asm/Kbuild   |   1 +
 arch/score/include/asm/Kbuild  |   1 +
 arch/sh/include/asm/Kbuild |   1 +
 arch/sparc/include/asm/Kbuild  |   1 +
 arch/tile/include/asm/Kbuild   |   1 +
 arch/um/include/asm/Kbuild |   1 +
 arch/unicore32/include/asm/Kbuild  |   1 +
 arch/x86/include/asm/Kbuild|   1 +
 arch/x86/tools/relocs.c|   2 +
 arch/xtensa/include/asm/Kbuild |   1 +
 include/asm-generic/ranges.h   |  89 ++
 include/asm-generic/vmlinux.lds.h  |  12 +++-
 include/linux/ranges.h | 128 +
 38 files changed, 320 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/sections/ranges.rst
 create mode 100644 include/asm-generic/ranges.h
 create mode 100644 include/linux/ranges.h

diff --git a/Documentation/sections/index.rst b/Documentation/sections/index.rst
index d411e9b22eb3..6dd93ddd5dbe 100644
--- a/Documentation/sections/index.rst
+++ b/Documentation/sections/index.rst
@@ -9,3 +9,4 @@ used throughout the kernel to help declare and define them.
:maxdepth: 4
 
section-core
+   ranges
diff --git a/Documentation/sections/ranges.rst 
b/Documentation/sections/ranges.rst
new file mode 100644
index ..1293dcb3ab38
--- /dev/null
+++ b/Documentation/sections/ranges.rst
@@ -0,0 +1,49 @@
+
+Linux section ranges
+
+
+This documents Linux' use of section ranges, how you can use
+them and how they work.
+
+About section ranges
+
+
+Introduction
+
+.. kernel-doc:: include/linux/ranges.h
+   :doc: Introduction
+
+Section range module support
+
+.. kernel-doc:: include/linux/ranges.h
+   :doc: Section range module support
+
+Section range helpers
+=
+.. kernel-doc:: include/linux/ranges.h
+   :doc: Section range helpers
+
+DECLARE_SECTION_RANGE
+-
+.. kernel-doc:: include/linux/ranges.h
+   :functions: DECLARE_SECTION_RANGE
+
+DEFINE_SECTION_RANGE
+
+.. kernel-doc:: include/linux/ranges.h
+   :functions: DEFINE_SECTION_RANGE
+
+SECTION_ADDR_IN_RANGE
+-

[Xen-devel] [PATCH v4 11/16] jump_label: move guard #endif down where it belongs

[mcgrof]

From: "Luis R. Rodriguez" 

The ending header guard is misplaced. This has no
functional change, this is just an eye-sore.

Signed-off-by: Luis R. Rodriguez 
---
 include/linux/jump_label.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h
index 661af564fae8..1256f543b002 100644
--- a/include/linux/jump_label.h
+++ b/include/linux/jump_label.h
@@ -384,6 +384,6 @@ extern bool wrong_branch_error(void);
 #define static_branch_enable(x)static_key_enable(&(x)->key)
 #define static_branch_disable(x)   static_key_disable(&(x)->key)
 
-#endif /* _LINUX_JUMP_LABEL_H */
-
 #endif /* __ASSEMBLY__ */
+
+#endif /* _LINUX_JUMP_LABEL_H */
-- 
2.9.2


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

[Xen-devel] [PATCH v4 05/16] xtensa: skip adding literal when SORT() is used

[mcgrof]

From: "Luis R. Rodriguez" 

When SORT(foo.*) is used the current sed replacements add
SORT(foo.literal foo.*), this breaks linking. Avoid adding
literals for SORT globs, if needed, these need to be added
manually.

Signed-off-by: Luis R. Rodriguez 
---
 arch/xtensa/kernel/Makefile | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/xtensa/kernel/Makefile b/arch/xtensa/kernel/Makefile
index c31f5d5afc7d..8180850ed147 100644
--- a/arch/xtensa/kernel/Makefile
+++ b/arch/xtensa/kernel/Makefile
@@ -29,10 +29,10 @@ AFLAGS_mxhead.o += -mtext-section-literals
 #
 # Replicate rules in scripts/Makefile.build
 
-sed-y = -e ':a; s/\*(\([^)]*\)\.text\.unlikely/*(\1.literal.unlikely 
.{text}.unlikely/; ta; ' \
-   -e ':b; s/\*(\([^)]*\)\.text\(\.[a-z]*\)/*(\1.{text}\2.literal 
.{text}\2/; tb; ' \
-   -e ':c; s/\*(\([^)]*\)\(\.[a-z]*it\|\.ref\)\.text/*(\1\2.literal 
\2.{text}/; tc; ' \
-   -e ':d; s/\*(\([^)]\+ \|\)\.text/*(\1.literal .{text}/; td; ' \
+sed-y = -e ':a; s/\*(\([^)SORT]*\)\.text\.unlikely/*(\1.literal.unlikely 
.{text}.unlikely/; ta; ' \
+   -e ':b; s/\*(\([^)SORT]*\)\.text\(\.[a-z]*\)/*(\1.{text}\2.literal 
.{text}\2/; tb; ' \
+   -e ':c; s/\*(\([^SORT)]*\)\(\.[a-z]*it\|\.ref\)\.text/*(\1\2.literal 
\2.{text}/; tc; ' \
+   -e ':d; s/\*(\([^SORT)]\+ \|\)\.text/*(\1.literal .{text}/; td; ' \
-e 's/\.{text}/.text/g'
 
 quiet_cmd__cpp_lds_S = LDS $@
-- 
2.9.2


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

[Xen-devel] [PATCH v4 12/16] jump_label: port __jump_table to linker tables

[mcgrof]

From: "Luis R. Rodriguez" 

Move the __jump_table from the a custom section solution
to a generic solution, this avoiding extra vmlinux.lds.h
customizations.

This also demos the use of the .data (SECTION_DATA) linker
table and of the shared asm call push_section_tbl().

Built-in kernel functionality was tested with CONFIG_STATIC_KEYS_SELFTEST.
Moduler  kernel functionality was tested with CONFIG_TEST_STATIC_KEYS.
Both work as expected.

Since __jump_table sections are also supported per
module this also required expanding module-common.lds.S
to capture and fold all .data.tlb.__jump_table.* onto
the the section __jump_table -- in this case for modules
need to keep a reference in place, given the alternative
is to use DEFINE_LINKTABLE(struct jump_entry, __jump_table)
per module -- and later through macro hacks instantiate
the jump entries per module upon init. This is doable but
we'd loose out on the sorting of the table using the
linker, to sort we'd always still need to expand the
module common linker script. An alternative mechanism
is possible which would make these custom module sections
extensions dynamic without requiring manual changes, this
however is best done later through a separate evolution
once linker tables are in place.

A careful reviewer may note that some architectures use
"\n\t" to separate asm code, while others just use a new line.
Upon review last time it was deemed reasonable to for all
architectures to just use "\n", this is defined as ASM_CMD_SEP,
and if an architecture needs to override they can do so on their
architecture sections.h prior to including asm-generic/sections.h

v4:

o Some architectures allow linker scripts to follow including header
  files, some others do not, so if you need a helper on a linker script
  you need to explicitly include it. So for instance although
  scripts/module-common.lds.S includes  and this file
  includes , you still need to explicitly
  include it on the linker script. This issue is present on ARM.

o as per Josh Poimboeuf open code the section table name instead
  of including the kernel section headers, the simplicity and
  independence from the kernel is preferred.

v3:

o More elaborate tests performed
o first modular support use case, module tested was
  CONFIG_TEST_STATIC_KEYS (lib/test_static_keys.ko), this
  required us to extend module-common.lds.S
o use generic push_section_tbl_any() for all architectures
o Makes use of ASM_CMD_SEP to enable architectures to override later
  if needed
o guard tables.h inclusion and table definition with __KERNEL__

v2: introduced in this series

Signed-off-by: Luis R. Rodriguez 
---
 arch/arm/include/asm/jump_label.h |  6 --
 arch/arm64/include/asm/jump_label.h   |  6 --
 arch/mips/include/asm/jump_label.h|  6 --
 arch/powerpc/include/asm/jump_label.h |  8 +---
 arch/s390/include/asm/jump_label.h|  6 --
 arch/sparc/include/asm/jump_label.h   |  6 --
 arch/x86/include/asm/jump_label.h | 10 ++
 include/asm-generic/vmlinux.lds.h |  4 
 include/linux/jump_label.h|  4 ++--
 kernel/jump_label.c   | 17 ++---
 scripts/module-common.lds.S   |  5 +
 tools/objtool/special.c   |  2 +-
 12 files changed, 49 insertions(+), 31 deletions(-)

diff --git a/arch/arm/include/asm/jump_label.h 
b/arch/arm/include/asm/jump_label.h
index 34f7b6980d21..960135a7b88e 100644
--- a/arch/arm/include/asm/jump_label.h
+++ b/arch/arm/include/asm/jump_label.h
@@ -1,6 +1,8 @@
 #ifndef _ASM_ARM_JUMP_LABEL_H
 #define _ASM_ARM_JUMP_LABEL_H
 
+#include 
+
 #ifndef __ASSEMBLY__
 
 #include 
@@ -12,7 +14,7 @@ static __always_inline bool arch_static_branch(struct 
static_key *key, bool bran
 {
asm_volatile_goto("1:\n\t"
 WASM(nop) "\n\t"
-".pushsection __jump_table,  \"aw\"\n\t"
+push_section_tbl_any(SECTION_DATA, __jump_table, aw)
 ".word 1b, %l[l_yes], %c0\n\t"
 ".popsection\n\t"
 : :  "i" (&((char *)key)[branch]) :  : l_yes);
@@ -26,7 +28,7 @@ static __always_inline bool arch_static_branch_jump(struct 
static_key *key, bool
 {
asm_volatile_goto("1:\n\t"
 WASM(b) " %l[l_yes]\n\t"
-".pushsection __jump_table,  \"aw\"\n\t"
+push_section_tbl_any(SECTION_DATA, __jump_table, aw)
 ".word 1b, %l[l_yes], %c0\n\t"
 ".popsection\n\t"
 : :  "i" (&((char *)key)[branch]) :  : l_yes);
diff --git a/arch/arm64/include/asm/jump_label.h 
b/arch/arm64/include/asm/jump_label.h
index 1b5e0e843c3a..aa52cd2607e3 100644
--- a/arch/arm64/include/asm/jump_label.h
+++ b/arch/arm64/include/asm/jump_label.h
@@ -19,6 +19,8 @@
 #ifndef __ASM_JUMP_LABEL_H
 #define __ASM_JUMP_LABEL_H
 
+#include 
+
 #ifndef __ASSEMBLY__
 
 #include 
@@ -29,7 +31,7 @@
 static __always_inline bool arch_static_branch(struct 

[Xen-devel] [PATCH v4 07/16] tables.h: add linker table support

[mcgrof]

From: "Luis R. Rodriguez" 

A linker table is a data structure that is stitched together from items
in multiple object files. Linux has historically implicitly used linker
tables for ages, however they were all built in an adhoc manner which
requires linker script modifications, per architecture. This adds a
general linker table solution so that a new linker table can be
implemented by changing C code only. The Linux linker table was
inspired by Michael Brown's iPXE's linker table solution, it has been
been completely re-written and adapted for integration and use on Linux.

The same philosophy is borrowed, extended and further simplified:

Linker tables enable an extremely light weight linker build time
solution for feature ordering and selection, this can help to both
simplify init sequences in a generic fashion and helps avoiding code
bit-rotting when desirable. Further changes will be added later
which will make more evident how code bit rot can be avoided using
linker tables.

v4:

o Split out kbuild additions to help with code bit rot into
  its own patch
o tons of documentation love
o fix arch/x86/tools/relocs.c typo - which caused compilation issues
  on old toolchains
o add c6x toolchain work around as discussed with Mark Salter
o sprinkle a few more needed VMLINUX_SYMBOL() - fixes
  compilation on blackfin
o suggested name changes by boris:
- %s/SECTION_TYPE_RANGES/rng/g
- %s/SECTION_TYPE/SECTION_CORE/g
- %s/section_type_asmtype/section_core_type/g
- %s/section_type/section_core/g
- %s/section_rng/set_section_rng/g
- Drop DECLARE_SECTION_TBL() -- this is an asm equivalent
  DEFINE_LINKTABLE() -- this however is not used yet, and it requires
  a bit more work to match the C code definitions.
o drop tools/include/linux/sections.h in favor of the more popular open
  coding the names for tools
o expand documentation to include module support
o add maintaners
o Use generic-y
o move .text.tbl before unlikely to match the other sections

v3:

o addressed initial modular support test cases
o added generic asm macros so linker tables can be used in
  asm code / C asm calls
o section ranges are now split up into their own set of files
o use asm/sections.h instead of linux/sections.h for the linker
  script
o add a sections.h file for each architecture that was missing one,
  this is needed now as we'll be relying on sections.h for custom
  section types in code rather than custom architecture specific
  linker script hacks.
o full rewrite at this point, decided to pick copyleft-next license
  for this work

v2:

o modified completely to match feedback by community, made equivalent
  modifications to userspace solution. This is pretty much a complete
  rewrite of how we present and use linker tables. By using standard
  sections we no longer have to make custom linker script extensions
  for each new linker table solution, you just pick a linker table
  type by section type.
o extend documention considerably, including use of kdoc
o drop ICC hacks per popular request to ignore such issues for now
o use sections.h - this lets us streamline a clean use case of
  well documented sections. To help further with this make use of
  SECTION_TBL() to allow use of these in code and SECTION_TBL_ALL()
  on linker scripts, as well as SECTION_TBL_ALL_STR() on relocs.c
  when needed.

Cc: Michael Brown 
Signed-off-by: Luis R. Rodriguez 
---
 Documentation/sections/index.rst |   1 +
 Documentation/sections/linker-tables.rst | 187 ++
 MAINTAINERS  |  12 +
 arch/alpha/include/asm/Kbuild|   1 +
 arch/arc/include/asm/Kbuild  |   1 +
 arch/arm/include/asm/Kbuild  |   1 +
 arch/arm64/include/asm/Kbuild|   1 +
 arch/avr32/include/asm/Kbuild|   1 +
 arch/blackfin/include/asm/Kbuild |   1 +
 arch/c6x/include/asm/tables.h|  26 ++
 arch/cris/include/asm/Kbuild |   1 +
 arch/frv/include/asm/Kbuild  |   1 +
 arch/h8300/include/asm/Kbuild|   1 +
 arch/hexagon/include/asm/Kbuild  |   1 +
 arch/ia64/include/asm/Kbuild |   1 +
 arch/m32r/include/asm/Kbuild |   1 +
 arch/m68k/include/asm/Kbuild |   1 +
 arch/metag/include/asm/Kbuild|   1 +
 arch/microblaze/include/asm/Kbuild   |   1 +
 arch/mips/include/asm/Kbuild |   1 +
 arch/mn10300/include/asm/Kbuild  |   1 +
 arch/nios2/include/asm/Kbuild|   1 +
 arch/openrisc/include/asm/Kbuild |   1 +
 arch/parisc/include/asm/Kbuild   |   1 +
 arch/powerpc/include/asm/Kbuild  |   1 +
 arch/s390/include/asm/Kbuild |   1 +
 arch/score/include/asm/Kbuild|   1 +
 arch/sh/include/asm/Kbuild   |   1 +
 arch/sparc/include/asm/Kbuild|   1 +
 arch/tile/include/asm/Kbuild |   1 +
 arch/um/include/asm/Kbuild   |   1 

[Xen-devel] [PATCH v4 10/16] firmware: port built-in section to linker table

[mcgrof]

From: "Luis R. Rodriguez" 

This ports built-in firmware to use linker tables,
this replaces the custom section solution with a
generic solution.

This also demos the use of the .rodata (SECTION_RO)
linker tables.

Tested with 0 built-in firmware, 1 and 2 built-in
firmwares successfully.

v4:

o work around c6x toolchain bug by using SECTION_TBL_RO

o fix compilation on blackfin

v3:
o explicitly include tables.h as we no longer include
  tables.h from sections.h

o use new section_tbl_asmtype() helper on firmware/Makefile
  to enable having to unfold things on our own.

v2: introduced this file in this version of the series

Cc: Barry Song 
Cc: Mike Frysinger 
Cc: Steven Miao 
Cc: Michael Matz 
Cc: Guenter Roeck 
Cc: Fengguang Wu 
Signed-off-by: Luis R. Rodriguez 
---
 arch/x86/kernel/cpu/microcode/core.c |  8 
 drivers/base/firmware_class.c| 12 ++--
 firmware/Makefile|  3 ++-
 include/asm-generic/vmlinux.lds.h|  7 ---
 4 files changed, 12 insertions(+), 18 deletions(-)

diff --git a/arch/x86/kernel/cpu/microcode/core.c 
b/arch/x86/kernel/cpu/microcode/core.c
index df04b2d033f6..3e7c08d99601 100644
--- a/arch/x86/kernel/cpu/microcode/core.c
+++ b/arch/x86/kernel/cpu/microcode/core.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -91,15 +92,14 @@ static bool __init check_loader_disabled_bsp(void)
return *res;
 }
 
-extern struct builtin_fw __start_builtin_fw[];
-extern struct builtin_fw __end_builtin_fw[];
+DECLARE_LINKTABLE_RO(struct builtin_fw, builtin_fw);
 
 bool get_builtin_firmware(struct cpio_data *cd, const char *name)
 {
 #ifdef CONFIG_FW_LOADER
-   struct builtin_fw *b_fw;
+   const struct builtin_fw *b_fw;
 
-   for (b_fw = __start_builtin_fw; b_fw != __end_builtin_fw; b_fw++) {
+   LINKTABLE_FOR_EACH(b_fw, builtin_fw) {
if (!strcmp(name, b_fw->name)) {
cd->size = b_fw->size;
cd->data = b_fw->data;
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 22d1760a4278..8fbf03c3e4c2 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -43,15 +44,14 @@ MODULE_LICENSE("GPL");
 
 #ifdef CONFIG_FW_LOADER
 
-extern struct builtin_fw __start_builtin_fw[];
-extern struct builtin_fw __end_builtin_fw[];
+DEFINE_LINKTABLE_RO(struct builtin_fw, builtin_fw);
 
 static bool fw_get_builtin_firmware(struct firmware *fw, const char *name,
void *buf, size_t size)
 {
-   struct builtin_fw *b_fw;
+   const struct builtin_fw *b_fw;
 
-   for (b_fw = __start_builtin_fw; b_fw != __end_builtin_fw; b_fw++) {
+   LINKTABLE_FOR_EACH(b_fw, builtin_fw) {
if (strcmp(name, b_fw->name) == 0) {
fw->size = b_fw->size;
fw->data = b_fw->data;
@@ -67,9 +67,9 @@ static bool fw_get_builtin_firmware(struct firmware *fw, 
const char *name,
 
 static bool fw_is_builtin_firmware(const struct firmware *fw)
 {
-   struct builtin_fw *b_fw;
+   const struct builtin_fw *b_fw;
 
-   for (b_fw = __start_builtin_fw; b_fw != __end_builtin_fw; b_fw++)
+   LINKTABLE_FOR_EACH(b_fw, builtin_fw)
if (fw->data == b_fw->data)
return true;
 
diff --git a/firmware/Makefile b/firmware/Makefile
index fa3e81c2a97b..9e701bf4ced2 100644
--- a/firmware/Makefile
+++ b/firmware/Makefile
@@ -155,6 +155,7 @@ quiet_cmd_fwbin = MK_FW   $@
  ASM_ALIGN=$(if $(CONFIG_64BIT),3,2);   \
  PROGBITS=$(if $(CONFIG_ARM),%,@)progbits;  \
  echo "/* Generated by firmware/Makefile */"   > $@;\
+ echo "\#include "   >>$@;\
  echo ".section .rodata"   >>$@;\
  echo ".p2align $${ASM_ALIGN}" >>$@;\
  echo "_fw_$${FWSTR}_bin:" >>$@;\
@@ -164,7 +165,7 @@ quiet_cmd_fwbin = MK_FW   $@
  echo ".p2align $${ASM_ALIGN}" >>$@;\
  echo "_fw_$${FWSTR}_name:">>$@;\
  echo ".string \"$$FWNAME\""   >>$@;\
- echo ".section .builtin_fw,\"a\",$${PROGBITS}">>$@;\
+ echo "set_section_tbl_type(SECTION_TBL_RO, builtin_fw, 
SECTION_ORDER_ANY, a,$${PROGBITS})" >>$@;\
  echo ".p2align $${ASM_ALIGN}" >>$@;\
  echo "$${ASM_WORD} _fw_$${FWSTR}_name">>$@;\
  echo "$${ASM_WORD} 

[Xen-devel] [PATCH v4 04/16] generic-sections: add section core helpers

[mcgrof]

From: "Luis R. Rodriguez" 

Linux makes extensive use of custom ELF header sections,
documentation for these are well scatterred. Unify this
documentation in a central place and provide helpers to
build custom Linux sections.

This also generalizes sections code to enable avoiding
modifying the linker scripts when we want to add new
custom Linux sections. In order to make this generally
useful we need to ensure all architectures can make use of
core section helpers but that they can also override should
this be needed. Instead of relying on section.h this adds
a sections-core.h since this will be targetted to be safe
to be used on asm code, linker scripts and C code.

v4:

o Port to shiny new sphinx documentation format

o fix a unicore32 build, turns out this actually fixes unicore32
  defconfig builds which were failing for a long while. unicore32
  does not seem to grok well the type passed on a section declaration,
  this ignores it.

o Use VMLINUX_SYMBOL() in more user symbols (extern C code), not doing
  this was causing final linker issues with blackfin -- this is
  a CONFIG_HAVE_UNDERSCORE_SYMBOL_PREFIX=y architecture. The other one
  being metatag. metatag is not supported on 0-day so I cannot confirm
  compilation there.

o Added SECTION_CORE() for C code, used later by __LINUX_RANGE()

o Since SECTION_CORE() is defined for linker script and C code, share
  the same helper and just use a __stringify() for the C code as is done
  for the other C helpers.

o move generic sections to asm-generic/section-core.h instead.
  PowerPC compilation blows up if asm/jump_labels.h gets
  section.h included, fixing this is not in any way easy.
  The list of issues are endless. Moving new data to a new
  simple file resolves this.

o since things are now in asm-generic/section-core.h the
  guard changes on asm-generic/sections.h and each architecture
  sections.h are no longer needed

o Give generic sections some maintainer love, that change is
  Acked-by Arnd Bergmann, Josh and hpa.

o A few checkpatch.pl style fixes

o As suggested by James Hogan use generic-y to copy generic
  header files on architectures that do not have a sections.h
  instead of writing a simple file only to include the generic one.

v3:

o add missing sections.h for architectures that did not
  have it

o move generic sections to asm-generic/sections.h

o add generic asm helpers section_type(), section_type_asmtype(),
  push_section_type() -- these helpers enable easy use for
  for later declaring and using of custom linux sections using
  more standard APIs in both C code, asm code (C asm calls, or
  asm files), enabling future standardized section types to
  be more immediately accessible to asm code, not just C code.
  Note for ASM_CMD_SEP we use by default "\n", architectures needed
  to override can do so on their own sections.h prior to inclusion
  of asm-generic/sections.h

Signed-off-by: Luis R. Rodriguez 
---
 Documentation/index.rst   |   1 +
 Documentation/sections/conf.py|   4 +
 Documentation/sections/index.rst  |  11 +
 Documentation/sections/section-core.rst   | 153 ++
 MAINTAINERS   |  14 ++
 arch/alpha/include/asm/Kbuild |   1 +
 arch/arc/include/asm/Kbuild   |   1 +
 arch/arm/include/asm/Kbuild   |   1 +
 arch/arm64/include/asm/Kbuild |   1 +
 arch/avr32/include/asm/Kbuild |   1 +
 arch/blackfin/include/asm/Kbuild  |   1 +
 arch/c6x/include/asm/Kbuild   |   1 +
 arch/cris/include/asm/Kbuild  |   1 +
 arch/frv/include/asm/Kbuild   |   1 +
 arch/h8300/include/asm/Kbuild |   1 +
 arch/hexagon/include/asm/Kbuild   |   1 +
 arch/ia64/include/asm/Kbuild  |   1 +
 arch/m32r/include/asm/Kbuild  |   1 +
 arch/m68k/include/asm/Kbuild  |   1 +
 arch/metag/include/asm/Kbuild |   1 +
 arch/microblaze/include/asm/Kbuild|   1 +
 arch/mips/include/asm/Kbuild  |   1 +
 arch/mn10300/include/asm/Kbuild   |   1 +
 arch/nios2/include/asm/Kbuild |   1 +
 arch/openrisc/include/asm/Kbuild  |   1 +
 arch/parisc/include/asm/Kbuild|   1 +
 arch/powerpc/include/asm/Kbuild   |   1 +
 arch/s390/include/asm/Kbuild  |   1 +
 arch/score/include/asm/Kbuild |   1 +
 arch/sh/include/asm/Kbuild|   1 +
 arch/sparc/include/asm/Kbuild |   1 +
 arch/tile/include/asm/Kbuild  |   1 +
 arch/um/include/asm/Kbuild|   1 +
 arch/unicore32/include/asm/section-core.h |  19 ++
 arch/x86/include/asm/Kbuild   |   1 +
 arch/xtensa/include/asm/Kbuild|   1 +
 include/asm-generic/section-core.h| 341 ++
 include/asm-generic/sections.h|   2 +
 include/asm-generic/vmlinux.lds.h  

[Xen-devel] [PATCH v4 07/16] tables.h: add linker table support

[mcgrof]

From: "Luis R. Rodriguez" 

A linker table is a data structure that is stitched together from items
in multiple object files. Linux has historically implicitly used linker
tables for ages, however they were all built in an adhoc manner which
requires linker script modifications, per architecture. This adds a
general linker table solution so that a new linker table can be
implemented by changing C code only. The Linux linker table was
inspired by Michael Brown's iPXE's linker table solution, it has been
been completely re-written and adapted for integration and use on Linux.

The same philosophy is borrowed, extended and further simplified:

Linker tables enable an extremely light weight linker build time
solution for feature ordering and selection, this can help to both
simplify init sequences in a generic fashion and helps avoiding code
bit-rotting when desirable. Further changes will be added later
which will make more evident how code bit rot can be avoided using
linker tables.

v4:

o Split out kbuild additions to help with code bit rot into
  its own patch
o tons of documentation love
o fix arch/x86/tools/relocs.c typo - which caused compilation issues
  on old toolchains
o add c6x toolchain work around as discussed with Mark Salter
o sprinkle a few more needed VMLINUX_SYMBOL() - fixes
  compilation on blackfin
o suggested name changes by boris:
- %s/SECTION_TYPE_RANGES/rng/g
- %s/SECTION_TYPE/SECTION_CORE/g
- %s/section_type_asmtype/section_core_type/g
- %s/section_type/section_core/g
- %s/section_rng/set_section_rng/g
- Drop DECLARE_SECTION_TBL() -- this is an asm equivalent
  DEFINE_LINKTABLE() -- this however is not used yet, and it requires
  a bit more work to match the C code definitions.
o drop tools/include/linux/sections.h in favor of the more popular open
  coding the names for tools
o expand documentation to include module support
o add maintaners
o Use generic-y
o move .text.tbl before unlikely to match the other sections

v3:

o addressed initial modular support test cases
o added generic asm macros so linker tables can be used in
  asm code / C asm calls
o section ranges are now split up into their own set of files
o use asm/sections.h instead of linux/sections.h for the linker
  script
o add a sections.h file for each architecture that was missing one,
  this is needed now as we'll be relying on sections.h for custom
  section types in code rather than custom architecture specific
  linker script hacks.
o full rewrite at this point, decided to pick copyleft-next license
  for this work

v2:

o modified completely to match feedback by community, made equivalent
  modifications to userspace solution. This is pretty much a complete
  rewrite of how we present and use linker tables. By using standard
  sections we no longer have to make custom linker script extensions
  for each new linker table solution, you just pick a linker table
  type by section type.
o extend documention considerably, including use of kdoc
o drop ICC hacks per popular request to ignore such issues for now
o use sections.h - this lets us streamline a clean use case of
  well documented sections. To help further with this make use of
  SECTION_TBL() to allow use of these in code and SECTION_TBL_ALL()
  on linker scripts, as well as SECTION_TBL_ALL_STR() on relocs.c
  when needed.

Cc: Michael Brown 
Signed-off-by: Luis R. Rodriguez 
---
 Documentation/sections/index.rst |   1 +
 Documentation/sections/linker-tables.rst | 187 ++
 MAINTAINERS  |  12 +
 arch/alpha/include/asm/Kbuild|   1 +
 arch/arc/include/asm/Kbuild  |   1 +
 arch/arm/include/asm/Kbuild  |   1 +
 arch/arm64/include/asm/Kbuild|   1 +
 arch/avr32/include/asm/Kbuild|   1 +
 arch/blackfin/include/asm/Kbuild |   1 +
 arch/c6x/include/asm/tables.h|  26 ++
 arch/cris/include/asm/Kbuild |   1 +
 arch/frv/include/asm/Kbuild  |   1 +
 arch/h8300/include/asm/Kbuild|   1 +
 arch/hexagon/include/asm/Kbuild  |   1 +
 arch/ia64/include/asm/Kbuild |   1 +
 arch/m32r/include/asm/Kbuild |   1 +
 arch/m68k/include/asm/Kbuild |   1 +
 arch/metag/include/asm/Kbuild|   1 +
 arch/microblaze/include/asm/Kbuild   |   1 +
 arch/mips/include/asm/Kbuild |   1 +
 arch/mn10300/include/asm/Kbuild  |   1 +
 arch/nios2/include/asm/Kbuild|   1 +
 arch/openrisc/include/asm/Kbuild |   1 +
 arch/parisc/include/asm/Kbuild   |   1 +
 arch/powerpc/include/asm/Kbuild  |   1 +
 arch/s390/include/asm/Kbuild |   1 +
 arch/score/include/asm/Kbuild|   1 +
 arch/sh/include/asm/Kbuild   |   1 +
 arch/sparc/include/asm/Kbuild|   1 +
 arch/tile/include/asm/Kbuild |   1 +
 arch/um/include/asm/Kbuild   |   1 

[Xen-devel] [PATCH v4 00/16] linux: generalize sections, ranges and linker tables

[mcgrof]

From: "Luis R. Rodriguez" <mcg...@kernel.org>

This v4 addresses feedback from the previous v3 series [0], and also
addresses a huge array of additional tests against many architectures
outside of what 0-day provides. As I mentioned in my last v3 series,
0-day had only found one issue with the series, a blackfin architecture
linker issue with the last series. Guenter Rock was kind enough to give
my series a test spin on his test bed and he found quite a bit of other
oddball issues with obscure architectures, and even on x86 with an old
toolchain. After a lot of work and coordinating with a few maintainers
I'm happy to report all issues found so far through all possible testing
I could do are now fixed, this series also addresses all feedback from
the last series, as such this goes submitted as PATCH form.

In addressing fixing this work on a few architectures some of the previous
patches are further simplified. The kprobes port to linker tables is made
much easier now that I've addressed moving out core kprobe declarations
into asm-generic/kprobes.h. Refer to the patch "kprobes: move kprobe
declarations to asm-generic/kprobes.h". This makes for a much cleaner
solution across architectures.

Boris feedback on making the code bit rot feature optional is addressed
by using a new Kconfig symbol for this, CONFIG_BUILD_AVOID_BITROT,
but given Greg's concerns over lack of clarity over what this was all about
I've ripped that functionality out into its own patch with a bit more
extensive documentation and re-wording. See the patch "kbuild: enable option
to force compile force-obj-y and force-lib-y". I hope makes it clear how
linker tables can help with avoiding code bit rot. I've gone with a new
Kconfig symbol CONFIG_BUILD_AVOID_BITROT given CONFIG_COMPILE_TEST is
not available on UML, this feature is desirable on all architectures.

The documentation is revamped, now that the DocBook format is deprecated
I ported the documention into the trendy hipster Sphinx documentation
format.

AT Boris' request I've adapated the userspace linker table application
forintegration into the kernel under tools/ to make it easier to keep
things in sync, however since this requires a bit of changes to some headers
in tools/ I'll submit that separately.

[0] https://lkml.kernel.org/r/1469222687-1600-1-git-send-email-mcg...@kernel.org

If you'd like this in git-form, you can get it on the 20160819-linker-table-v4
branch of my linux-next tree on kernel.org, this also includes the series of
the linker table userspace sandbox:

https://git.kernel.org/cgit/linux/kernel/git/mcgrof/linux-next.git/log/?h=20160819-linker-table-v4

Please let me know if there are any concerns or questions.

Luis R. Rodriguez (16):
  x86: remove LTO_REFERENCE_INITCALL()
  dell-smo8800: include uaccess.h
  scripts/module-common.lds: enable generation
  generic-sections: add section core helpers
  xtensa: skip adding literal when SORT() is used
  ranges.h: add helpers to build and identify Linux section ranges
  tables.h: add linker table support
  kbuild: enable option to force compile force-obj-y and force-lib-y
  firmware/Makefile: force recompilation if makefile changes
  firmware: port built-in section to linker table
  jump_label: move guard #endif down where it belongs
  jump_label: port __jump_table to linker tables
  dynamic_debug: port to use linker tables
  kprobes: move kprobe declarations to asm-generic/kprobes.h
  kprobes: port .kprobes.text to section range
  kprobes: port blacklist kprobes to linker table

 .gitignore |   2 +
 Documentation/index.rst|   1 +
 Documentation/kbuild/makefiles.txt |  36 ++
 Documentation/sections/conf.py |   4 +
 Documentation/sections/index.rst   |  13 +
 Documentation/sections/linker-tables.rst   | 202 +++
 Documentation/sections/ranges.rst  |  49 ++
 Documentation/sections/section-core.rst| 153 +
 MAINTAINERS|  37 ++
 Makefile   |   6 +-
 arch/alpha/include/asm/Kbuild  |   4 +
 arch/arc/include/asm/Kbuild|   3 +
 arch/arc/include/asm/kprobes.h |   6 +-
 arch/arc/kernel/vmlinux.lds.S  |   1 -
 arch/arm/include/asm/Kbuild|   3 +
 arch/arm/include/asm/jump_label.h  |   6 +-
 arch/arm/include/asm/kprobes.h |   4 +
 arch/arm/kernel/entry-armv.S   |   3 +-
 arch/arm/kernel/vmlinux-xip.lds.S  |   1 -
 arch/arm/kernel/vmlinux.lds.S  |   1 -
 arch/arm/probes/decode.h   |   1 +
 arch/arm64/include/asm/Kbuild  |   3 +
 arch/arm64/include/asm/jump_label.h|   6 +-
 arch/arm64/include/asm/kprob

[Xen-devel] [PATCH v4 01/16] x86: remove LTO_REFERENCE_INITCALL()

[mcgrof]

From: "Luis R. Rodriguez" 

The setup for LTO never made it upstream, and although this has
some users, this is now really old stuff for a gcc 4.7 LTO problem.
We know that at least LTO_REFERENCE_INITCALL() work around can
be removed if LTO is not supported on v4.7 anymore.

As per Andi the DISABLE_LTO and LTO_CFLAGS are still neeeded though.

v3: added to this series, removing LTO_REFERENCE_INITCALL()
justifies that other future similar macros do not need
a respective LTO_REFERENCE_INITCALL() on them therefore
simplifying new code.

Acked-by: Andi Kleen 
Signed-off-by: Luis R. Rodriguez 
---
 include/linux/init.h | 20 +---
 1 file changed, 1 insertion(+), 19 deletions(-)

diff --git a/include/linux/init.h b/include/linux/init.h
index 1e5c131d5c9a..aa662ad80d9c 100644
--- a/include/linux/init.h
+++ b/include/linux/init.h
@@ -151,23 +151,6 @@ extern bool initcall_debug;
 
 #ifndef __ASSEMBLY__
 
-#ifdef CONFIG_LTO
-/* Work around a LTO gcc problem: when there is no reference to a variable
- * in a module it will be moved to the end of the program. This causes
- * reordering of initcalls which the kernel does not like.
- * Add a dummy reference function to avoid this. The function is
- * deleted by the linker.
- */
-#define LTO_REFERENCE_INITCALL(x) \
-   ; /* yes this is needed */  \
-   static __used __exit void *reference_##x(void)  \
-   {   \
-   return   \
-   }
-#else
-#define LTO_REFERENCE_INITCALL(x)
-#endif
-
 /* initcalls are now grouped by functionality into separate 
  * subsections. Ordering inside the subsections is determined
  * by link order. 
@@ -180,8 +163,7 @@ extern bool initcall_debug;
 
 #define __define_initcall(fn, id) \
static initcall_t __initcall_##fn##id __used \
-   __attribute__((__section__(".initcall" #id ".init"))) = fn; \
-   LTO_REFERENCE_INITCALL(__initcall_##fn##id)
+   __attribute__((__section__(".initcall" #id ".init"))) = fn;
 
 /*
  * Early initcalls run before initializing SMP.
-- 
2.9.2


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

[Xen-devel] [PATCH v4 03/16] scripts/module-common.lds: enable generation

[mcgrof]

From: "Luis R. Rodriguez" 

scripts/module-common.lds is currently pretty static, in the
future this may change and we will want access to kernel macros
to help expands certain areas. To get access to use macros we
need to generate module-common.lds from module-common.lds.S, for
now though only enable the generation. We'll later expand on this
as needed.

Since this file is now generated add it to .gitignore.

v4: add file to MAINTAINERS
v3: new to this series

Signed-off-by: Luis R. Rodriguez 
---
 .gitignore | 2 ++
 MAINTAINERS| 1 +
 Makefile   | 6 +-
 scripts/Makefile.modpost   | 2 +-
 scripts/{module-common.lds => module-common.lds.S} | 0
 5 files changed, 9 insertions(+), 2 deletions(-)
 rename scripts/{module-common.lds => module-common.lds.S} (100%)

diff --git a/.gitignore b/.gitignore
index c2ed4ecb0acd..0f0702054fdb 100644
--- a/.gitignore
+++ b/.gitignore
@@ -114,3 +114,5 @@ all.config
 
 # Kdevelop4
 *.kdev4
+
+scripts/module-common.lds
diff --git a/MAINTAINERS b/MAINTAINERS
index d635ab047f3a..5aec01883020 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7887,6 +7887,7 @@ M:Rusty Russell 
 S: Maintained
 F: include/linux/module.h
 F: kernel/module.c
+F: scripts/module-common.lds.S
 
 MOTION EYE VAIO PICTUREBOOK CAMERA DRIVER
 W: http://popies.net/meye/
diff --git a/Makefile b/Makefile
index 5c18baad7218..b3e5ea78d582 100644
--- a/Makefile
+++ b/Makefile
@@ -408,6 +408,10 @@ KBUILD_AFLAGS_MODULE  := -DMODULE
 KBUILD_CFLAGS_MODULE  := -DMODULE
 KBUILD_LDFLAGS_MODULE := -T $(srctree)/scripts/module-common.lds
 
+$(srctree)/scripts/module-common.lds: $(srctree)/scripts/module-common.lds.S
+   $(Q)$(CC) $(CFLAGS) $(INCLUDES) $(LINUXINCLUDE) -E -P \
+   -D__ASSEMBLY__ -DLINKER_SCRIPT -o $@ $<
+
 # Read KERNELRELEASE from include/config/kernel.release (if it exists)
 KERNELRELEASE = $(shell cat include/config/kernel.release 2> /dev/null)
 KERNELVERSION = $(VERSION)$(if $(PATCHLEVEL),.$(PATCHLEVEL)$(if 
$(SUBLEVEL),.$(SUBLEVEL)))$(EXTRAVERSION)
@@ -1174,7 +1178,7 @@ all: modules
 # using awk while concatenating to the final file.
 
 PHONY += modules
-modules: $(vmlinux-dirs) $(if $(KBUILD_BUILTIN),vmlinux) modules.builtin
+modules: $(srctree)/scripts/module-common.lds $(vmlinux-dirs) $(if 
$(KBUILD_BUILTIN),vmlinux) modules.builtin
$(Q)$(AWK) '!x[$$0]++' $(vmlinux-dirs:%=$(objtree)/%/modules.order) > 
$(objtree)/modules.order
@$(kecho) '  Building modules, stage 2.';
$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modpost
diff --git a/scripts/Makefile.modpost b/scripts/Makefile.modpost
index 1366a94b6c39..2d8aff7735d6 100644
--- a/scripts/Makefile.modpost
+++ b/scripts/Makefile.modpost
@@ -121,7 +121,7 @@ quiet_cmd_ld_ko_o = LD [M]  $@
  $(KBUILD_LDFLAGS_MODULE) $(LDFLAGS_MODULE) \
  -o $@ $(filter-out FORCE,$^)
 
-$(modules): %.ko :%.o %.mod.o FORCE
+$(modules): %.ko : $(srctree)/scripts/module-common.lds %.o %.mod.o FORCE
$(call if_changed,ld_ko_o)
 
 targets += $(modules)
diff --git a/scripts/module-common.lds b/scripts/module-common.lds.S
similarity index 100%
rename from scripts/module-common.lds
rename to scripts/module-common.lds.S
-- 
2.9.2


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

[Xen-devel] [PATCH v4 10/16] firmware: port built-in section to linker table

[mcgrof]

From: "Luis R. Rodriguez" 

This ports built-in firmware to use linker tables,
this replaces the custom section solution with a
generic solution.

This also demos the use of the .rodata (SECTION_RO)
linker tables.

Tested with 0 built-in firmware, 1 and 2 built-in
firmwares successfully.

v4:

o work around c6x toolchain bug by using SECTION_TBL_RO

o fix compilation on blackfin

v3:
o explicitly include tables.h as we no longer include
  tables.h from sections.h

o use new section_tbl_asmtype() helper on firmware/Makefile
  to enable having to unfold things on our own.

v2: introduced this file in this version of the series

Cc: Barry Song 
Cc: Mike Frysinger 
Cc: Steven Miao 
Cc: Michael Matz 
Cc: Guenter Roeck 
Cc: Fengguang Wu 
Signed-off-by: Luis R. Rodriguez 
---
 arch/x86/kernel/cpu/microcode/core.c |  8 
 drivers/base/firmware_class.c| 12 ++--
 firmware/Makefile|  3 ++-
 include/asm-generic/vmlinux.lds.h|  7 ---
 4 files changed, 12 insertions(+), 18 deletions(-)

diff --git a/arch/x86/kernel/cpu/microcode/core.c 
b/arch/x86/kernel/cpu/microcode/core.c
index df04b2d033f6..3e7c08d99601 100644
--- a/arch/x86/kernel/cpu/microcode/core.c
+++ b/arch/x86/kernel/cpu/microcode/core.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -91,15 +92,14 @@ static bool __init check_loader_disabled_bsp(void)
return *res;
 }
 
-extern struct builtin_fw __start_builtin_fw[];
-extern struct builtin_fw __end_builtin_fw[];
+DECLARE_LINKTABLE_RO(struct builtin_fw, builtin_fw);
 
 bool get_builtin_firmware(struct cpio_data *cd, const char *name)
 {
 #ifdef CONFIG_FW_LOADER
-   struct builtin_fw *b_fw;
+   const struct builtin_fw *b_fw;
 
-   for (b_fw = __start_builtin_fw; b_fw != __end_builtin_fw; b_fw++) {
+   LINKTABLE_FOR_EACH(b_fw, builtin_fw) {
if (!strcmp(name, b_fw->name)) {
cd->size = b_fw->size;
cd->data = b_fw->data;
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 22d1760a4278..8fbf03c3e4c2 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -43,15 +44,14 @@ MODULE_LICENSE("GPL");
 
 #ifdef CONFIG_FW_LOADER
 
-extern struct builtin_fw __start_builtin_fw[];
-extern struct builtin_fw __end_builtin_fw[];
+DEFINE_LINKTABLE_RO(struct builtin_fw, builtin_fw);
 
 static bool fw_get_builtin_firmware(struct firmware *fw, const char *name,
void *buf, size_t size)
 {
-   struct builtin_fw *b_fw;
+   const struct builtin_fw *b_fw;
 
-   for (b_fw = __start_builtin_fw; b_fw != __end_builtin_fw; b_fw++) {
+   LINKTABLE_FOR_EACH(b_fw, builtin_fw) {
if (strcmp(name, b_fw->name) == 0) {
fw->size = b_fw->size;
fw->data = b_fw->data;
@@ -67,9 +67,9 @@ static bool fw_get_builtin_firmware(struct firmware *fw, 
const char *name,
 
 static bool fw_is_builtin_firmware(const struct firmware *fw)
 {
-   struct builtin_fw *b_fw;
+   const struct builtin_fw *b_fw;
 
-   for (b_fw = __start_builtin_fw; b_fw != __end_builtin_fw; b_fw++)
+   LINKTABLE_FOR_EACH(b_fw, builtin_fw)
if (fw->data == b_fw->data)
return true;
 
diff --git a/firmware/Makefile b/firmware/Makefile
index fa3e81c2a97b..9e701bf4ced2 100644
--- a/firmware/Makefile
+++ b/firmware/Makefile
@@ -155,6 +155,7 @@ quiet_cmd_fwbin = MK_FW   $@
  ASM_ALIGN=$(if $(CONFIG_64BIT),3,2);   \
  PROGBITS=$(if $(CONFIG_ARM),%,@)progbits;  \
  echo "/* Generated by firmware/Makefile */"   > $@;\
+ echo "\#include "   >>$@;\
  echo ".section .rodata"   >>$@;\
  echo ".p2align $${ASM_ALIGN}" >>$@;\
  echo "_fw_$${FWSTR}_bin:" >>$@;\
@@ -164,7 +165,7 @@ quiet_cmd_fwbin = MK_FW   $@
  echo ".p2align $${ASM_ALIGN}" >>$@;\
  echo "_fw_$${FWSTR}_name:">>$@;\
  echo ".string \"$$FWNAME\""   >>$@;\
- echo ".section .builtin_fw,\"a\",$${PROGBITS}">>$@;\
+ echo "set_section_tbl_type(SECTION_TBL_RO, builtin_fw, 
SECTION_ORDER_ANY, a,$${PROGBITS})" >>$@;\
  echo ".p2align $${ASM_ALIGN}" >>$@;\
  echo "$${ASM_WORD} _fw_$${FWSTR}_name">>$@;\
  echo "$${ASM_WORD} 

[Xen-devel] [PATCH v4 09/16] firmware/Makefile: force recompilation if makefile changes

[mcgrof]

From: "Luis R. Rodriguez" 

If you modify the target asm we currently do not force the
recompilation of the firmware files. The target asm is in
the firmware/Makefile, peg this file as a dependency to
require re-compilation of firmware targets when the asm
changes.

v3: introduced in this series

Signed-off-by: Luis R. Rodriguez 
---
 firmware/Makefile | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/firmware/Makefile b/firmware/Makefile
index e297e1b52636..fa3e81c2a97b 100644
--- a/firmware/Makefile
+++ b/firmware/Makefile
@@ -176,7 +176,8 @@ quiet_cmd_fwbin = MK_FW   $@
 wordsize_deps := $(wildcard include/config/64bit.h include/config/32bit.h \
include/config/ppc32.h include/config/ppc64.h \
include/config/superh32.h include/config/superh64.h \
-   include/config/x86_32.h include/config/x86_64.h)
+   include/config/x86_32.h include/config/x86_64.h \
+   firmware/Makefile)
 
 $(patsubst %,$(obj)/%.gen.S, $(fw-shipped-y)): %: $(wordsize_deps)
$(call cmd,fwbin,$(patsubst %.gen.S,%,$@))
-- 
2.9.2


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

[Xen-devel] [PATCH v4 02/16] dell-smo8800: include uaccess.h

[mcgrof]

From: "Luis R. Rodriguez" 

sections.h is currently included and it provides dell-smo8800
with what it needs, an upcoming change will decouple uaccess.h
from sections.h. This driver needs to explicitly require uaccess.h
before this change.

v3: new to this series -- needed due to collateral of the split of
old linker tables from tables.h into 3 files: sections.h, ranges.h
and tables.h

Reviewed-by: Pali Rohár 
Signed-off-by: Luis R. Rodriguez 
---
 drivers/platform/x86/dell-smo8800.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/platform/x86/dell-smo8800.c 
b/drivers/platform/x86/dell-smo8800.c
index 0aec4fd4c48e..37e646034ef8 100644
--- a/drivers/platform/x86/dell-smo8800.c
+++ b/drivers/platform/x86/dell-smo8800.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct smo8800_device {
u32 irq; /* acpi device irq */
-- 
2.9.2


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

[Xen-devel] [PATCH v4 00/16] linux: generalize sections, ranges and linker tables

[mcgrof]

From: "Luis R. Rodriguez" <mcg...@kernel.org>

This v4 addresses feedback from the previous v3 series [0], and also
addresses a huge array of additional tests against many architectures
outside of what 0-day provides. As I mentioned in my last v3 series,
0-day had only found one issue with the series, a blackfin architecture
linker issue with the last series. Guenter Rock was kind enough to give
my series a test spin on his test bed and he found quite a bit of other
oddball issues with obscure architectures, and even on x86 with an old
toolchain. After a lot of work and coordinating with a few maintainers
I'm happy to report all issues found so far through all possible testing
I could do are now fixed, this series also addresses all feedback from
the last series, as such this goes submitted as PATCH form.

In addressing fixing this work on a few architectures some of the previous
patches are further simplified. The kprobes port to linker tables is made
much easier now that I've addressed moving out core kprobe declarations
into asm-generic/kprobes.h. Refer to the patch "kprobes: move kprobe
declarations to asm-generic/kprobes.h". This makes for a much cleaner
solution across architectures.

Boris feedback on making the code bit rot feature optional is addressed
by using a new Kconfig symbol for this, CONFIG_BUILD_AVOID_BITROT,
but given Greg's concerns over lack of clarity over what this was all about
I've ripped that functionality out into its own patch with a bit more
extensive documentation and re-wording. See the patch "kbuild: enable option
to force compile force-obj-y and force-lib-y". I hope makes it clear how
linker tables can help with avoiding code bit rot. I've gone with a new
Kconfig symbol CONFIG_BUILD_AVOID_BITROT given CONFIG_COMPILE_TEST is
not available on UML, this feature is desirable on all architectures.

The documentation is revamped, now that the DocBook format is deprecated
I ported the documention into the trendy hipster Sphinx documentation
format.

AT Boris' request I've adapated the userspace linker table application
forintegration into the kernel under tools/ to make it easier to keep
things in sync, however since this requires a bit of changes to some headers
in tools/ I'll submit that separately.

[0] https://lkml.kernel.org/r/1469222687-1600-1-git-send-email-mcg...@kernel.org

If you'd like this in git-form, you can get it on the 20160819-linker-table-v4
branch of my linux-next tree on kernel.org, this also includes the series of
the linker table userspace sandbox:

https://git.kernel.org/cgit/linux/kernel/git/mcgrof/linux-next.git/log/?h=20160819-linker-table-v4

Please let me know if there are any concerns or questions.

Luis R. Rodriguez (16):
  x86: remove LTO_REFERENCE_INITCALL()
  dell-smo8800: include uaccess.h
  scripts/module-common.lds: enable generation
  generic-sections: add section core helpers
  xtensa: skip adding literal when SORT() is used
  ranges.h: add helpers to build and identify Linux section ranges
  tables.h: add linker table support
  kbuild: enable option to force compile force-obj-y and force-lib-y
  firmware/Makefile: force recompilation if makefile changes
  firmware: port built-in section to linker table
  jump_label: move guard #endif down where it belongs
  jump_label: port __jump_table to linker tables
  dynamic_debug: port to use linker tables
  kprobes: move kprobe declarations to asm-generic/kprobes.h
  kprobes: port .kprobes.text to section range
  kprobes: port blacklist kprobes to linker table

 .gitignore |   2 +
 Documentation/index.rst|   1 +
 Documentation/kbuild/makefiles.txt |  36 ++
 Documentation/sections/conf.py |   4 +
 Documentation/sections/index.rst   |  13 +
 Documentation/sections/linker-tables.rst   | 202 +++
 Documentation/sections/ranges.rst  |  49 ++
 Documentation/sections/section-core.rst| 153 +
 MAINTAINERS|  37 ++
 Makefile   |   6 +-
 arch/alpha/include/asm/Kbuild  |   4 +
 arch/arc/include/asm/Kbuild|   3 +
 arch/arc/include/asm/kprobes.h |   6 +-
 arch/arc/kernel/vmlinux.lds.S  |   1 -
 arch/arm/include/asm/Kbuild|   3 +
 arch/arm/include/asm/jump_label.h  |   6 +-
 arch/arm/include/asm/kprobes.h |   4 +
 arch/arm/kernel/entry-armv.S   |   3 +-
 arch/arm/kernel/vmlinux-xip.lds.S  |   1 -
 arch/arm/kernel/vmlinux.lds.S  |   1 -
 arch/arm/probes/decode.h   |   1 +
 arch/arm64/include/asm/Kbuild  |   3 +
 arch/arm64/include/asm/jump_label.h|   6 +-
 arch/arm64/include/asm/kprob

[Xen-devel] [PATCH v4 04/16] generic-sections: add section core helpers

[mcgrof]

From: "Luis R. Rodriguez" 

Linux makes extensive use of custom ELF header sections,
documentation for these are well scatterred. Unify this
documentation in a central place and provide helpers to
build custom Linux sections.

This also generalizes sections code to enable avoiding
modifying the linker scripts when we want to add new
custom Linux sections. In order to make this generally
useful we need to ensure all architectures can make use of
core section helpers but that they can also override should
this be needed. Instead of relying on section.h this adds
a sections-core.h since this will be targetted to be safe
to be used on asm code, linker scripts and C code.

v4:

o Port to shiny new sphinx documentation format

o fix a unicore32 build, turns out this actually fixes unicore32
  defconfig builds which were failing for a long while. unicore32
  does not seem to grok well the type passed on a section declaration,
  this ignores it.

o Use VMLINUX_SYMBOL() in more user symbols (extern C code), not doing
  this was causing final linker issues with blackfin -- this is
  a CONFIG_HAVE_UNDERSCORE_SYMBOL_PREFIX=y architecture. The other one
  being metatag. metatag is not supported on 0-day so I cannot confirm
  compilation there.

o Added SECTION_CORE() for C code, used later by __LINUX_RANGE()

o Since SECTION_CORE() is defined for linker script and C code, share
  the same helper and just use a __stringify() for the C code as is done
  for the other C helpers.

o move generic sections to asm-generic/section-core.h instead.
  PowerPC compilation blows up if asm/jump_labels.h gets
  section.h included, fixing this is not in any way easy.
  The list of issues are endless. Moving new data to a new
  simple file resolves this.

o since things are now in asm-generic/section-core.h the
  guard changes on asm-generic/sections.h and each architecture
  sections.h are no longer needed

o Give generic sections some maintainer love, that change is
  Acked-by Arnd Bergmann, Josh and hpa.

o A few checkpatch.pl style fixes

o As suggested by James Hogan use generic-y to copy generic
  header files on architectures that do not have a sections.h
  instead of writing a simple file only to include the generic one.

v3:

o add missing sections.h for architectures that did not
  have it

o move generic sections to asm-generic/sections.h

o add generic asm helpers section_type(), section_type_asmtype(),
  push_section_type() -- these helpers enable easy use for
  for later declaring and using of custom linux sections using
  more standard APIs in both C code, asm code (C asm calls, or
  asm files), enabling future standardized section types to
  be more immediately accessible to asm code, not just C code.
  Note for ASM_CMD_SEP we use by default "\n", architectures needed
  to override can do so on their own sections.h prior to inclusion
  of asm-generic/sections.h

Signed-off-by: Luis R. Rodriguez 
---
 Documentation/index.rst   |   1 +
 Documentation/sections/conf.py|   4 +
 Documentation/sections/index.rst  |  11 +
 Documentation/sections/section-core.rst   | 153 ++
 MAINTAINERS   |  14 ++
 arch/alpha/include/asm/Kbuild |   1 +
 arch/arc/include/asm/Kbuild   |   1 +
 arch/arm/include/asm/Kbuild   |   1 +
 arch/arm64/include/asm/Kbuild |   1 +
 arch/avr32/include/asm/Kbuild |   1 +
 arch/blackfin/include/asm/Kbuild  |   1 +
 arch/c6x/include/asm/Kbuild   |   1 +
 arch/cris/include/asm/Kbuild  |   1 +
 arch/frv/include/asm/Kbuild   |   1 +
 arch/h8300/include/asm/Kbuild |   1 +
 arch/hexagon/include/asm/Kbuild   |   1 +
 arch/ia64/include/asm/Kbuild  |   1 +
 arch/m32r/include/asm/Kbuild  |   1 +
 arch/m68k/include/asm/Kbuild  |   1 +
 arch/metag/include/asm/Kbuild |   1 +
 arch/microblaze/include/asm/Kbuild|   1 +
 arch/mips/include/asm/Kbuild  |   1 +
 arch/mn10300/include/asm/Kbuild   |   1 +
 arch/nios2/include/asm/Kbuild |   1 +
 arch/openrisc/include/asm/Kbuild  |   1 +
 arch/parisc/include/asm/Kbuild|   1 +
 arch/powerpc/include/asm/Kbuild   |   1 +
 arch/s390/include/asm/Kbuild  |   1 +
 arch/score/include/asm/Kbuild |   1 +
 arch/sh/include/asm/Kbuild|   1 +
 arch/sparc/include/asm/Kbuild |   1 +
 arch/tile/include/asm/Kbuild  |   1 +
 arch/um/include/asm/Kbuild|   1 +
 arch/unicore32/include/asm/section-core.h |  19 ++
 arch/x86/include/asm/Kbuild   |   1 +
 arch/xtensa/include/asm/Kbuild|   1 +
 include/asm-generic/section-core.h| 341 ++
 include/asm-generic/sections.h|   2 +
 include/asm-generic/vmlinux.lds.h  

[Xen-devel] [PATCH v4 08/16] kbuild: enable option to force compile force-obj-y and force-lib-y

[mcgrof]

From: "Luis R. Rodriguez" 

Linux provides a rich array of features, enabling each feature
however increases the size of the kernel and there are many
features which users often want disabled. The traditional
solution to this problem is for each feature to have its own
Kconfig symbol, followed by a series of #ifdef statements
in C code and header files, allowing the feature to be compiled
only when desirable. As the variability of Linux increases build
tests can and are often done with random kernel configurations,
allyesconfig, and allmodconfig to help find code issues. This
however doesn't catch all errors and as a consequence code that
is typically not enabled often can suffer from bit-rot over time.

An alternative approach for subsystems, which refer to as the 'build-all
link-selectively philosophy' is to keep the Kconfig symbols, replace
the #ifdef approach by having each feature implemented it its own C file,
and force compilation for all features to avoid the code bit-rot problem.
With this strategy only features that are enabled via Kconfig get
linked into the kernel, so the forced compilation has no size impact
on the kernel. The practice of having each feature implemented in its own
C file is already prevalent in many subsystems, however #ifdefs are still
typically required during feature initialization. For instance in:

  #ifdef CONFIG_FOO
  foo_init();
  #endif

We cannot remove the #ifdef and leave foo_init() as we'd either
need to always enable the feature or add a respective #ifdef in a
foo.h which makes foo_init() do nothing when CONFIG_FOO is disabled.

Linker tables enable lifting the requirement to use of #ifdefs during
initialization. With linker tables initialization sequences can instead
be aggregated into a custom ELF section at link time, during run time
the table can be iterated over and each init sequence enabled can be called.
A feature's init routine is only added to a table when its respective
Kconfig symbols has been enabled and therefore linked in. Linker tables
enable subsystems to completely do away with #ifdefs if one is comfortable
in accepting all subsystem's feature's structural size implications.

Subsystems which want to follow the 'build-all link-selectively
philosophy' still need a way to easily express and annotate that they
wish for all code to always be compiled to help avoid code bit rot,
as such two new targets force-obj-y and force-lib-y are provided to
help with this. Its not fair to require everyone to force compilation
of all features of a subsystem though, so as a compromise, the new
targets only force compilation when CONFIG_BUILD_AVOID_BITROT is
enabled.

Only built-in features are supported at the moment. Module support
is expected to be added after a generic solution to add linker
tables to modules more easily is developed.

v4: this patch was added to this series, it was split off from the
linker tables addition due to the confusion over the code bit
rot alternatives that are possible with linker tables.

Signed-off-by: Luis R. Rodriguez 
---
 Documentation/kbuild/makefiles.txt   | 36 
 Documentation/sections/linker-tables.rst | 15 +++
 include/linux/tables.h   | 71 
 init/Kconfig | 22 ++
 scripts/Makefile.build   |  7 ++--
 scripts/Makefile.lib | 11 +
 6 files changed, 159 insertions(+), 3 deletions(-)

diff --git a/Documentation/kbuild/makefiles.txt 
b/Documentation/kbuild/makefiles.txt
index 385a5ef41c17..01c260913f5c 100644
--- a/Documentation/kbuild/makefiles.txt
+++ b/Documentation/kbuild/makefiles.txt
@@ -1089,6 +1089,42 @@ When kbuild executes, the following steps are followed 
(roughly):
In this example, extra-y is used to list object files that
shall be built, but shall not be linked as part of built-in.o.
 
+force-obj-y force-lib-y
+
+   When CONFIG_BUILD_AVOID_BITROT is enabled using these targets for your
+   kconfig symbols forces compilation of the associated objects if the
+   kconfig's symbol's dependencies are met, the objects however are only
+   linked into to the kernel if and only if the kconfig symbol was
+   enabled. If CONFIG_BUILD_AVOID_BITROT is disabled the force-obj-y and
+   force-lib-y targets are functionally equilvalent to obj-y and lib-y
+   respectively.
+
+   Using force-obj-y and force-lib-y are part of a code architecture and
+   build philosophy further enabled by linker tables, for more details
+   refer to the documention in include/linux/tables.h, refer to the
+   sections:
+
+   o The code bit-rot problem
+   o The build-all selective-link philosophy
+   o Avoiding the code bit-rot problem with linker tables
+   o Linker table module support
+
+   Modules support is expected to be enhanced in the 

[Xen-devel] [PATCH v4 01/16] x86: remove LTO_REFERENCE_INITCALL()

[mcgrof]

From: "Luis R. Rodriguez" 

The setup for LTO never made it upstream, and although this has
some users, this is now really old stuff for a gcc 4.7 LTO problem.
We know that at least LTO_REFERENCE_INITCALL() work around can
be removed if LTO is not supported on v4.7 anymore.

As per Andi the DISABLE_LTO and LTO_CFLAGS are still neeeded though.

v3: added to this series, removing LTO_REFERENCE_INITCALL()
justifies that other future similar macros do not need
a respective LTO_REFERENCE_INITCALL() on them therefore
simplifying new code.

Acked-by: Andi Kleen 
Signed-off-by: Luis R. Rodriguez 
---
 include/linux/init.h | 20 +---
 1 file changed, 1 insertion(+), 19 deletions(-)

diff --git a/include/linux/init.h b/include/linux/init.h
index 1e5c131d5c9a..aa662ad80d9c 100644
--- a/include/linux/init.h
+++ b/include/linux/init.h
@@ -151,23 +151,6 @@ extern bool initcall_debug;
 
 #ifndef __ASSEMBLY__
 
-#ifdef CONFIG_LTO
-/* Work around a LTO gcc problem: when there is no reference to a variable
- * in a module it will be moved to the end of the program. This causes
- * reordering of initcalls which the kernel does not like.
- * Add a dummy reference function to avoid this. The function is
- * deleted by the linker.
- */
-#define LTO_REFERENCE_INITCALL(x) \
-   ; /* yes this is needed */  \
-   static __used __exit void *reference_##x(void)  \
-   {   \
-   return   \
-   }
-#else
-#define LTO_REFERENCE_INITCALL(x)
-#endif
-
 /* initcalls are now grouped by functionality into separate 
  * subsections. Ordering inside the subsections is determined
  * by link order. 
@@ -180,8 +163,7 @@ extern bool initcall_debug;
 
 #define __define_initcall(fn, id) \
static initcall_t __initcall_##fn##id __used \
-   __attribute__((__section__(".initcall" #id ".init"))) = fn; \
-   LTO_REFERENCE_INITCALL(__initcall_##fn##id)
+   __attribute__((__section__(".initcall" #id ".init"))) = fn;
 
 /*
  * Early initcalls run before initializing SMP.
-- 
2.9.2


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

[Xen-devel] [PATCH v4 06/16] ranges.h: add helpers to build and identify Linux section ranges

[mcgrof]

From: "Luis R. Rodriguez" 

Section ranges are on one of the types of custom sections
types used in Linux. This provides a series of helpers for
defining them and using them. Most importantly this also
enables us to avoid modifying the linker script when we
add a new section range.

It turns out a lot of custom sections are actually section ranges,
and these are typically spelled out in their architecture specific
asm/sections.h file -- we anable architectures to override what asm
is used for section ranges but start by default trusting the
asm-generic version all around.

v4:

o tons of documentation love
o fix arch/x86/tools/relocs.c typo - which caused compilation issues
  on old toolchains
o port to new shiny sphinx documentation
o sprinkle a few more needed VMLINUX_SYMBOL() - fixes
  compilation on blackfin
o name changes as suggested by Boris:
- %s/SECTION_TYPE_RANGES/rng/g
- %s/SECTION_TYPE/SECTION_CORE/g
- %s/section_type_asmtype/section_core_type/g
- %s/section_type/section_core/g
- %s/section_rng/set_section_rng/g
- rebrand DECLARE_SECTION_RNG() as DEFINE_SECTION_RANGE() - this is
  the asm version of the respective C version, this will have a
  userspace C demo added later.
o move __LINUX_RANGE() and __LINUX_RANGE_ORDER() - fixes builds
  on sparc
o adds section ranges to linker script
o rename SECTION_RANGE_ALL()
o use default alignment, fixes builds on powerpc and arm for both
  __LINUX_RANGE() and __LINUX_RANGE_ORDER()
o expand documentation to document modules support
o add maintainers
o use generic-y

v3: new in this series, uses copyleft-next

Signed-off-by: Luis R. Rodriguez 
---
 Documentation/sections/index.rst   |   1 +
 Documentation/sections/ranges.rst  |  49 ++
 MAINTAINERS|  10 +++
 arch/alpha/include/asm/Kbuild  |   1 +
 arch/arc/include/asm/Kbuild|   1 +
 arch/arm/include/asm/Kbuild|   1 +
 arch/arm64/include/asm/Kbuild  |   1 +
 arch/avr32/include/asm/Kbuild  |   1 +
 arch/blackfin/include/asm/Kbuild   |   1 +
 arch/c6x/include/asm/Kbuild|   1 +
 arch/cris/include/asm/Kbuild   |   1 +
 arch/frv/include/asm/Kbuild|   1 +
 arch/h8300/include/asm/Kbuild  |   1 +
 arch/hexagon/include/asm/Kbuild|   1 +
 arch/ia64/include/asm/Kbuild   |   1 +
 arch/m32r/include/asm/Kbuild   |   1 +
 arch/m68k/include/asm/Kbuild   |   1 +
 arch/metag/include/asm/Kbuild  |   1 +
 arch/microblaze/include/asm/Kbuild |   1 +
 arch/mips/include/asm/Kbuild   |   1 +
 arch/mn10300/include/asm/Kbuild|   1 +
 arch/nios2/include/asm/Kbuild  |   1 +
 arch/openrisc/include/asm/Kbuild   |   1 +
 arch/parisc/include/asm/Kbuild |   1 +
 arch/powerpc/include/asm/Kbuild|   1 +
 arch/s390/include/asm/Kbuild   |   1 +
 arch/score/include/asm/Kbuild  |   1 +
 arch/sh/include/asm/Kbuild |   1 +
 arch/sparc/include/asm/Kbuild  |   1 +
 arch/tile/include/asm/Kbuild   |   1 +
 arch/um/include/asm/Kbuild |   1 +
 arch/unicore32/include/asm/Kbuild  |   1 +
 arch/x86/include/asm/Kbuild|   1 +
 arch/x86/tools/relocs.c|   2 +
 arch/xtensa/include/asm/Kbuild |   1 +
 include/asm-generic/ranges.h   |  89 ++
 include/asm-generic/vmlinux.lds.h  |  12 +++-
 include/linux/ranges.h | 128 +
 38 files changed, 320 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/sections/ranges.rst
 create mode 100644 include/asm-generic/ranges.h
 create mode 100644 include/linux/ranges.h

diff --git a/Documentation/sections/index.rst b/Documentation/sections/index.rst
index d411e9b22eb3..6dd93ddd5dbe 100644
--- a/Documentation/sections/index.rst
+++ b/Documentation/sections/index.rst
@@ -9,3 +9,4 @@ used throughout the kernel to help declare and define them.
:maxdepth: 4
 
section-core
+   ranges
diff --git a/Documentation/sections/ranges.rst 
b/Documentation/sections/ranges.rst
new file mode 100644
index ..1293dcb3ab38
--- /dev/null
+++ b/Documentation/sections/ranges.rst
@@ -0,0 +1,49 @@
+
+Linux section ranges
+
+
+This documents Linux' use of section ranges, how you can use
+them and how they work.
+
+About section ranges
+
+
+Introduction
+
+.. kernel-doc:: include/linux/ranges.h
+   :doc: Introduction
+
+Section range module support
+
+.. kernel-doc:: include/linux/ranges.h
+   :doc: Section range module support
+
+Section range helpers
+=
+.. kernel-doc:: include/linux/ranges.h
+   :doc: Section range helpers
+
+DECLARE_SECTION_RANGE
+-
+.. kernel-doc:: include/linux/ranges.h
+   :functions: DECLARE_SECTION_RANGE
+
+DEFINE_SECTION_RANGE
+
+.. kernel-doc:: include/linux/ranges.h
+   :functions: DEFINE_SECTION_RANGE
+
+SECTION_ADDR_IN_RANGE
+-

[Xen-devel] [PATCH v4 05/16] xtensa: skip adding literal when SORT() is used

[mcgrof]

From: "Luis R. Rodriguez" 

When SORT(foo.*) is used the current sed replacements add
SORT(foo.literal foo.*), this breaks linking. Avoid adding
literals for SORT globs, if needed, these need to be added
manually.

Signed-off-by: Luis R. Rodriguez 
---
 arch/xtensa/kernel/Makefile | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/xtensa/kernel/Makefile b/arch/xtensa/kernel/Makefile
index c31f5d5afc7d..8180850ed147 100644
--- a/arch/xtensa/kernel/Makefile
+++ b/arch/xtensa/kernel/Makefile
@@ -29,10 +29,10 @@ AFLAGS_mxhead.o += -mtext-section-literals
 #
 # Replicate rules in scripts/Makefile.build
 
-sed-y = -e ':a; s/\*(\([^)]*\)\.text\.unlikely/*(\1.literal.unlikely 
.{text}.unlikely/; ta; ' \
-   -e ':b; s/\*(\([^)]*\)\.text\(\.[a-z]*\)/*(\1.{text}\2.literal 
.{text}\2/; tb; ' \
-   -e ':c; s/\*(\([^)]*\)\(\.[a-z]*it\|\.ref\)\.text/*(\1\2.literal 
\2.{text}/; tc; ' \
-   -e ':d; s/\*(\([^)]\+ \|\)\.text/*(\1.literal .{text}/; td; ' \
+sed-y = -e ':a; s/\*(\([^)SORT]*\)\.text\.unlikely/*(\1.literal.unlikely 
.{text}.unlikely/; ta; ' \
+   -e ':b; s/\*(\([^)SORT]*\)\.text\(\.[a-z]*\)/*(\1.{text}\2.literal 
.{text}\2/; tb; ' \
+   -e ':c; s/\*(\([^SORT)]*\)\(\.[a-z]*it\|\.ref\)\.text/*(\1\2.literal 
\2.{text}/; tc; ' \
+   -e ':d; s/\*(\([^SORT)]\+ \|\)\.text/*(\1.literal .{text}/; td; ' \
-e 's/\.{text}/.text/g'
 
 quiet_cmd__cpp_lds_S = LDS $@
-- 
2.9.2


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

[Xen-devel] [PATCH v4 03/16] scripts/module-common.lds: enable generation

[mcgrof]

From: "Luis R. Rodriguez" 

scripts/module-common.lds is currently pretty static, in the
future this may change and we will want access to kernel macros
to help expands certain areas. To get access to use macros we
need to generate module-common.lds from module-common.lds.S, for
now though only enable the generation. We'll later expand on this
as needed.

Since this file is now generated add it to .gitignore.

v4: add file to MAINTAINERS
v3: new to this series

Signed-off-by: Luis R. Rodriguez 
---
 .gitignore | 2 ++
 MAINTAINERS| 1 +
 Makefile   | 6 +-
 scripts/Makefile.modpost   | 2 +-
 scripts/{module-common.lds => module-common.lds.S} | 0
 5 files changed, 9 insertions(+), 2 deletions(-)
 rename scripts/{module-common.lds => module-common.lds.S} (100%)

diff --git a/.gitignore b/.gitignore
index c2ed4ecb0acd..0f0702054fdb 100644
--- a/.gitignore
+++ b/.gitignore
@@ -114,3 +114,5 @@ all.config
 
 # Kdevelop4
 *.kdev4
+
+scripts/module-common.lds
diff --git a/MAINTAINERS b/MAINTAINERS
index d635ab047f3a..5aec01883020 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7887,6 +7887,7 @@ M:Rusty Russell 
 S: Maintained
 F: include/linux/module.h
 F: kernel/module.c
+F: scripts/module-common.lds.S
 
 MOTION EYE VAIO PICTUREBOOK CAMERA DRIVER
 W: http://popies.net/meye/
diff --git a/Makefile b/Makefile
index 5c18baad7218..b3e5ea78d582 100644
--- a/Makefile
+++ b/Makefile
@@ -408,6 +408,10 @@ KBUILD_AFLAGS_MODULE  := -DMODULE
 KBUILD_CFLAGS_MODULE  := -DMODULE
 KBUILD_LDFLAGS_MODULE := -T $(srctree)/scripts/module-common.lds
 
+$(srctree)/scripts/module-common.lds: $(srctree)/scripts/module-common.lds.S
+   $(Q)$(CC) $(CFLAGS) $(INCLUDES) $(LINUXINCLUDE) -E -P \
+   -D__ASSEMBLY__ -DLINKER_SCRIPT -o $@ $<
+
 # Read KERNELRELEASE from include/config/kernel.release (if it exists)
 KERNELRELEASE = $(shell cat include/config/kernel.release 2> /dev/null)
 KERNELVERSION = $(VERSION)$(if $(PATCHLEVEL),.$(PATCHLEVEL)$(if 
$(SUBLEVEL),.$(SUBLEVEL)))$(EXTRAVERSION)
@@ -1174,7 +1178,7 @@ all: modules
 # using awk while concatenating to the final file.
 
 PHONY += modules
-modules: $(vmlinux-dirs) $(if $(KBUILD_BUILTIN),vmlinux) modules.builtin
+modules: $(srctree)/scripts/module-common.lds $(vmlinux-dirs) $(if 
$(KBUILD_BUILTIN),vmlinux) modules.builtin
$(Q)$(AWK) '!x[$$0]++' $(vmlinux-dirs:%=$(objtree)/%/modules.order) > 
$(objtree)/modules.order
@$(kecho) '  Building modules, stage 2.';
$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modpost
diff --git a/scripts/Makefile.modpost b/scripts/Makefile.modpost
index 1366a94b6c39..2d8aff7735d6 100644
--- a/scripts/Makefile.modpost
+++ b/scripts/Makefile.modpost
@@ -121,7 +121,7 @@ quiet_cmd_ld_ko_o = LD [M]  $@
  $(KBUILD_LDFLAGS_MODULE) $(LDFLAGS_MODULE) \
  -o $@ $(filter-out FORCE,$^)
 
-$(modules): %.ko :%.o %.mod.o FORCE
+$(modules): %.ko : $(srctree)/scripts/module-common.lds %.o %.mod.o FORCE
$(call if_changed,ld_ko_o)
 
 targets += $(modules)
diff --git a/scripts/module-common.lds b/scripts/module-common.lds.S
similarity index 100%
rename from scripts/module-common.lds
rename to scripts/module-common.lds.S
-- 
2.9.2


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

[Xen-devel] [PATCH v4 02/16] dell-smo8800: include uaccess.h

[mcgrof]

From: "Luis R. Rodriguez" 

sections.h is currently included and it provides dell-smo8800
with what it needs, an upcoming change will decouple uaccess.h
from sections.h. This driver needs to explicitly require uaccess.h
before this change.

v3: new to this series -- needed due to collateral of the split of
old linker tables from tables.h into 3 files: sections.h, ranges.h
and tables.h

Reviewed-by: Pali Rohár 
Signed-off-by: Luis R. Rodriguez 
---
 drivers/platform/x86/dell-smo8800.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/platform/x86/dell-smo8800.c 
b/drivers/platform/x86/dell-smo8800.c
index 0aec4fd4c48e..37e646034ef8 100644
--- a/drivers/platform/x86/dell-smo8800.c
+++ b/drivers/platform/x86/dell-smo8800.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct smo8800_device {
u32 irq; /* acpi device irq */
-- 
2.9.2


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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemut-rhel6hvm-intel  9 redhat-installfail REGR. vs. 67556
 test-amd64-amd64-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 
67556
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 9 windows-install fail REGR. vs. 67556

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt-raw 10 guest-start  fail blocked in 67556
 build-amd64-rumpuserxen   6 xen-buildfail   like 67556
 build-i386-rumpuserxen6 xen-buildfail   like 67556
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 67556
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
like 67556
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 67556
 test-amd64-i386-xl-qemut-winxpsp3  9 windows-install   fail like 67556

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

version targeted for testing:
 xen  361db13b0380a3462f788d44076f42f6f155e719
baseline version:
 xen  336d7239f8a703594f00e0d25ce0d1831f802952

Last test of basis67556  2016-08-18 11:47:17 Z1 days
Testing same since67560  2016-08-19 03:49:13 Z0 days1 attempts


People who touched revisions under test:
  Anthony PERARD 
  Jan Beulich 
  Juergen Gross 
  Wei Liu 

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl   7 host-ping-check-xen  fail REGR. vs. 100561

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

version targeted for testing:
 xen  2a99aa99fc84a45f505f84802af56b006d14c52e
baseline version:
 xen  f8992212c9ee537e67f30841e3232b982d74af2b

Last test of basis   100561  2016-08-19 16:01:07 Z0 days
Testing same since   100564  2016-08-19 18:01:31 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 

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



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

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

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

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


Not pushing.


commit 2a99aa99fc84a45f505f84802af56b006d14c52e
Author: Andrew Cooper 
Date:   Fri Aug 19 15:08:10 2016 +0100

xen/physmap: Do not permit a guest to populate PoD pages for itself

PoD is supposed to be entirely transparent to guest, but this interface has
been left exposed for a long time.

The use of PoD requires careful co-ordination by the toolstack with the
XENMEM_{get,set}_pod_target hypercalls, and xenstore ballooning target.  The
best a guest can do without toolstack cooperation crash.

Furthermore, there are combinations of features (e.g. c/s c63868ff "libxl:
disallow PCI device assignment for HVM guest when PoD is enabled") which a
toolstack might wish to explicitly prohibit (in this case, because the two
simply don't function in combination).  In such cases, the guest mustn't be
able to subvert the configuration chosen by the toolstack.

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

commit f2c060fc972b1cb7aa7a1be35508a9ebfd564fdc
Author: Andrew Cooper 
Date:   Fri Aug 19 14:28:54 2016 +0100

xen/memop: Latch current->domain in a local variable

It is more efficient.

Signed-off-by: Andrew Cooper 
Acked-by: Jan Beulich 
(qemu changes not included)

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

[Xen-devel] [qemu-mainline baseline-only test] 67559: regressions - trouble: broken/fail/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 67559 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67559/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl   3 host-install(3) broken REGR. vs. 67555
 test-amd64-amd64-xl-multivcpu  6 xen-boot fail REGR. vs. 67555
 test-amd64-amd64-xl-qemuu-win7-amd64  9 windows-install   fail REGR. vs. 67555

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

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

version targeted for testing:
 qemuu02b1ad881cbb1795029737a9077db60267dc0c6f
baseline version:
 qemuu5f0e775348082c355769a3df612e055abea61c06

Last test of basis67555  2016-08-18 08:46:39 Z1 days
Testing same since67559  2016-08-19 02:17:30 Z0 days1 attempts


People who touched revisions under test:
  Denis V. Lunev 
  Dmitry Fleytman 
  Evgeny Yakovlev 
  Fam Zheng 
  Jason Wang 
  Li Qiang 
  Li Zhijian 
  Peter Maydell 
  Prasad J Pandit 
  Stefan Hajnoczi 
  Zhang Chen 

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

[Xen-devel] HVMOP_altp2m_vcpu_enable_notify code example usage

[Dmitry Rockosov]

Hello Xen Team!

Does anybody have any code examples of HVMOP_altp2m_vcpu_enable_notify?

I want to fully test #VE, VMFUNC and EPTP Switching VM Function 0 in Xen,
but doesn't have any documentations/examples for it.
I tried xen-access test from tools/tests/xen-access, but looks like it
doesn't use VMFUNC and #VE, it simply changes VMCS entries with vmwrite,
w/o VMFUNC 0 (EPTP Switching).

Thanks in advance!

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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 00bcb5c27a5bb781099482c5763937334be91e76
baseline version:
 ovmf 7822a1d91d53e80525f571183a24d54488f5437f

Last test of basis67557  2016-08-18 17:21:52 Z1 days
Testing same since67561  2016-08-19 05:19:21 Z0 days1 attempts


People who touched revisions under test:
  Yonghong Zhu 

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



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

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

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


Push not applicable.


commit 00bcb5c27a5bb781099482c5763937334be91e76
Author: Yonghong Zhu 
Date:   Thu Aug 18 10:07:36 2016 +0800

BaseTools: check CONF_PATH env to get the configure files

Add CONF_PATH env check. First priority is user set the conf dir by
--conf option, then the CONF_PATH env, the last one is the standard
WORKSPACE(PACKAGE_PATH)/Conf.
Also print the conf path directory in the build log.

Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu 
Reviewed-by: Liming Gao 

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

[Xen-devel] [distros-debian-jessie test] 67562: tolerable all pass

[Platform Team regression test user]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-armhf-jessie-netboot-pygrub 12 saverestore-support-check fail 
never pass
 test-armhf-armhf-armhf-jessie-netboot-pygrub 11 migrate-support-check fail 
never pass

baseline version:
 flight   66973

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-jessie-netboot-pvgrub pass
 test-amd64-i386-i386-jessie-netboot-pvgrub   pass
 test-amd64-i386-amd64-jessie-netboot-pygrub  pass
 test-armhf-armhf-armhf-jessie-netboot-pygrub pass
 test-amd64-amd64-i386-jessie-netboot-pygrub  pass



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

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

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


Push not applicable.


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

Re: [Xen-devel] [PATCH v2] x86/PV: don't wrongly hide/expose CPUID.OSXSAVE from/to user mode

[Andrew Cooper]

On 19/08/16 18:09, Andrew Cooper wrote:
> On 19/08/16 13:53, Jan Beulich wrote:
>> User mode code generally cannot be expected to invoke the PV-enabled
>> CPUID Xen supports, and prior to the CPUID levelling changes for 4.7
>> (as well as even nowadays on levelling incapable hardware) such CPUID
>> invocations actually saw the host CR4.OSXSAVE value, whereas prior to
>> this patch
>> - on Intel guest user mode always saw the flag clear,
>> - on AMD guest user mode saw the flag set even when the guest kernel
>>   didn't enable use of XSAVE/XRSTOR.
>> Fold in the guest view of CR4.OSXSAVE when setting the levelling MSRs,
>> just like we do in other CPUID handling.
>>
>> To make guest CR4 changes immediately visible via CPUID, also invoke
>> ctxt_switch_levelling() from the CR4 write path.
>>
>> Signed-off-by: Jan Beulich 
> I have just rerun a more thorough test, and I clearly got some incorrect
> conclusions to start with.
>
> (XEN) '1' pressed -> Extreme debugging in progress...
> (XEN) Testing OSXSAVE
> (XEN) ** CR4[-], MSR[-], cpuid 0
> (XEN) ** CR4[+], MSR[-], cpuid 0
> (XEN) ** CR4[-], MSR[+], cpuid 0
> (XEN) ** CR4[+], MSR[+], cpuid 1
> (XEN) '2' pressed -> Extreme debugging in progress...
> (XEN) Testing APIC
> (XEN) ** APIC[-], MSR[-], cpuid 0
> (XEN) ** APIC[+], MSR[-], cpuid 0
> (XEN) ** APIC[-], MSR[+], cpuid 0
> (XEN) ** APIC[+], MSR[+], cpuid 1
> (XEN) Watchdog timer detects that CPU21 is stuck!
> ... (an IPI hitting this core while the APIC is hard disabled appears to
> get ignored, and other cores get unhappy)
>
> So on this Sandy Bridge box does match your observation of behaviour,
> and that masks are applied after fast-forwarded state.  I am rerunning
> on other hardware to see how they behave.

From Nehalem:

(XEN) '1' pressed -> Extreme debugging in progress...
(XEN) Testing OSXSAVE
(XEN) feature xsave missing - skipping OSXSAVE check
(XEN) '2' pressed -> Extreme debugging in progress...
(XEN) Testing APIC
(XEN) ** APIC[-], MSR[-], cpuid 0
(XEN) ** APIC[+], MSR[-], cpuid 0
(XEN) ** APIC[-], MSR[+], cpuid 0
(XEN) ** APIC[+], MSR[+], cpuid 1
(XEN) Watchdog timer detects that CPU6 is stuck!


From AMD Excavator:
(XEN) '1' pressed -> Extreme debugging in progress...
(XEN) Testing OSXSAVE
(XEN) ** CR4[-], MSR[-], cpuid 0
(XEN) ** CR4[+], MSR[-], cpuid 0
(XEN) ** CR4[-], MSR[+], cpuid 0
(XEN) ** CR4[+], MSR[+], cpuid 1
(XEN) '2' pressed -> Extreme debugging in progress...
(XEN) Testing APIC
(XEN) ** APIC[-], MSR[-], cpuid 0
(XEN) ** APIC[+], MSR[-], cpuid 0
(XEN) ** APIC[-], MSR[+], cpuid 0
(XEN) ** APIC[+], MSR[+], cpuid 1
(Curiously, no problems at all with short times of APIC hard disable)

~Andrew

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  f8992212c9ee537e67f30841e3232b982d74af2b
baseline version:
 xen  830f177d920bdb4fda4fcdcd3b8ac0928cb579fb

Last test of basis   100548  2016-08-18 17:07:26 Z1 days
Testing same since   100561  2016-08-19 16:01:07 Z0 days1 attempts


People who touched revisions under test:
  Derek Straka 
  Jan Beulich 

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



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=f8992212c9ee537e67f30841e3232b982d74af2b
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
f8992212c9ee537e67f30841e3232b982d74af2b
+ branch=xen-unstable-smoke
+ revision=f8992212c9ee537e67f30841e3232b982d74af2b
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.7-testing
+ '[' xf8992212c9ee537e67f30841e3232b982d74af2b = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' 

Re: [Xen-devel] [PATCH 2/2] xen/Kconfig: Misc tweaks

[Andrew Cooper]

On 19/08/16 17:50, Doug Goldstein wrote:
> On 8/19/16 11:14 AM, Jan Beulich wrote:
>>  >>> On 19.08.16 at 17:54,  wrote:
>>> * Drop one piece of trailing whitespace
>>>  * Reposition LATE_HWDOM so it sits properly nested inside XSM in menuconfig
>>>  * Spelling and grammar corrections
>>>
>>> Signed-off-by: Andrew Cooper 
>> Acked-by: Jan Beulich 
>> with one question:
>>
>>> @@ -141,7 +121,7 @@ config XSM_POLICY
>>> depends on XSM
>>> ---help---
>>>   This includes a default XSM policy in the hypervisor so that the
>>> - bootloader does not need to load a policy to get sane behavior from an
>>> + bootloader does not need to load a policy to get sane behaviour from 
>>> an
>> Isn't the original spelling valid in American English?

Oh - so it is.

I will drop this correction.  I already did for a lot of s/z (mis)use.

~Andrew

>>
>> Jan
>>
> Yes. An American English speaker wrote it originally as well. Spelling
> and grammatical changes to what I write are always welcome.
>
> Reviewed-by: Doug Goldstein 
>


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

[Xen-devel] [PATCH v2 Altp2m cleanup v3 2/3] Move altp2m specific functions to altp2m files.

[Paul Lai]

Move altp2m specific functions to altp2m files.  This makes the code
a little easier to read.

Also moving ept code to ept specific files as requested in:
  https://lists.xenproject.org/archives/html/xen-devel/2015-07/msg04323.html

Signed-off-by: Paul Lai 
---
 xen/arch/x86/mm/altp2m.c  | 45 +++
 xen/arch/x86/mm/hap/hap.c | 35 +-
 xen/arch/x86/mm/p2m-ept.c | 39 +
 xen/arch/x86/mm/p2m.c | 45 +++
 xen/include/asm-x86/altp2m.h  |  4 +++-
 xen/include/asm-x86/hvm/vmx/vmx.h |  3 +++
 xen/include/asm-x86/p2m.h |  9 +++-
 7 files changed, 101 insertions(+), 79 deletions(-)

diff --git a/xen/arch/x86/mm/altp2m.c b/xen/arch/x86/mm/altp2m.c
index 930bdc2..cc9b0fc 100644
--- a/xen/arch/x86/mm/altp2m.c
+++ b/xen/arch/x86/mm/altp2m.c
@@ -17,6 +17,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -65,6 +66,50 @@ altp2m_vcpu_destroy(struct vcpu *v)
 vcpu_unpause(v);
 }
 
+int
+hvm_altp2m_init( struct domain *d)
+{
+int rc = 0;
+unsigned int i = 0;
+
+/* Init alternate p2m data. */
+if ( (d->arch.altp2m_eptp = alloc_xenheap_page()) == NULL )
+{
+rc = -ENOMEM;
+goto out;
+}
+
+for ( i = 0; i < MAX_EPTP; i++ )
+d->arch.altp2m_eptp[i] = mfn_x(INVALID_MFN);
+
+for ( i = 0; i < MAX_ALTP2M; i++ )
+{
+rc = p2m_alloc_table(d->arch.altp2m_p2m[i]);
+if ( rc != 0 )
+   goto out;
+}
+
+d->arch.altp2m_active = 0;
+ out:
+return rc;
+}
+
+void
+hvm_altp2m_teardown( struct domain *d)
+{
+unsigned int i = 0;
+d->arch.altp2m_active = 0;
+
+if ( d->arch.altp2m_eptp )
+{
+free_xenheap_page(d->arch.altp2m_eptp);
+d->arch.altp2m_eptp = NULL;
+}
+
+for ( i = 0; i < MAX_ALTP2M; i++ )
+p2m_teardown(d->arch.altp2m_p2m[i]);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
index 3218fa2..6e1e9a5 100644
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -501,24 +502,9 @@ int hap_enable(struct domain *d, u32 mode)
 
 if ( hvm_altp2m_supported() )
 {
-/* Init alternate p2m data */
-if ( (d->arch.altp2m_eptp = alloc_xenheap_page()) == NULL )
-{
-rv = -ENOMEM;
-goto out;
-}
-
-for ( i = 0; i < MAX_EPTP; i++ )
-d->arch.altp2m_eptp[i] = mfn_x(INVALID_MFN);
-
-for ( i = 0; i < MAX_ALTP2M; i++ )
-{
-rv = p2m_alloc_table(d->arch.altp2m_p2m[i]);
-if ( rv != 0 )
-   goto out;
-}
-
-d->arch.altp2m_active = 0;
+rv = hvm_altp2m_init(d);
+if ( rv != 0 )
+   goto out;
 }
 
 /* Now let other users see the new mode */
@@ -534,18 +520,7 @@ void hap_final_teardown(struct domain *d)
 unsigned int i;
 
 if ( hvm_altp2m_supported() )
-{
-d->arch.altp2m_active = 0;
-
-if ( d->arch.altp2m_eptp )
-{
-free_xenheap_page(d->arch.altp2m_eptp);
-d->arch.altp2m_eptp = NULL;
-}
-
-for ( i = 0; i < MAX_ALTP2M; i++ )
-p2m_teardown(d->arch.altp2m_p2m[i]);
-}
+hvm_altp2m_teardown(d);
 
 /* Destroy nestedp2m's first */
 for (i = 0; i < MAX_NESTEDP2M; i++) {
diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index 13cab24..8247a02 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -1329,6 +1329,45 @@ void setup_ept_dump(void)
 register_keyhandler('D', ept_dump_p2m_table, "dump VT-x EPT tables", 0);
 }
 
+void p2m_init_altp2m_ept_helper( struct domain *d, unsigned int i)
+{
+struct p2m_domain *p2m = d->arch.altp2m_p2m[i];
+struct ept_data *ept;
+
+p2m->min_remapped_gfn = gfn_x(INVALID_GFN);
+p2m->max_remapped_gfn = 0;
+ept = >ept;
+ept->asr = pagetable_get_pfn(p2m_get_pagetable(p2m));
+d->arch.altp2m_eptp[i] = ept_get_eptp(ept);
+}
+
+unsigned int p2m_find_altp2m_by_eptp(struct domain *d, uint64_t eptp)
+{
+struct p2m_domain *p2m;
+struct ept_data *ept;
+unsigned int i;
+
+altp2m_list_lock(d);
+
+for ( i = 0; i < MAX_ALTP2M; i++ )
+{
+if ( d->arch.altp2m_eptp[i] == mfn_x(INVALID_MFN) )
+continue;
+
+p2m = d->arch.altp2m_p2m[i];
+ept = >ept;
+
+if ( eptp == ept_get_eptp(ept) )
+goto out;
+}
+
+i = INVALID_ALTP2M;
+
+ out:
+altp2m_list_unlock(d);
+return i;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index ff0cce8..7673663 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -196,8 +196,8 @@ static void p2m_teardown_altp2m(struct 

[Xen-devel] [PATCH v2 Altp2m cleanup v3 1/3] altp2m cleanup work

[Paul Lai]

Indent goto labels by one space
Inline (header) altp2m functions
Define default behavior in switch
Define max and min for range of altp2m macroed values

Signed-off-by: Paul Lai 
---
 xen/arch/x86/hvm/hvm.c| 46 ---
 xen/include/asm-x86/hvm/hvm.h | 19 +++---
 2 files changed, 37 insertions(+), 28 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 893eff6..1995fa4 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1932,11 +1932,11 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned 
long gla,
  * Otherwise, this is an error condition. */
 rc = fall_through;
 
-out_put_gfn:
+ out_put_gfn:
 __put_gfn(p2m, gfn);
 if ( ap2m_active )
 __put_gfn(hostp2m, gfn);
-out:
+ out:
 /* All of these are delayed until we exit, since we might 
  * sleep on event ring wait queues, and we must not hold
  * locks in such circumstance */
@@ -5213,12 +5213,25 @@ static int do_altp2m_op(
 return -EFAULT;
 
 if ( a.pad1 || a.pad2 ||
- (a.version != HVMOP_ALTP2M_INTERFACE_VERSION) ||
- (a.cmd < HVMOP_altp2m_get_domain_state) ||
- (a.cmd > HVMOP_altp2m_change_gfn) )
+(a.version != HVMOP_ALTP2M_INTERFACE_VERSION) )
 return -EINVAL;
 
-d = (a.cmd != HVMOP_altp2m_vcpu_enable_notify) ?
+switch( a.cmd )
+{
+case HVMOP_altp2m_get_domain_state:
+case HVMOP_altp2m_set_domain_state:
+case HVMOP_altp2m_vcpu_enable_notify:
+case HVMOP_altp2m_create_p2m:
+case HVMOP_altp2m_destroy_p2m:
+case HVMOP_altp2m_switch_p2m:
+case HVMOP_altp2m_set_mem_access:
+case HVMOP_altp2m_change_gfn:
+break;
+default:
+return -ENOSYS;
+}
+
+d = ( a.cmd != HVMOP_altp2m_vcpu_enable_notify ) ?
 rcu_lock_domain_by_any_id(a.domain) : rcu_lock_current_domain();
 
 if ( d == NULL )
@@ -5335,6 +5348,8 @@ static int do_altp2m_op(
 rc = p2m_change_altp2m_gfn(d, a.u.change_gfn.view,
 _gfn(a.u.change_gfn.old_gfn),
 _gfn(a.u.change_gfn.new_gfn));
+default:
+return -EINVAL;
 }
 
  out:
@@ -5859,25 +5874,6 @@ void hvm_toggle_singlestep(struct vcpu *v)
 v->arch.hvm_vcpu.single_step = !v->arch.hvm_vcpu.single_step;
 }
 
-void altp2m_vcpu_update_p2m(struct vcpu *v)
-{
-if ( hvm_funcs.altp2m_vcpu_update_p2m )
-hvm_funcs.altp2m_vcpu_update_p2m(v);
-}
-
-void altp2m_vcpu_update_vmfunc_ve(struct vcpu *v)
-{
-if ( hvm_funcs.altp2m_vcpu_update_vmfunc_ve )
-hvm_funcs.altp2m_vcpu_update_vmfunc_ve(v);
-}
-
-bool_t altp2m_vcpu_emulate_ve(struct vcpu *v)
-{
-if ( hvm_funcs.altp2m_vcpu_emulate_ve )
-return hvm_funcs.altp2m_vcpu_emulate_ve(v);
-return 0;
-}
-
 int hvm_set_mode(struct vcpu *v, int mode)
 {
 
diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
index 314881a..07109b7 100644
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -589,13 +589,26 @@ static inline bool_t hvm_altp2m_supported(void)
 }
 
 /* updates the current hardware p2m */
-void altp2m_vcpu_update_p2m(struct vcpu *v);
+static inline void altp2m_vcpu_update_p2m(struct vcpu *v)
+{
+if ( hvm_funcs.altp2m_vcpu_update_p2m )
+hvm_funcs.altp2m_vcpu_update_p2m(v);
+}
 
 /* updates VMCS fields related to VMFUNC and #VE */
-void altp2m_vcpu_update_vmfunc_ve(struct vcpu *v);
+static inline void altp2m_vcpu_update_vmfunc_ve(struct vcpu *v)
+{
+if ( hvm_funcs.altp2m_vcpu_update_vmfunc_ve )
+hvm_funcs.altp2m_vcpu_update_vmfunc_ve(v);
+}
 
 /* emulates #VE */
-bool_t altp2m_vcpu_emulate_ve(struct vcpu *v);
+static inline bool_t altp2m_vcpu_emulate_ve(struct vcpu *v)
+{
+if ( hvm_funcs.altp2m_vcpu_emulate_ve )
+return hvm_funcs.altp2m_vcpu_emulate_ve(v);
+return 0;
+}
 
 /* Check CR4/EFER values */
 const char *hvm_efer_valid(const struct vcpu *v, uint64_t value,
-- 
2.7.4


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

[Xen-devel] [PATCH v2 Altp2m cleanup v3 3/3] Making altp2m struct dynamically allocated.

[Paul Lai]

Ravi Sahita's dynamically allocated altp2m structs

Signed-off-by: Paul Lai 
Reviewed-by: Ravi Sahita 
---
 xen/arch/x86/hvm/hvm.c   |  8 +++---
 xen/arch/x86/hvm/vmx/vmx.c   |  2 +-
 xen/arch/x86/mm/altp2m.c | 18 ++---
 xen/arch/x86/mm/mm-locks.h   |  4 +--
 xen/arch/x86/mm/p2m-ept.c| 10 
 xen/arch/x86/mm/p2m.c| 61 
 xen/common/monitor.c |  1 +
 xen/include/asm-x86/altp2m.h |  7 -
 xen/include/asm-x86/domain.h |  6 ++---
 xen/include/asm-x86/p2m.h|  9 ++-
 10 files changed, 72 insertions(+), 54 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 1995fa4..115d8e7 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -5245,7 +5245,7 @@ static int do_altp2m_op(
 
 if ( (a.cmd != HVMOP_altp2m_get_domain_state) &&
  (a.cmd != HVMOP_altp2m_set_domain_state) &&
- !d->arch.altp2m_active )
+ !altp2m_active(d) )
 {
 rc = -EOPNOTSUPP;
 goto out;
@@ -5279,11 +5279,11 @@ static int do_altp2m_op(
 break;
 }
 
-ostate = d->arch.altp2m_active;
-d->arch.altp2m_active = !!a.u.domain_state.state;
+ostate = altp2m_active(d);
+set_altp2m_active(d, !!a.u.domain_state.state);
 
 /* If the alternate p2m state has changed, handle appropriately */
-if ( d->arch.altp2m_active != ostate &&
+if ( altp2m_active(d) != ostate &&
  (ostate || !(rc = p2m_init_altp2m_by_id(d, 0))) )
 {
 for_each_vcpu( d, v )
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 3d330b6..e7c8d04 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2018,7 +2018,7 @@ static void vmx_vcpu_update_vmfunc_ve(struct vcpu *v)
 {
 v->arch.hvm_vmx.secondary_exec_control |= mask;
 __vmwrite(VM_FUNCTION_CONTROL, VMX_VMFUNC_EPTP_SWITCHING);
-__vmwrite(EPTP_LIST_ADDR, virt_to_maddr(d->arch.altp2m_eptp));
+__vmwrite(EPTP_LIST_ADDR, virt_to_maddr(d->arch.altp2m->altp2m_eptp));
 
 if ( cpu_has_vmx_virt_exceptions )
 {
diff --git a/xen/arch/x86/mm/altp2m.c b/xen/arch/x86/mm/altp2m.c
index cc9b0fc..eec9ffc 100644
--- a/xen/arch/x86/mm/altp2m.c
+++ b/xen/arch/x86/mm/altp2m.c
@@ -73,23 +73,23 @@ hvm_altp2m_init( struct domain *d)
 unsigned int i = 0;
 
 /* Init alternate p2m data. */
-if ( (d->arch.altp2m_eptp = alloc_xenheap_page()) == NULL )
+if ( (d->arch.altp2m->altp2m_eptp = alloc_xenheap_page()) == NULL )
 {
 rc = -ENOMEM;
 goto out;
 }
 
 for ( i = 0; i < MAX_EPTP; i++ )
-d->arch.altp2m_eptp[i] = mfn_x(INVALID_MFN);
+d->arch.altp2m->altp2m_eptp[i] = mfn_x(INVALID_MFN);
 
 for ( i = 0; i < MAX_ALTP2M; i++ )
 {
-rc = p2m_alloc_table(d->arch.altp2m_p2m[i]);
+rc = p2m_alloc_table(d->arch.altp2m->altp2m_p2m[i]);
 if ( rc != 0 )
goto out;
 }
 
-d->arch.altp2m_active = 0;
+set_altp2m_active(d, 0);
  out:
 return rc;
 }
@@ -98,16 +98,16 @@ void
 hvm_altp2m_teardown( struct domain *d)
 {
 unsigned int i = 0;
-d->arch.altp2m_active = 0;
+set_altp2m_active(d, 0);
 
-if ( d->arch.altp2m_eptp )
+if ( d->arch.altp2m->altp2m_eptp )
 {
-free_xenheap_page(d->arch.altp2m_eptp);
-d->arch.altp2m_eptp = NULL;
+free_xenheap_page(d->arch.altp2m->altp2m_eptp);
+d->arch.altp2m->altp2m_eptp = NULL;
 }
 
 for ( i = 0; i < MAX_ALTP2M; i++ )
-p2m_teardown(d->arch.altp2m_p2m[i]);
+p2m_teardown(d->arch.altp2m->altp2m_p2m[i]);
 }
 
 /*
diff --git a/xen/arch/x86/mm/mm-locks.h b/xen/arch/x86/mm/mm-locks.h
index 086c8bb..4d17b0a 100644
--- a/xen/arch/x86/mm/mm-locks.h
+++ b/xen/arch/x86/mm/mm-locks.h
@@ -251,8 +251,8 @@ declare_mm_rwlock(p2m);
  */
 
 declare_mm_lock(altp2mlist)
-#define altp2m_list_lock(d)   mm_lock(altp2mlist, &(d)->arch.altp2m_list_lock)
-#define altp2m_list_unlock(d) mm_unlock(&(d)->arch.altp2m_list_lock)
+#define altp2m_list_lock(d)   mm_lock(altp2mlist, 
&(d)->arch.altp2m->altp2m_list_lock)
+#define altp2m_list_unlock(d) mm_unlock(&(d)->arch.altp2m->altp2m_list_lock)
 
 /* P2M lock (per-altp2m-table)
  *
diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index 8247a02..74b2754 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -1331,14 +1331,14 @@ void setup_ept_dump(void)
 
 void p2m_init_altp2m_ept_helper( struct domain *d, unsigned int i)
 {
-struct p2m_domain *p2m = d->arch.altp2m_p2m[i];
+struct p2m_domain *p2m = d->arch.altp2m->altp2m_p2m[i];
 struct ept_data *ept;
 
 p2m->min_remapped_gfn = gfn_x(INVALID_GFN);
-p2m->max_remapped_gfn = 0;
+p2m->max_remapped_gfn = gfn_x(_gfn(0UL));
 ept = >ept;
 ept->asr = pagetable_get_pfn(p2m_get_pagetable(p2m));
-d->arch.altp2m_eptp[i] = 

[Xen-devel] [PATCH v2 Altp2m cleanup v3 0/3] Cleaning up altp2m code

[Paul Lai]

Incorporating comments from v1 altp2m clean code URLs:
   https://lists.xenproject.org/archives/html/xen-devel/2016-06/msg03223.html
   https://lists.xenproject.org/archives/html/xen-devel/2016-06/msg03465.html
   https://lists.xenproject.org/archives/html/xen-devel/2016-06/msg03467.html

Older comments, reason for the code clean effort, are the following URLs:
   https://lists.xenproject.org/archives/html/xen-devel/2015-07/msg04323.html
   https://lists.xenproject.org/archives/html/xen-devel/2015-07/msg04454.html
   https://lists.xenproject.org/archives/html/xen-devel/2015-07/msg04530.html

Paul Lai (3):
  altp2m cleanup work
  Move altp2m specific functions to altp2m files.
  Making altp2m struct dynamically allocated.

 xen/arch/x86/hvm/hvm.c|  54 +---
 xen/arch/x86/hvm/vmx/vmx.c|   2 +-
 xen/arch/x86/mm/altp2m.c  |  45 +
 xen/arch/x86/mm/hap/hap.c |  35 ++---
 xen/arch/x86/mm/mm-locks.h|   4 +-
 xen/arch/x86/mm/p2m-ept.c |  39 ++
 xen/arch/x86/mm/p2m.c | 104 +-
 xen/common/monitor.c  |   1 +
 xen/include/asm-x86/altp2m.h  |  11 +++-
 xen/include/asm-x86/domain.h  |   6 +--
 xen/include/asm-x86/hvm/hvm.h |  19 +--
 xen/include/asm-x86/hvm/vmx/vmx.h |   3 ++
 xen/include/asm-x86/p2m.h |  18 ---
 13 files changed, 195 insertions(+), 146 deletions(-)

-- 
2.7.4


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

Re: [Xen-devel] [PATCH v2] x86/PV: don't wrongly hide/expose CPUID.OSXSAVE from/to user mode

[Andrew Cooper]

On 19/08/16 13:53, Jan Beulich wrote:
> User mode code generally cannot be expected to invoke the PV-enabled
> CPUID Xen supports, and prior to the CPUID levelling changes for 4.7
> (as well as even nowadays on levelling incapable hardware) such CPUID
> invocations actually saw the host CR4.OSXSAVE value, whereas prior to
> this patch
> - on Intel guest user mode always saw the flag clear,
> - on AMD guest user mode saw the flag set even when the guest kernel
>   didn't enable use of XSAVE/XRSTOR.
> Fold in the guest view of CR4.OSXSAVE when setting the levelling MSRs,
> just like we do in other CPUID handling.
>
> To make guest CR4 changes immediately visible via CPUID, also invoke
> ctxt_switch_levelling() from the CR4 write path.
>
> Signed-off-by: Jan Beulich 

I have just rerun a more thorough test, and I clearly got some incorrect
conclusions to start with.

(XEN) '1' pressed -> Extreme debugging in progress...
(XEN) Testing OSXSAVE
(XEN) ** CR4[-], MSR[-], cpuid 0
(XEN) ** CR4[+], MSR[-], cpuid 0
(XEN) ** CR4[-], MSR[+], cpuid 0
(XEN) ** CR4[+], MSR[+], cpuid 1
(XEN) '2' pressed -> Extreme debugging in progress...
(XEN) Testing APIC
(XEN) ** APIC[-], MSR[-], cpuid 0
(XEN) ** APIC[+], MSR[-], cpuid 0
(XEN) ** APIC[-], MSR[+], cpuid 0
(XEN) ** APIC[+], MSR[+], cpuid 1
(XEN) Watchdog timer detects that CPU21 is stuck!
... (an IPI hitting this core while the APIC is hard disabled appears to
get ignored, and other cores get unhappy)

So on this Sandy Bridge box does match your observation of behaviour,
and that masks are applied after fast-forwarded state.  I am rerunning
on other hardware to see how they behave.

~Andrew

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

Re: [Xen-devel] [GIT PULL] (xen) stable/for-jens-4.8-for-linus to your 'for-linus' branch for v4.8-rc3

[Jens Axboe]

On 08/19/2016 10:48 AM, Konrad Rzeszutek Wilk wrote:

Hey Jens!

Please git pull the following three fixes in to your 'for-linus' branch.
It is against 'for-linus' instead of 'for-4.8/drivers' because we had some
code in xen-blkfront go through the Xen tree (with your Ack). The reason
was that you 'for-4.8/drivers' was based on 4.7-rc2, and the fixes needed
to be against newer tag.

Anyhow, if you could please git pull the following branch:

 git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git 
stable/for-jens-4.8-for-linus

which has fixes as we are exercising the multiqueue components more 
aggressively.

Here is the diffstat:

 drivers/block/xen-blkfront.c | 97 +---
 1 file changed, 56 insertions(+), 41 deletions(-)

Bob Liu (3):
  xen-blkfront: fix places not updated after introducing 64KB page 
granularity
  xen-blkfront: introduce blkif_set_queue_limits()
  xen-blkfront: free resources if xlvbd_alloc_gendisk fails


Pulled, thanks.

--
Jens Axboe

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

Re: [Xen-devel] [PATCH 2/2] xen/Kconfig: Misc tweaks

[Doug Goldstein]

On 8/19/16 11:14 AM, Jan Beulich wrote:
>  >>> On 19.08.16 at 17:54,  wrote:
>> * Drop one piece of trailing whitespace
>>  * Reposition LATE_HWDOM so it sits properly nested inside XSM in menuconfig
>>  * Spelling and grammar corrections
>>
>> Signed-off-by: Andrew Cooper 
> 
> Acked-by: Jan Beulich 
> with one question:
> 
>> @@ -141,7 +121,7 @@ config XSM_POLICY
>>  depends on XSM
>>  ---help---
>>This includes a default XSM policy in the hypervisor so that the
>> -  bootloader does not need to load a policy to get sane behavior from an
>> +  bootloader does not need to load a policy to get sane behaviour from 
>> an
> 
> Isn't the original spelling valid in American English?
> 
> Jan
> 

Yes. An American English speaker wrote it originally as well. Spelling
and grammatical changes to what I write are always welcome.

Reviewed-by: Doug Goldstein 

-- 
Doug Goldstein



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

[Xen-devel] [GIT PULL] (xen) stable/for-jens-4.8-for-linus to your 'for-linus' branch for v4.8-rc3

[Konrad Rzeszutek Wilk]

Hey Jens!

Please git pull the following three fixes in to your 'for-linus' branch.
It is against 'for-linus' instead of 'for-4.8/drivers' because we had some
code in xen-blkfront go through the Xen tree (with your Ack). The reason
was that you 'for-4.8/drivers' was based on 4.7-rc2, and the fixes needed
to be against newer tag.

Anyhow, if you could please git pull the following branch:
 
 git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git 
stable/for-jens-4.8-for-linus

which has fixes as we are exercising the multiqueue components more 
aggressively.

Here is the diffstat:

 drivers/block/xen-blkfront.c | 97 +---
 1 file changed, 56 insertions(+), 41 deletions(-)

Bob Liu (3):
  xen-blkfront: fix places not updated after introducing 64KB page 
granularity
  xen-blkfront: introduce blkif_set_queue_limits()
  xen-blkfront: free resources if xlvbd_alloc_gendisk fails


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

[Xen-devel] [PATCH v3] xen: credit1: fix a race when picking initial pCPU for a vCPU

[Dario Faggioli]

In the Credit1 hunk of 9f358ddd69463 ("xen: Have
schedulers revise initial placement") csched_cpu_pick()
is called without taking the runqueue lock of the
(temporary) pCPU that the vCPU has been assigned to
(e.g., in XEN_DOMCTL_max_vcpus).

However, although 'hidden' in the IS_RUNQ_IDLE() macro,
that function does access the runq (for doing load
balancing calculations). Two scenarios are possible:
 1) we are on cpu X, and IS_RUNQ_IDLE() peeks at cpu's
X own runq;
 2) we are on cpu X, but IS_RUNQ_IDLE() peeks at some
other cpu's runq.

Scenario 2) absolutely requies that the appropriate
runq lock is taken. Scenario 1) works even without
taking the cpu's own runq lock. That is actually what
happens when when _csched_pick_cpu() is called from
csched_vcpu_acct() (in turn, called by csched_tick()).

Races have been observed and reported (by both XenServer
own testing and OSSTest [1]), in the form of
IS_RUNQ_IDLE() falling over LIST_POISON, because we're
not currently holding the proper lock, in
csched_vcpu_insert(), when scenario 1) occurs.

However, for better robustness, from now on we always
ask for the proper runq lock to be held when calling
IS_RUNQ_IDLE() (which is also becoming a static inline
function instead of macro).

In order to comply with that, we take the lock around
the call to _csched_cpu_pick() in csched_vcpu_acct().

[1] https://lists.xen.org/archives/html/xen-devel/2016-08/msg02144.html

Reported-by: Andrew Cooper 
Signed-off-by: Dario Faggioli 
---
Cc: George Dunlap 
Cc: Andrew Cooper 
Cc: Jan Beulich 
---
Changes from v2:
 - actually, take the runq lock around the call to _csched_cpu_pick() in
   csched_vcpu_acct(), as considered better by George during review.

Changes from v1:
 - macro IS_RUNQ_IDLE() to static inline is_runq_idle(), as suggested
   during review;
 - add an ASSERT() and a comment, as suggested during review;
 - take into account what's described in the changelog as "scenario 1)",
   which wasn't being considered in v1.
---
 xen/common/sched_credit.c |   53 +
 1 file changed, 39 insertions(+), 14 deletions(-)

diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
index 220ff0d..c2b4b24 100644
--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -84,9 +84,6 @@
 #define CSCHED_VCPU(_vcpu)  ((struct csched_vcpu *) (_vcpu)->sched_priv)
 #define CSCHED_DOM(_dom)((struct csched_dom *) (_dom)->sched_priv)
 #define RUNQ(_cpu)  (&(CSCHED_PCPU(_cpu)->runq))
-/* Is the first element of _cpu's runq its idle vcpu? */
-#define IS_RUNQ_IDLE(_cpu)  (list_empty(RUNQ(_cpu)) || \
- is_idle_vcpu(__runq_elem(RUNQ(_cpu)->next)->vcpu))
 
 
 /*
@@ -248,6 +245,18 @@ __runq_elem(struct list_head *elem)
 return list_entry(elem, struct csched_vcpu, runq_elem);
 }
 
+/* Is the first element of cpu's runq (if any) cpu's idle vcpu? */
+static inline bool_t is_runq_idle(unsigned int cpu)
+{
+/*
+ * We're peeking at cpu's runq, we must hold the proper lock.
+ */
+ASSERT(spin_is_locked(per_cpu(schedule_data, cpu).schedule_lock));
+
+return list_empty(RUNQ(cpu)) ||
+   is_idle_vcpu(__runq_elem(RUNQ(cpu)->next)->vcpu);
+}
+
 static inline void
 __runq_insert(struct csched_vcpu *svc)
 {
@@ -771,7 +780,7 @@ _csched_cpu_pick(const struct scheduler *ops, struct vcpu 
*vc, bool_t commit)
  * runnable vcpu on cpu, we add cpu to the idlers.
  */
 cpumask_and(, _online_map, CSCHED_PRIV(ops)->idlers);
-if ( vc->processor == cpu && IS_RUNQ_IDLE(cpu) )
+if ( vc->processor == cpu && is_runq_idle(cpu) )
 __cpumask_set_cpu(cpu, );
 cpumask_and(, , );
 
@@ -951,21 +960,33 @@ csched_vcpu_acct(struct csched_private *prv, unsigned int 
cpu)
 /*
  * Put this VCPU and domain back on the active list if it was
  * idling.
- *
- * If it's been active a while, check if we'd be better off
- * migrating it to run elsewhere (see multi-core and multi-thread
- * support in csched_cpu_pick()).
  */
 if ( list_empty(>active_vcpu_elem) )
 {
 __csched_vcpu_acct_start(prv, svc);
 }
-else if ( _csched_cpu_pick(ops, current, 0) != cpu )
+else
 {
-SCHED_VCPU_STAT_CRANK(svc, migrate_r);
-SCHED_STAT_CRANK(migrate_running);
-set_bit(_VPF_migrating, >pause_flags);
-cpu_raise_softirq(cpu, SCHEDULE_SOFTIRQ);
+unsigned int new_cpu;
+unsigned long flags;
+spinlock_t *lock = vcpu_schedule_lock_irqsave(current, );
+
+/*
+ * If it's been active a while, check if we'd be better off
+ * migrating it to run elsewhere (see multi-core and multi-thread
+ * support in csched_cpu_pick()).
+ */
+new_cpu = _csched_cpu_pick(ops, current, 0);
+
+

Re: [Xen-devel] Save/Restore is not working properly

[Cendrin Sa]

Hi again,
So save/restore has a bug or not? I still have problem with it when i use
LVM.

On Sat, Aug 13, 2016 at 11:10 AM, Cendrin Sa  wrote:

> I used save without any option when my VM was in running state, save won't
> work if I pause a VM.
>
>
> On Sat, Aug 13, 2016 at 11:04 AM, Cendrin Sa  wrote:
>
>>
>>- I'm using Xen unstable 4.8 manually compiled on debian , I create a
>>debian netinst guest using the following config file and then just use
>>save/restore, after restoring a machine *kernel hangout task happens*.
>>
>>
>>- We've test it With Xen 4.7  manually compiled on ubuntu 14.04 and
>>the same thing happened. the guest VM was ubuntu 14.04 with GUI, after
>>restoring we were able to move the mouse but the VM was crashed.
>>
>>
>>- Also, the same *kernel hangout task *happened on CentOS (also its
>>kernel is 2.6...) and with Xen 4.2.
>>
>> These is important to note that after creating VMs using a raw image file
>> created with both "qemu-img" and "dd" the problem solved and save/restore
>> is working properly.
>> It seems there is a problem related to LVM.
>>
>>
>>1.
>>2. builder = "hvm"
>>3. memory = 1024
>>4. vcpus = 2
>>5. name = "debian64"
>>6. vif = [ 'bridge=xenbr0' ]
>>7. disk = [
>>8. 'file:/dev/vg0/debian64_clone.img,xvda,rw',
>>9. 
>> 'file:/home/lisbeth/src/debian-8.5.0-amd64-netinst.iso,xvdc:cdrom,r'
>>10.]
>>11.
>>12. boot = "c"
>>
>>
>> On Thu, Aug 11, 2016 at 7:48 PM, Wei Liu  wrote:
>>
>>> On Wed, Aug 10, 2016 at 02:24:09PM +0100, George Dunlap wrote:
>>> > On Wed, Aug 10, 2016 at 12:11 PM, Roger Pau Monné <
>>> roger@citrix.com> wrote:
>>> > > On Sun, Aug 07, 2016 at 07:51:14PM +0430, Cendrin Sa wrote:
>>> > >> Hi,
>>> > >> I was searching a way to clone a machine using both memory and disk
>>> > >> approach.
>>> > >> I checked xen save/restore but after restoring, I can only work some
>>> > >> seconds with my machine and it will crash with
>>> the_kernel_task_hang_up.
>>> > >> using an script* to clone a machine is not working either.
>>> > >> so is it a bug or something or I'm cloning the wrong way?
>>> > >
>>> > > Hello,
>>> > >
>>> > > I've not tried to perform cloning myself, but I have a little script
>>> to
>>> > > perform VM checkpoints (so that you can restore the VM to any given
>>> point in
>>> > > time). It's based on FreeBSD so it uses ZFS, but it should work with
>>> LVM
>>> > > also if you replace it with the appropriate runes. AFAICT it should
>>> be quite
>>> > > easy to expand it to also do VM cloning. This is transparent from a
>>> VM point
>>> > > of view.
>>> >
>>> > FWIW on a recent version of Xen-unstable, "xl save -c" appears to be
>>> > broken, at least with me CentOS 6 VM.  If I do "xl save" then "xl
>>> > restore", everything works fine; but if I do "xl save -c", then the
>>> > save appears to work as normal, and after it's done the guest console
>>> > has output similar to the output it has when restoring, but processes
>>> > which access the disk hang, and in 2 minutes I get "hung process"
>>> > output as Cendrin described.
>>> >
>>> > I do get some warning messages though:
>>> >
>>> > Using NULL legacy PIC
>>> > WARNING: g.e. still in use!
>>> > WARNING: leaking g.e. and page still in use!
>>> > WARNING: g.e. still in use!
>>> > WARNING: leaking g.e. and page still in use!
>>> > WARNING: g.e. still in use!
>>> > WARNING: leaking g.e. and page still in use!
>>> > Changing capacity of (202, 0) to 4194288 sectors
>>> >
>>> > This is the stock CentOS 6.6 kernel: 2.6.32-504.16.2.el6.x86_64
>>> >
>>>
>>> It looks like the guest kernel is trying to free up all the grant
>>> references.
>>>
>>> In the case of xl save -c my impression is that it shouldn't be doing
>>> that because the suspend is supposed to be canceled from guest's PoV.
>>>
>>> See comment in xenctrl.h for xc_domain_resume.
>>>
>>> Also related: 8903a7a5f6a47cc40c1c204a1cc28b0030b04486
>>>
>>> Wei.
>>>
>>> >  -George
>>>
>>
>>
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 2/2] x86/EFI: use less crude way of generating the build ID

[Konrad Rzeszutek Wilk]

On Mon, Aug 15, 2016 at 10:15:47AM -0400, Konrad Rzeszutek Wilk wrote:
> On Mon, Aug 15, 2016 at 01:58:47AM -0600, Jan Beulich wrote:
> > >>> On 15.08.16 at 01:42,  wrote:
> > >> --- a/xen/arch/x86/efi/Makefile
> > >> +++ b/xen/arch/x86/efi/Makefile
> > >> @@ -9,6 +9,9 @@ efi := $(if $(efi),$(shell $(CC) $(filte
> > >>  efi := $(if $(efi),$(shell $(LD) -mi386pep --subsystem=10 -o check.efi 
> > >> check.o 2>disabled && echo y))
> > >>  efi := $(if $(efi),$(shell rm disabled)y,$(shell $(call 
> > >> create,boot.init.o); $(call create,runtime.o)))
> > >>  
> > >> -extra-$(efi) += boot.init.o relocs-dummy.o runtime.o compat.o
> > >> +extra-$(efi) += boot.init.o relocs-dummy.o runtime.o compat.o buildid.o
> > >> +
> > >> +%.o: %.ihex
> > >> +$(OBJCOPY) -I ihex -O binary $< $@
> > > 
> > > 
> > > Under  Ubuntu 14.04.4 this fails compilation:
> > > 
> > > 
> > > make[4]: *** No rule to make target `buildid.o', needed by `stub.o'.
> > 
> > That's extremely odd, namely considering that the rule is right
> > there in the quoted text above. Could you double check
> > xen/arch/x86/efi/buildid.ihex is actually there?
> 
> 
> No it is not. I had issues with your email (git am -s) so I did it by
> hand (patch -p2) and of course forgot to include the new file. And later
> on built it on another OS after pulling from a git tree which missed this 
> file.
> 
> Sorry about the false report!

About the review:

> 
> x86/EFI: use less crude way of generating the build ID
> 
> Recent enough binutils support --build-id also for COFF/PE output, and
> hence we should use that in favor of the original hack when possible.

Could you mention the exact version that gained this?

> 
> This gets complicated by the linker requiring at least one COFF object
> file to attach the .buildid section to. Hence the patch introduces a

Is that requirement spelled out in the manpage of the linker?

> buildid.ihex (in order to avoid introducing binary files into the repo)
> which then gets converted to a binary minimal COFF object (no sections,
> no symbols).

Otherwise:

Reviewed-by: Konrad Rzeszutek Wilk 

Thanks!

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

Re: [Xen-devel] [PATCH 2/2] xen/Kconfig: Misc tweaks

[Jan Beulich]

 >>> On 19.08.16 at 17:54,  wrote:
> * Drop one piece of trailing whitespace
>  * Reposition LATE_HWDOM so it sits properly nested inside XSM in menuconfig
>  * Spelling and grammar corrections
> 
> Signed-off-by: Andrew Cooper 

Acked-by: Jan Beulich 
with one question:

> @@ -141,7 +121,7 @@ config XSM_POLICY
>   depends on XSM
>   ---help---
> This includes a default XSM policy in the hypervisor so that the
> -   bootloader does not need to load a policy to get sane behavior from an
> +   bootloader does not need to load a policy to get sane behaviour from 
> an

Isn't the original spelling valid in American English?

Jan


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

Re: [Xen-devel] [PATCH 1/2] xen/Kconfig: Drop redundant comments from Kconfig files

[Jan Beulich]

>>> On 19.08.16 at 17:54,  wrote:
> Most of the comments are duplicated from the help text, and those without help
> provide no useful additional input.
> 
> Signed-off-by: Andrew Cooper 

Non-ARM parts
Acked-by: Jan Beulich 

albeit being known to rather comment too little I think that shouldn't
be taken to count too much, i.e. waiting for some further one would
probably not be a bad idea.

Jan


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

Re: [Xen-devel] [PATCH v2 2/2] xen/physmap: Do not permit a guest to populate PoD pages for itself

[Jan Beulich]

>>> On 19.08.16 at 18:00,  wrote:
> PoD is supposed to be entirely transparent to guest, but this interface has
> been left exposed for a long time.
> 
> The use of PoD requires careful co-ordination by the toolstack with the
> XENMEM_{get,set}_pod_target hypercalls, and xenstore ballooning target.  The
> best a guest can do without toolstack cooperation crash.
> 
> Furthermore, there are combinations of features (e.g. c/s c63868ff "libxl:
> disallow PCI device assignment for HVM guest when PoD is enabled") which a
> toolstack might wish to explicitly prohibit (in this case, because the two
> simply don't function in combination).  In such cases, the guest mustn't be
> able to subvert the configuration chosen by the toolstack.
> 
> Signed-off-by: Andrew Cooper 

Acked-by: Jan Beulich 


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

[Xen-devel] [PATCH 1/2] xen/Kconfig: Drop redundant comments from Kconfig files

[Andrew Cooper]

Most of the comments are duplicated from the help text, and those without help
provide no useful additional input.

Signed-off-by: Andrew Cooper 
---
CC: Doug Goldstein 
CC: Jan Beulich 
CC: Stefano Stabellini 
CC: Julien Grall 
---
 xen/arch/arm/Kconfig|  3 ---
 xen/common/Kconfig  | 14 --
 xen/drivers/acpi/Kconfig|  1 -
 xen/drivers/char/Kconfig|  7 ---
 xen/drivers/cpufreq/Kconfig |  1 -
 xen/drivers/passthrough/Kconfig |  1 -
 xen/drivers/pci/Kconfig |  1 -
 xen/drivers/video/Kconfig   |  3 ---
 8 files changed, 31 deletions(-)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 871c243..797c91f 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -1,4 +1,3 @@
-# Select 32 or 64 bit
 config 64BIT
bool
default ARCH != "arm32"
@@ -43,11 +42,9 @@ config ACPI
  Advanced Configuration and Power Interface (ACPI) support for Xen is
  an alternative to device tree on ARM64.
 
-# Select HAS_GICV3 if GICv3 is supported
 config HAS_GICV3
bool
 
-# Select ALTERNATIVE if the architecture supports runtime patching
 config ALTERNATIVE
bool
 
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index befa30e..b2d3d61 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -11,31 +11,24 @@ config COMPAT
 config CORE_PARKING
bool
 
-# Select HAS_DEVICE_TREE if device tree is supported
 config HAS_DEVICE_TREE
bool
 
-# Select HAS_MEM_ACCESS if mem access is supported
 config HAS_MEM_ACCESS
bool
 
-# Select HAS_MEM_PAGING if mem paging is supported
 config HAS_MEM_PAGING
bool
 
-# Select HAS_MEM_SHARING if mem sharing is supported
 config HAS_MEM_SHARING
bool
 
-# Select HAS_PDX if PDX is supported
 config HAS_PDX
bool
 
-# Select HAS_KEXEC if kexec is supported
 config HAS_KEXEC
bool
 
-# Select HAS_GDBSX if GDBSX is supported
 config HAS_GDBSX
bool
 
@@ -50,7 +43,6 @@ config HAS_CHECKPOLICY
string
option env="XEN_HAS_CHECKPOLICY"
 
-# Enable/Disable kexec support
 config KEXEC
bool "kexec support"
default y
@@ -62,7 +54,6 @@ config KEXEC
 
  If unsure, say Y.
 
-# Allows "late" initialization of the hardware domain
 config LATE_HWDOM
bool "dedicated hardware domain"
default n
@@ -83,7 +74,6 @@ config LATE_HWDOM
 
  If unsure, say N.
 
-# Enables transcendent memory support
 config TMEM
def_bool y
prompt "Transcendent Memory Support" if EXPERT = "y"
@@ -97,7 +87,6 @@ config TMEM
 
  If unsure, say Y.
 
-# Adds support for Xenoprof
 config XENOPROF
def_bool y
prompt "Xen Oprofile Support" if EXPERT = "y"
@@ -110,7 +99,6 @@ config XENOPROF
 
  If unsure, say Y.
 
-# Enable/Disable XSM support
 config XSM
bool "Xen Security Modules support"
default n
@@ -163,7 +151,6 @@ config XSM_POLICY
 
  If unsure, say Y.
 
-# Enable schedulers
 menu "Schedulers"
visible if EXPERT = "y"
 
@@ -221,7 +208,6 @@ endmenu
 config CRYPTO
bool
 
-# Enable/Disable live patching support
 config LIVEPATCH
bool "Live patching support (TECH PREVIEW)"
default n
diff --git a/xen/drivers/acpi/Kconfig b/xen/drivers/acpi/Kconfig
index 1074dbf..b64d373 100644
--- a/xen/drivers/acpi/Kconfig
+++ b/xen/drivers/acpi/Kconfig
@@ -1,5 +1,4 @@
 
-# Select ACPI if ACPI is supported
 config ACPI
bool
 
diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
index 08973cf..51343d0 100644
--- a/xen/drivers/char/Kconfig
+++ b/xen/drivers/char/Kconfig
@@ -1,11 +1,9 @@
-#  16550-series UART support
 config HAS_NS16550
bool
default y
help
  This selects the 16550-series UART support. For most systems, say Y.
 
-# Xilinx Zynq Cadence UART support
 config HAS_CADENCE_UART
bool
default y
@@ -14,7 +12,6 @@ config HAS_CADENCE_UART
  This selects the Xilinx Zynq Cadence UART. If you have a Xilinx Zynq
  based board, say Y.
 
-# ARM AMBA PL011 UART support
 config HAS_PL011
bool
default y
@@ -23,7 +20,6 @@ config HAS_PL011
  This selects the ARM(R) AMBA(R) PrimeCell PL011 UART. If you have
  an Integrator/PP2, Integrator/CP or Versatile platform, say Y.
 
-# Samsung Exynos 4210 UART support
 config HAS_EXYNOS4210
bool
default y
@@ -32,7 +28,6 @@ config HAS_EXYNOS4210
  This selects the Samsung Exynos 4210 UART. If you have a Samsung
  Exynos based board, say Y.
 
-# OMAP UART support
 config HAS_OMAP
bool
default y
@@ -41,7 +36,6 @@ config HAS_OMAP
  This selects the Texas Instruments OMAP UART. If you have a Texas
  Instruments based CPU, say Y.
 
-# SuperH SCI(F) UART support
 config HAS_SCIF
bool
default 

[Xen-devel] [PATCH v2 2/2] xen/physmap: Do not permit a guest to populate PoD pages for itself

[Andrew Cooper]

PoD is supposed to be entirely transparent to guest, but this interface has
been left exposed for a long time.

The use of PoD requires careful co-ordination by the toolstack with the
XENMEM_{get,set}_pod_target hypercalls, and xenstore ballooning target.  The
best a guest can do without toolstack cooperation crash.

Furthermore, there are combinations of features (e.g. c/s c63868ff "libxl:
disallow PCI device assignment for HVM guest when PoD is enabled") which a
toolstack might wish to explicitly prohibit (in this case, because the two
simply don't function in combination).  In such cases, the guest mustn't be
able to subvert the configuration chosen by the toolstack.

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

v2:
 * Move the exclusion logic into populate_physmap().  No functional change.
---
 xen/common/memory.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/xen/common/memory.c b/xen/common/memory.c
index 1ead35c..f34dd56 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -140,14 +140,14 @@ static void populate_physmap(struct memop_args *a)
 struct page_info *page;
 unsigned int i, j;
 xen_pfn_t gpfn, mfn;
-struct domain *d = a->domain;
+struct domain *d = a->domain, *curr_d = current->domain;
 
 if ( !guest_handle_subrange_okay(a->extent_list, a->nr_done,
  a->nr_extents-1) )
 return;
 
 if ( a->extent_order > (a->memflags & MEMF_populate_on_demand ? MAX_ORDER :
-max_order(current->domain)) )
+max_order(curr_d)) )
 return;
 
 for ( i = a->nr_done; i < a->nr_extents; i++ )
@@ -163,6 +163,10 @@ static void populate_physmap(struct memop_args *a)
 
 if ( a->memflags & MEMF_populate_on_demand )
 {
+/* Disallow populating PoD pages on oneself. */
+if ( d == curr_d )
+goto out;
+
 if ( guest_physmap_mark_populate_on_demand(d, gpfn,
a->extent_order) < 0 )
 goto out;
-- 
2.1.4


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

[Xen-devel] [PATCH 2/2] xen/Kconfig: Misc tweaks

[Andrew Cooper]

 * Drop one piece of trailing whitespace
 * Reposition LATE_HWDOM so it sits properly nested inside XSM in menuconfig
 * Spelling and grammar corrections

Signed-off-by: Andrew Cooper 
---
CC: Doug Goldstein 
CC: Jan Beulich 
---
 xen/common/Kconfig | 44 ++--
 1 file changed, 22 insertions(+), 22 deletions(-)

diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index b2d3d61..92d4610 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -54,26 +54,6 @@ config KEXEC
 
  If unsure, say Y.
 
-config LATE_HWDOM
-   bool "dedicated hardware domain"
-   default n
-   depends on XSM && X86
-   ---help---
- Allows the creation of a dedicated hardware domain distinct from
- domain 0 that manages devices without needing access to other
- privileged functionality such as the ability to manage domains.
- This requires that the actual domain 0 be a stub domain that
- constructs the actual hardware domain instead of initializing the
- hardware itself.  Because the hardware domain needs access to
- hypercalls not available to unprivileged guests, an XSM policy
- is required to properly define the privilege of these domains.
-
- This feature does nothing if the "hardware_dom" boot parameter is
- not present.  If this feature is being used for security, it should
- be combined with an IOMMU in strict mode.
-
- If unsure, say N.
-
 config TMEM
def_bool y
prompt "Transcendent Memory Support" if EXPERT = "y"
@@ -141,7 +121,7 @@ config XSM_POLICY
depends on XSM
---help---
  This includes a default XSM policy in the hypervisor so that the
- bootloader does not need to load a policy to get sane behavior from an
+ bootloader does not need to load a policy to get sane behaviour from 
an
  XSM-enabled hypervisor.  If this is disabled, a policy must be
  provided by the bootloader or by Domain 0.  Even if this is enabled, a
  policy provided by the bootloader will override it.
@@ -151,6 +131,26 @@ config XSM_POLICY
 
  If unsure, say Y.
 
+config LATE_HWDOM
+   bool "Dedicated hardware domain"
+   default n
+   depends on XSM && X86
+   ---help---
+ Allows the creation of a dedicated hardware domain distinct from
+ domain 0 that manages devices without needing access to other
+ privileged functionality such as the ability to manage domains.
+ This requires that the actual domain 0 be a stub domain that
+ constructs the actual hardware domain instead of initializing the
+ hardware itself.  Because the hardware domain needs access to
+ hypercalls not available to unprivileged guests, an XSM policy
+ is required to properly define the privilege of these domains.
+
+ This feature does nothing if the "hardware_dom" boot parameter is
+ not present.  If this feature is being used for security, it should
+ be combined with an IOMMU in strict mode.
+
+ If unsure, say N.
+
 menu "Schedulers"
visible if EXPERT = "y"
 
@@ -183,7 +183,7 @@ config SCHED_ARINC653
 
 choice
prompt "Default Scheduler?"
-   default SCHED_CREDIT_DEFAULT 
+   default SCHED_CREDIT_DEFAULT
 
config SCHED_CREDIT_DEFAULT
bool "Credit Scheduler" if SCHED_CREDIT
-- 
2.1.4


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 100551 pass in 
100557
 test-armhf-armhf-libvirt-raw  6 xen-boot   fail pass in 100551
 test-amd64-i386-xl-qemuu-debianhvm-amd64 14 guest-saverestore.2 fail pass in 
100551

Regressions which are regarded as allowable (not blocking):
 build-amd64-rumpuserxen   6 xen-buildfail  like 100551
 build-i386-rumpuserxen6 xen-buildfail  like 100551
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100551
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100551
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 100551
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100551
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 100551

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

version targeted for testing:
 xen  830f177d920bdb4fda4fcdcd3b8ac0928cb579fb
baseline version:
 xen  830f177d920bdb4fda4fcdcd3b8ac0928cb579fb

Last test of basis   100557  2016-08-19 08:30:41 Z0 days
Testing same since0  1970-01-01 00:00:00 Z 17032 days0 attempts

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 
100546
 test-armhf-armhf-xl-arndale   9 debian-install   fail REGR. vs. 100546

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds  6 xen-boot fail REGR. vs. 100546
 test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail REGR. vs. 100546
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100546
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100546

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

version targeted for testing:
 qemuu60c6b790fc5dc26418dca42a77bab925ca7bac60
baseline version:
 qemuu02b1ad881cbb1795029737a9077db60267dc0c6f

Last test of basis   100546  2016-08-18 15:18:29 Z1 days
Testing same since   100559  2016-08-19 10:42:44 Z0 days1 attempts


People who touched revisions under test:
  Michal Privoznik 
  Peter Maydell 

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

Re: [Xen-devel] XSA 154 and ISA region (640K -> 1MB) WB cache instead of UC

[Konrad Rzeszutek Wilk]

On Thu, Aug 18, 2016 at 04:35:44PM +0100, One Thousand Gnomes wrote:
> On Thu, 18 Aug 2016 05:12:54 -0600
> "Jan Beulich"  wrote:
> 
> > >>> On 18.08.16 at 12:16,  wrote:  
> > > On 18/08/16 11:06, Jan Beulich wrote:  
> > > On 17.08.16 at 22:32,  wrote:  
> > >>>Looking at the kernel it assumes that WB is ok for 640KB->1MB.
> > >>>The comment says:
> > >>>" /* Low ISA region is always mapped WB in page table. No need to 
> > >>> track   
> > > *"  
> > >> As per above it's not clear to me what this comment is backed by.  
> > > 
> > > This states what is in the pagetables.  Not the combined result with 
> > > MTRRs.
> > > 
> > > WB in the pagetables and WC/UB in the MTRRs is a legal combination which
> > > functions correctly.  
> > 
> > True, but then again - haven't I been told multiple times that Linux
> > nowadays prefers to run without using MTRRs?
> 
> The BIOS sets up the fixed MTRR registers for the 640K-1MB window. Those
> are separate to the variable range MTRR registers used for main memory
> with specific mappings for segments A000 to BFFF then C000-C7FF /
> C800-CFFF / etc up to .

OK, so BIOS-inherited.

Looking at the Intel SDM (figure 11-7), if the MTRR is UC for that, then 
having pagetables being either UC or WB are fine. Except Linux's use
of the quirk (is_untracked_pat_range) ends up always requesting WB.

And to combat the splat, the patch:


From 5209635f23786fb88cf0ce77719da8acda63bf65 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk 
Date: Fri, 19 Aug 2016 11:06:44 -0400
Subject: [PATCH] x86/xen: Add x86_platform.is_untracked_pat_range quirk to
 ignore ISA regions.

On x86 whenever VMAs are setup, the 'is_ISA_range quirk' (which this
patch re-implements) is used to figure whether to ignore the
requested PAT type and always use WB (see 'reserve_memtype').
Specifically it forces the WB type for any region in the ISA space.

From the Intel SDM, the combination of MTRR (UC, which is setup by
the BIOS) and PAT (UC or WB) for the ISA region ends up with the same
value - UC.

However on Xen, due to XSA 154 we enforce that mappings that _ANY_
pagetable entry to MMIO ranges MUST have the same the same cachability
mapping - and in this case we enforce UC.

Which means that with XSA 154 (and without this patch) any application
that maps /dev/mem to get SMBIOS information (like mcelog), and pokes
in the ISA region will not have an PTE set. That is due to
reserve_pfn_range returning -EINVAL which results in the PTE not being set.

[These are debug entries added in 'reserve_pfn_range']
mcelog:2471 0xf->0xf1000, req_type=write-back new_type=write-back
mcelog:2471 0xeb000->0xed000, req_type=write-back new_type=write-back

.. above are successfull ones, but:
mcelog:2471 0xeb000->0xed000, req_type=uncached new_type=uncached
[again, a debug one:]
mcelog:2471 want=uncached got=write-back strict 0x000eb000-0x000ecfff
mcelog:2471 map pfn expected mapping type uncached for [mem 
0x000eb000-0x000ecfff], got write-back
 [ cut here ]

 [] dump_stack+0x63/0x83
 [] warn_slowpath_common+0x95/0xe0
 [] warn_slowpath_null+0x1a/0x20
 [] untrack_pfn+0x93/0xc0
 [] unmap_single_vma+0xa9/0x100
 [] unmap_vmas+0x54/0xa0
 [] exit_mmap+0x9a/0x150
 [] mmput+0x73/0x110
 [] dup_mm+0x105/0x110
 [] copy_process+0x11ed/0x1240
 [] do_fork+0x79/0x280
 [] ? syscall_trace_enter_phase1+0x153/0x180
 [] SyS_clone+0x16/0x20
 [] system_call_fastpath+0x12/0x71

results in that splat.

The effective result of the function below is for 'reserver_memtype'
to ignore the result from 'x86_platform.is_untracked_pat_range' quirk.
Which means that the splat above does not happen.

Signed-off-by: Konrad Rzeszutek Wilk 
---
 arch/x86/xen/enlighten.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 8ffb089..3238d04 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -283,6 +283,27 @@ static void __init xen_banner(void)
   version >> 16, version & 0x, extra.extraversion,
   xen_feature(XENFEAT_mmu_pt_update_preserve_ad) ? " 
(preserve-AD)" : "");
 }
+
+/*
+ * On x86 whenever VMAs are setup, the 'is_ISA_range quirk' (which we
+ * re-implement below) is used to figure whether to ignore the
+ * requested PAT type and always use WB (see 'reserve_memtype').
+ *
+ * The combination of MTRR (UC) and PAT (UC or WB) for the ISA region ends
+ * up with the same value - UC.
+ *
+ * However on Xen, due to XSA 154 we enforce that mappings to _ANY_ MMIO
+ * range MUST have the same the same cachability mapping - and in this case
+ * we enforce UC for everything.
+ *
+ * The effective result of the function below is for 'reserver_memtype'
+ * to ignore the result from 'x86_platform.is_untracked_pat_range' quirk.
+ */
+static bool xen_ignore(u64 s, u64 e)
+{
+   

Re: [Xen-devel] XSA 154 and ISA region (640K -> 1MB) WB cache instead of UC

[Jan Beulich]

>>> On 19.08.16 at 16:52,  wrote:
> On Thu, Aug 18, 2016 at 04:06:33AM -0600, Jan Beulich wrote:
>> >>> On 17.08.16 at 22:32,  wrote:
>> >Looking at the kernel it assumes that WB is ok for 640KB->1MB.
>> >The comment says:
>> >" /* Low ISA region is always mapped WB in page table. No need to track 
>> > *"
>> 
>> As per above it's not clear to me what this comment is backed by.
> 
> I was hoping you would know :-)
> 
> Ah, commit 2e5d9c857d4e6c9e7b7d8c8c86a68a7842d213d6
> Author: venkatesh.pallip...@intel.com 
> Date:   Tue Mar 18 17:00:14 2008 -0700
> 
> x86: PAT infrastructure patch
> 
> Sets up pat_init() infrastructure.
> 
> 
> which sets the MTRR for that region.

Hmm, that's the commit which introduced pat.c years ago. I can't
see it writing an MTRRs though, nor can I see it backing the comment
in adds in any way. I guess I'm confused...

Jan


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

Re: [Xen-devel] [PATCH 2/2] xen/physmap: Do not permit a guest to populate PoD pages for itself

[Jan Beulich]

>>> On 19.08.16 at 17:02,  wrote:
> On 19/08/16 15:58, Jan Beulich wrote:
> On 19.08.16 at 16:12,  wrote:
>>> --- a/xen/common/memory.c
>>> +++ b/xen/common/memory.c
>>> @@ -903,7 +903,16 @@ long do_memory_op(unsigned long cmd, 
> XEN_GUEST_HANDLE_PARAM(void) arg)
>>>  
>>>  if ( op == XENMEM_populate_physmap
>>>   && (reservation.mem_flags & XENMEMF_populate_on_demand) )
>>> +{
>>> +/* Disallow populating PoD pages on oneself. */
>>> +if ( d == curr_d )
>>> +{
>>> +rcu_unlock_domain(d);
>>> +return start_extent;
>>> +}
>>> +
>>>  args.memflags |= MEMF_populate_on_demand;
>>> +}
>>>  
>>>  if ( xsm_memory_adjust_reservation(XSM_TARGET, curr_d, d) )
>>>  {
>> Considering the code continues
>>
>> rcu_unlock_domain(d);
>> return start_extent;
>> }
>>
>> switch ( op )
>> {
>> case XENMEM_increase_reservation:
>> increase_reservation();
>> break;
>> case XENMEM_decrease_reservation:
>> decrease_reservation();
>> break;
>> default: /* XENMEM_populate_physmap */
>> populate_physmap();
>> break;
>> }
>>
>> I think it is time to move this XENMEM_populate_physmap specific
>> code chunk into populate_physmap(), at once eliminating the need
>> for another not entirely trivial error exit path here.
> 
> Do you mean just my code addition, or the whole if condition?  The
> former is easy, but the latter is hard as reservation is specifically
> not passed into populate_physmap().

Oh, I didn't realize that - just your addition then.

Jan


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

Re: [Xen-devel] [PATCH 2/2] xen/physmap: Do not permit a guest to populate PoD pages for itself

[Andrew Cooper]

On 19/08/16 15:58, Jan Beulich wrote:
 On 19.08.16 at 16:12,  wrote:
>> --- a/xen/common/memory.c
>> +++ b/xen/common/memory.c
>> @@ -903,7 +903,16 @@ long do_memory_op(unsigned long cmd, 
>> XEN_GUEST_HANDLE_PARAM(void) arg)
>>  
>>  if ( op == XENMEM_populate_physmap
>>   && (reservation.mem_flags & XENMEMF_populate_on_demand) )
>> +{
>> +/* Disallow populating PoD pages on oneself. */
>> +if ( d == curr_d )
>> +{
>> +rcu_unlock_domain(d);
>> +return start_extent;
>> +}
>> +
>>  args.memflags |= MEMF_populate_on_demand;
>> +}
>>  
>>  if ( xsm_memory_adjust_reservation(XSM_TARGET, curr_d, d) )
>>  {
> Considering the code continues
>
> rcu_unlock_domain(d);
> return start_extent;
> }
>
> switch ( op )
> {
> case XENMEM_increase_reservation:
> increase_reservation();
> break;
> case XENMEM_decrease_reservation:
> decrease_reservation();
> break;
> default: /* XENMEM_populate_physmap */
> populate_physmap();
> break;
> }
>
> I think it is time to move this XENMEM_populate_physmap specific
> code chunk into populate_physmap(), at once eliminating the need
> for another not entirely trivial error exit path here.

Do you mean just my code addition, or the whole if condition?  The
former is easy, but the latter is hard as reservation is specifically
not passed into populate_physmap().

~Andrew

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

Re: [Xen-devel] XSA 154 and ISA region (640K -> 1MB) WB cache instead of UC

[Konrad Rzeszutek Wilk]

On Thu, Aug 18, 2016 at 04:06:33AM -0600, Jan Beulich wrote:
> >>> On 17.08.16 at 22:32,  wrote:
> > One of the interesting things about XSA 154 fix ("x86: enforce consistent
> > cachability of MMIO mappings") is that when certain applications (mcelog)
> > are trying to map /dev/mmap and lurk in ISA regions - we get:
> 
> DYM /dev/mem ? Most accesses to which are bogus in PV guests
> (often including Dom0) anyway.

Yes.
> 
> > [   49.399053] WARNING: CPU: 0 PID: 2471 at arch/x86/mm/pat.c:913 
> > untrack_pfn+0x93/0xc0()
> 
> What Linux version is this? untrack_pfn() doesn't span line 913 in

4.1
> 4.8-rc2. And follow_phys() appears to only check whether the write
> flag is set as expected; I can't see any cachability checks. Plus it
> gets called only when both incoming address and size are zero.

The error that happens is much sooner - that is when the VMA is setup
with the incorrect page attributes. Specifically: reserve_memtype which

 548 /* Low ISA region is always mapped WB in page table. No need to 
track */
 549 if (x86_platform.is_untracked_pat_range(start, end)) { 
 
 550 if (new_type)  
 
 551 *new_type = _PAGE_CACHE_MODE_WB;   
 
 552 return 0;  
 
 553 }   

(And this for a change is v4.8-rc2)
> 
> > Anyhow what I am wondering:
> > 
> >  a) Should we add a edge case in the hypervisor to allow multiple mappings
> >for this region? I am thinking no.. but it sounds like mapping ISA region
> >as WB is safe even in baremetal?
> 
> We should never allow multiple mappings with different cachability.
> And I don't understand what makes you think the ISA region is safe
> to map WB? There might be ROMs, MMIO regions, or simply nothing
> there, neither of which is safe to map WB. ROMs certainly could be
> WP, but that would require a way to reliably size not only ISA
> extension ROMs, but also main and video BIOS.
> 
> >  b) Or would it be better to let Linux do its thing and treat 640KB->1MB
> >as uncached instead of writeback?
> 
> According to what you wrote earlier the two parts of the sentence
> read contradictory to me.
> 
> >Looking at the kernel it assumes that WB is ok for 640KB->1MB.
> >The comment says:
> >" /* Low ISA region is always mapped WB in page table. No need to track 
> > *"
> 
> As per above it's not clear to me what this comment is backed by.

I was hoping you would know :-)

Ah, commit 2e5d9c857d4e6c9e7b7d8c8c86a68a7842d213d6
Author: venkatesh.pallip...@intel.com 
Date:   Tue Mar 18 17:00:14 2008 -0700

x86: PAT infrastructure patch

Sets up pat_init() infrastructure.


which sets the MTRR for that region.
> 
> Jan
> 

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

Re: [Xen-devel] [PATCH 2/2] xen/physmap: Do not permit a guest to populate PoD pages for itself

[Jan Beulich]

>>> On 19.08.16 at 16:12,  wrote:
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -903,7 +903,16 @@ long do_memory_op(unsigned long cmd, 
> XEN_GUEST_HANDLE_PARAM(void) arg)
>  
>  if ( op == XENMEM_populate_physmap
>   && (reservation.mem_flags & XENMEMF_populate_on_demand) )
> +{
> +/* Disallow populating PoD pages on oneself. */
> +if ( d == curr_d )
> +{
> +rcu_unlock_domain(d);
> +return start_extent;
> +}
> +
>  args.memflags |= MEMF_populate_on_demand;
> +}
>  
>  if ( xsm_memory_adjust_reservation(XSM_TARGET, curr_d, d) )
>  {

Considering the code continues

rcu_unlock_domain(d);
return start_extent;
}

switch ( op )
{
case XENMEM_increase_reservation:
increase_reservation();
break;
case XENMEM_decrease_reservation:
decrease_reservation();
break;
default: /* XENMEM_populate_physmap */
populate_physmap();
break;
}

I think it is time to move this XENMEM_populate_physmap specific
code chunk into populate_physmap(), at once eliminating the need
for another not entirely trivial error exit path here.

Jan


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

Re: [Xen-devel] [PATCH 1/2] xen/memop: Latch current->domain in a local variable

[Jan Beulich]

>>> On 19.08.16 at 16:12,  wrote:
> It is more efficient.
> 
> Signed-off-by: Andrew Cooper 

Acked-by: Jan Beulich 


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

Re: [Xen-devel] [PATCH v8 05/13] libxl: Load guest BIOS from file

[Andrew Cooper]

On 18/08/16 15:13, Wei Liu wrote:
> From: Anthony PERARD 
>
> The path to the BIOS blob can be overriden by the xl's
> bios_path_override option, or provided by u.hvm.bios_firmware in the
> domain_build_info struct by other libxl user.
>
> Signed-off-by: Anthony PERARD 
> Acked-by: Wei Liu 

This introduces a regression, but I am not sure how best to fix it.

[root@xrtuk-09-12 xen-test-framework]# xl -vvv create -p
tests/selftest/test-hvm32-selftest.cfg
Parsing config from tests/selftest/test-hvm32-selftest.cfg
libxl: debug: libxl_create.c:1603:do_domain_create: ao 0xa6b9f0: create:
how=(nil) callback=(nil) poller=0xa6c120
libxl: debug: libxl_create.c:959:initiate_domain_create: running bootloader
libxl: debug: libxl_bootloader.c:324:libxl__bootloader_run: not a PV
domain, skipping bootloader
libxl: debug: libxl_event.c:686:libxl__ev_xswatch_deregister: watch
w=0xa6cc30: deregister unregistered
libxl: debug: libxl_numa.c:483:libxl__get_numa_candidate: New best NUMA
placement candidate found: nr_nodes=1, nr_cpus=12, nr_vcpus=17,
free_memkb=30611
libxl: detail: libxl_dom.c:182:numa_place_domain: NUMA placement
candidate with 1 nodes, 12 cpus and 30611 KB free selected
domainbuilder: detail: xc_dom_allocate: cmdline="(null)", features="(null)"
domainbuilder: detail: xc_dom_kernel_file:
filename="/opt/xen-test-framework/tests/selftest/test-hvm32-selftest"
domainbuilder: detail: xc_dom_malloc_filemap: 1090 kB
libxl: debug: libxl_dom.c:874:libxl__load_hvm_firmware_module: Loading
BIOS: /usr/libexec/xen/boot/bios.bin
libxl: error: libxl_dom.c:882:libxl__load_hvm_firmware_module: failed to
read BIOS file: No such file or directory

In this case, tools have been built with ./configure --disable-seabios

As a result, /usr/libexec/xen/boot/bios.bin (name altered a patch sent
separately) isn't built or installed.

I think libxl needs to logic to determine which firmware to use based on
the available CONFIG_* options it was built with.

> @@ -914,6 +951,30 @@ static int libxl__domain_firmware(libxl__gc *gc,
>  goto out;
>  }
>  
> +if (info->device_model_version == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
> +if (info->u.hvm.system_firmware) {
> +bios_filename = info->u.hvm.system_firmware;
> +} else {
> +switch (info->u.hvm.bios) {
> +case LIBXL_BIOS_TYPE_SEABIOS:
> +bios_filename = libxl__seabios_path();
> +break;
> +case LIBXL_BIOS_TYPE_OVMF:
> +bios_filename = libxl__ovmf_path();
> +break;

At the very least, these need to be guarded by #ifdef
CONFIG_{SEABIOS,OVMF}, as it is explicitly permitted for them not to be
present in a build.

> +case LIBXL_BIOS_TYPE_ROMBIOS:

ROMBIOS certainly does function correctly with QEMU_XEN, and is how
XenServer is planning to start the migration from a qemu-trad world to a
qemu-upstream world.  Even if libxl doesn't want to formally support
such a configuration, it shouldn't be excluded.

> +default:
> +abort();

This is completely antisocial.  Under no circumstances is it ok for a
library to call abort(); fail an assertion if necessary, but this is a
configuration error and should pass an error back to its caller, not
take the entire process with it.

~Andrew

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

[Xen-devel] [PATCH] tools/firmware: Rename bios.bin to seabios.bin

[Andrew Cooper]

bios.bin as a name is far too generic.  Rename it to seabios.bin.

Signed-off-by: Andrew Cooper 
---
CC: Ian Jackson 
CC: Wei Liu 
CC: Anthony PERARD 

Please rerun autogen.sh
---
 tools/configure | 2 +-
 tools/configure.ac  | 2 +-
 tools/firmware/Makefile | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/configure b/tools/configure
index 81ccf34..dd82f67 100755
--- a/tools/configure
+++ b/tools/configure
@@ -4451,7 +4451,7 @@ fi
 
 
 cat >>confdefs.h <<_ACEOF
-#define SEABIOS_PATH "${seabios_path:-$XENFIRMWAREDIR/bios.bin}"
+#define SEABIOS_PATH "${seabios_path:-$XENFIRMWAREDIR/seabios.bin}"
 _ACEOF
 
 
diff --git a/tools/configure.ac b/tools/configure.ac
index c12ad79..06a6202 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -223,7 +223,7 @@ AC_ARG_WITH([system-seabios],
 esac
 ],[])
 AC_DEFINE_UNQUOTED([SEABIOS_PATH],
-   ["${seabios_path:-$XENFIRMWAREDIR/bios.bin}"],
+   ["${seabios_path:-$XENFIRMWAREDIR/seabios.bin}"],
[SeaBIOS path])
 
 AC_ARG_WITH([system-ovmf],
diff --git a/tools/firmware/Makefile b/tools/firmware/Makefile
index cf09ad2..b840c6a 100644
--- a/tools/firmware/Makefile
+++ b/tools/firmware/Makefile
@@ -42,7 +42,7 @@ install: all
[ -d $(INST_DIR) ] || $(INSTALL_DIR) $(INST_DIR)
[ ! -e $(TARGET) ] || $(INSTALL_DATA) $(TARGET) $(INST_DIR)
 ifeq ($(CONFIG_SEABIOS),y)
-   $(INSTALL_DATA) seabios-dir/out/bios.bin $(INST_DIR)/bios.bin
+   $(INSTALL_DATA) seabios-dir/out/bios.bin $(INST_DIR)/seabios.bin
 endif
 ifeq ($(CONFIG_OVMF),y)
$(INSTALL_DATA) ovmf-dir/ovmf.bin $(INST_DIR)/ovmf.bin
-- 
2.1.4


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