Re: [Xen-devel] [PATCH LIVEPATCH-BUILD-TOOLS] EFI build with -ffunction-sections fails.

[Ross Lagerwall]

On 07/13/2016 09:14 PM, Konrad Rzeszutek Wilk wrote:

When we build Xen with the Rules.mk modified we end up:


... snip


A bit of grepping showed that the issue is with:

 --section-alignment=0x20

which is used on the linker command line and this fix
replaces the --section-alignment to be 4KB which allows the build
to complete.

Signed-off-by: Konrad Rzeszutek Wilk 
---
 livepatch-build | 2 ++
 1 file changed, 2 insertions(+)



Reviewed-by: Ross Lagerwall 

--
Ross Lagerwall

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

[Xen-devel] [linux-4.1 test] 97279: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 
96211
 test-amd64-i386-xl-qemuu-winxpsp3  9 windows-install  fail REGR. vs. 96211
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. 
vs. 96211
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
REGR. vs. 96211
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. 
vs. 96211
 test-amd64-i386-xl-xsm9 debian-installfail REGR. vs. 96211
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 windows-install fail REGR. vs. 96211
 test-amd64-i386-libvirt   9 debian-installfail REGR. vs. 96211
 test-amd64-i386-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 
96211
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail REGR. vs. 96211
 test-amd64-i386-qemut-rhel6hvm-amd  9 redhat-install  fail REGR. vs. 96211
 test-amd64-i386-xl-raw9 debian-di-install fail REGR. vs. 96211
 test-amd64-i386-freebsd10-amd64  9 freebsd-installfail REGR. vs. 96211
 test-amd64-i386-libvirt-xsm   9 debian-installfail REGR. vs. 96211
 test-amd64-i386-xl-qemut-winxpsp3  9 windows-install  fail REGR. vs. 96211
 test-amd64-amd64-xl-qemut-debianhvm-amd64  6 xen-boot fail REGR. vs. 96211
 test-amd64-amd64-pygrub   6 xen-boot  fail REGR. vs. 96211
 test-amd64-amd64-xl-multivcpu  6 xen-boot fail REGR. vs. 96211
 test-amd64-amd64-xl   6 xen-boot  fail REGR. vs. 96211
 test-amd64-amd64-i386-pvgrub  6 xen-boot  fail REGR. vs. 96211
 test-armhf-armhf-libvirt-qcow2  9 debian-di-install   fail REGR. vs. 96211
 test-armhf-armhf-xl-multivcpu  9 debian-install   fail REGR. vs. 96211
 test-amd64-amd64-libvirt-xsm  6 xen-boot  fail REGR. vs. 96211
 test-amd64-i386-qemuu-rhel6hvm-intel  9 redhat-installfail REGR. vs. 96211
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 9 windows-install fail REGR. vs. 96211
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm  6 xen-boot fail REGR. vs. 96211
 test-amd64-i386-freebsd10-i386  9 freebsd-install fail REGR. vs. 96211
 test-amd64-amd64-libvirt-vhd  6 xen-boot  fail REGR. vs. 96211
 test-amd64-amd64-xl-credit2   6 xen-boot  fail REGR. vs. 96211
 test-armhf-armhf-xl-arndale   9 debian-installfail REGR. vs. 96211
 test-amd64-i386-xl9 debian-installfail REGR. vs. 96211
 test-amd64-amd64-xl-qemuu-ovmf-amd64  6 xen-boot  fail REGR. vs. 96211
 test-amd64-i386-qemuu-rhel6hvm-amd  9 redhat-install  fail REGR. vs. 96211
 test-amd64-i386-libvirt-pair 15 debian-install/dst_host   fail REGR. vs. 96211
 test-armhf-armhf-xl   9 debian-installfail REGR. vs. 96211
 test-amd64-i386-qemut-rhel6hvm-intel  9 redhat-installfail REGR. vs. 96211
 test-amd64-amd64-qemuu-nested-intel  6 xen-boot   fail REGR. vs. 96211
 test-armhf-armhf-libvirt-xsm  9 debian-installfail REGR. vs. 96211
 test-armhf-armhf-xl-credit2   9 debian-installfail REGR. vs. 96211
 test-armhf-armhf-xl-xsm   9 debian-installfail REGR. vs. 96211
 test-amd64-i386-pair 15 debian-install/dst_host   fail REGR. vs. 96211
 test-amd64-amd64-xl-xsm   6 xen-boot  fail REGR. vs. 96211
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 
96211
 test-armhf-armhf-xl-cubietruck  9 debian-install  fail REGR. vs. 96211
 test-amd64-amd64-qemuu-nested-amd  6 xen-boot fail REGR. vs. 96211
 test-amd64-amd64-xl-qemut-win7-amd64  6 xen-boot  fail REGR. vs. 96211
 test-amd64-amd64-xl-qcow2 6 xen-boot  fail REGR. vs. 96211
 test-armhf-armhf-libvirt  9 debian-installfail REGR. vs. 96211
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  6 xen-boot fail REGR. vs. 96211
 test-amd64-amd64-xl-qemut-winxpsp3  6 xen-bootfail REGR. vs. 96211
 test-amd64-amd64-xl-qemuu-winxpsp3  6 xen-bootfail REGR. vs. 96211
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 6 xen-boot fail REGR. 
vs. 96211
 test-amd64-amd64-xl-pvh-amd   6 xen-boot  fail REGR. vs. 96211
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  6 xen-boot fail REGR. vs. 96211
 test-amd64-amd64-libvirt  6 xen-boot  fail REGR. vs. 96211
 test-amd64-amd64-xl-pvh-intel  6 xen-boot fail REGR. vs. 96211
 test-amd64-amd64-xl-qemuu-win7-amd64  6 xen-boot  fail REGR. vs. 96211
 test-amd64-amd64-amd64-pvgrub  6 xen-boot fail REGR. vs. 96211
 test-amd64-i386-xl-qemut-win7-amd64  9 windows-installfail REGR. vs. 96211
 test-amd64-amd64-libvir

[Xen-devel] [PATCH LIVEPATCH-BUILD-TOOLS v2 2/3] Remove --xen-debug

[Ross Lagerwall]

With Xen commit bacbf0cb7349 ("build: convert debug to Kconfig"),
the debug build is controlled via Kconfig, so drop the separate
--xen-debug option to livepatch-build.

Signed-off-by: Ross Lagerwall 
---
 livepatch-build | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/livepatch-build b/livepatch-build
index a9ac4df..e9d1e8d 100755
--- a/livepatch-build
+++ b/livepatch-build
@@ -66,7 +66,7 @@ function build_full()
 {
 cd "${SRCDIR}/xen" || die
 make "-j$CPUS" clean &> "${OUTPUT}/build_full_clean.log" || die
-make "-j$CPUS" debug="$XEN_DEBUG" &> "${OUTPUT}/build_full_compile.log" || 
die
+make "-j$CPUS" &> "${OUTPUT}/build_full_compile.log" || die
 cp xen-syms "$OUTPUT"
 }
 
@@ -86,7 +86,7 @@ function build_special()
 # Build with special GCC flags
 cd "${SRCDIR}/xen" || die
 sed -i 's/CFLAGS += -nostdinc/CFLAGS += -nostdinc -ffunction-sections 
-fdata-sections/' Rules.mk
-make "-j$CPUS" debug="$XEN_DEBUG" &> "${OUTPUT}/build_${name}_compile.log" 
|| die
+make "-j$CPUS" &> "${OUTPUT}/build_${name}_compile.log" || die
 sed -i 's/CFLAGS += -nostdinc -ffunction-sections -fdata-sections/CFLAGS 
+= -nostdinc/' Rules.mk
 
 unset LIVEPATCH_BUILD_DIR
@@ -163,13 +163,12 @@ usage() {
 echo "-j, --cpus Number of CPUs to use" >&2
 echo "-k, --skip Skip build or diff phase" >&2
 echo "-d, --debugEnable debug logging" >&2
-echo "--xen-debugBuild debug Xen" >&2
 echo "--xen-syms Build against a xen-syms" >&2
 echo "--depends  Required build-id" >&2
 echo "--prelink  Prelink" >&2
 }
 
-options=$(getopt -o hs:p:c:o:j:k:d -l 
"help,srcdir:patch:config:output:cpus:,skip:,debug,xen-debug,xen-syms:,depends:,prelink"
 -- "$@") || die "getopt failed"
+options=$(getopt -o hs:p:c:o:j:k:d -l 
"help,srcdir:patch:config:output:cpus:,skip:,debug,xen-syms:,depends:,prelink" 
-- "$@") || die "getopt failed"
 
 eval set -- "$options"
 
@@ -193,10 +192,6 @@ while [[ $# -gt 0 ]]; do
 DEBUG=1
 shift
 ;;
---xen-debug)
-XEN_DEBUG=y
-shift
-;;
 -s|--srcdir)
 shift
 srcarg="$1"
-- 
2.7.4


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

[Xen-devel] [PATCH LIVEPATCH-BUILD-TOOLS v2 1/3] Update to use a .config file

[Ross Lagerwall]

Require the user to pass a .config file matching the original build's
.config to ensure that the build configuration is identical.

Signed-off-by: Ross Lagerwall 
---
 livepatch-build | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/livepatch-build b/livepatch-build
index 8dc8889..a9ac4df 100755
--- a/livepatch-build
+++ b/livepatch-build
@@ -158,6 +158,7 @@ usage() {
 echo "-h, --help Show this help message" >&2
 echo "-s, --srcdir   Xen source directory" >&2
 echo "-p, --patchPatch file" >&2
+echo "-c, --config   .config file" >&2
 echo "-o, --output   Output directory" >&2
 echo "-j, --cpus Number of CPUs to use" >&2
 echo "-k, --skip Skip build or diff phase" >&2
@@ -168,7 +169,7 @@ usage() {
 echo "--prelink  Prelink" >&2
 }
 
-options=$(getopt -o hs:p:o:j:k:d -l 
"help,srcdir:patch:output:cpus:,skip:,debug,xen-debug,xen-syms:,depends:,prelink"
 -- "$@") || die "getopt failed"
+options=$(getopt -o hs:p:c:o:j:k:d -l 
"help,srcdir:patch:config:output:cpus:,skip:,debug,xen-debug,xen-syms:,depends:,prelink"
 -- "$@") || die "getopt failed"
 
 eval set -- "$options"
 
@@ -206,6 +207,11 @@ while [[ $# -gt 0 ]]; do
 patcharg="$1"
 shift
 ;;
+-c|--config)
+shift
+configarg="$1"
+shift
+;;
 -o|--output)
 shift
 outputarg="$1"
@@ -235,15 +241,18 @@ done
 
 [ -z "$srcarg" ] && die "Xen directory not given"
 [ -z "$patcharg" ] && die "Patchfile not given"
+[ -z "$configarg" ] && die ".config not given"
 [ -z "$outputarg" ] && die "Output directory not given"
 [ -z "$DEPENDS" ] && die "Build-id dependency not given"
 
 SRCDIR="$(readlink -m -- "$srcarg")"
 PATCHFILE="$(readlink -m -- "$patcharg")"
+CONFIGFILE="$(readlink -m -- "$configarg")"
 OUTPUT="$(readlink -m -- "$outputarg")"
 
 [ -d "${SRCDIR}" ] || die "Xen directory does not exist"
 [ -f "${PATCHFILE}" ] || die "Patchfile does not exist"
+[ -f "${CONFIGFILE}" ] || die ".config does not exist"
 
 PATCHNAME=$(make_patch_name "${PATCHFILE}")
 
@@ -251,16 +260,20 @@ echo "Building LivePatch patch: ${PATCHNAME}"
 echo
 echo "Xen directory: ${SRCDIR}"
 echo "Patch file: ${PATCHFILE}"
+echo ".config file: ${CONFIGFILE}"
 echo "Output directory: ${OUTPUT}"
 echo ""
 echo
 
 if [ "${SKIP}" != "build" ]; then
 [ -e "${OUTPUT}" ] && die "Output directory exists"
+grep -q 'CONFIG_LIVEPATCH=y' "${CONFIGFILE}" || die "CONFIG_LIVEPATCH must 
be enabled"
 cd "$SRCDIR" || die
 patch -s -N -p1 -f --fuzz=0 --dry-run < "$PATCHFILE" || die "Source patch 
file failed to apply"
 
 mkdir -p "${OUTPUT}" || die
+cp -f "${CONFIGFILE}" "${OUTPUT}/.config"
+cp -f "${OUTPUT}/.config" "xen/.config"
 
 echo "Perform full initial build with ${CPUS} CPU(s)..."
 build_full
-- 
2.7.4


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

[Xen-devel] [PATCH LIVEPATCH-BUILD-TOOLS v2 3/3] Update README.md

[Ross Lagerwall]

Update the example and project status. Add Contributing and Maintainers
sections.

Signed-off-by: Ross Lagerwall 
---
 README.md | 76 ---
 1 file changed, 53 insertions(+), 23 deletions(-)

diff --git a/README.md b/README.md
index 9fb709f..653c624 100644
--- a/README.md
+++ b/README.md
@@ -2,27 +2,34 @@ livepatch-build
 =
 
 livepatch-build is a tool for building LivePatch patches from source code
-patches.  It takes as input, a Xen tree and a patch and outputs an
+patches.  It takes as input, a Xen tree and a patch and outputs a
 `.livepatch` module containing containing the live patch.
 
 Quick start
 ---
 First checkout the code, and then run `make` to build it.
 
-Here is an example of building a patch for XSA-106:
+Here is an example of building a live patch for Xen for some XSA.
+First build Xen, install it on a host somewhere and reboot:
+```
+$ cp -r ~/src/xen ~/src/xenbuild
+$ cd ~/src/xen/xen
+$ make nconfig # Make sure to set CONFIG_LIVEPATCH=y
+$ make
+$ BUILDID=$(readelf -Wn xen-syms | awk '/Build ID:/ {print $3}')
+```
+
+Next, build a live patch, using a patch and the source, build ID, and
+.config from the original build:
 ```
-$ cd ~/src/xen
-$ git reset --hard
-$ git clean -x -f -d
-$ git checkout 346d4545569928b652c40c7815c1732676f8587c^
 $ cd ~/src/livepatch-build
-$ wget -q 'http://xenbits.xen.org/xsa/xsa106.patch'
-$ ./livepatch-build --xen-debug -s ~/src/xen -p xsa106.patch -o out
-Building LivePatch patch: xsa106
+$ ./livepatch-build -s ~/src/xenbuild -p ~/src/xsa.patch -o out \
+-c ~/src/xen/xen/.config --depends $BUILDID
+Building LivePatch patch: xsa
 
-Xen directory: /home/ross/src/xen
-Patch file: /home/ross/src/livepatch-build/xsa106.patch
-Output directory: /home/ross/src/livepatch-build/out
+Xen directory: /home/ross/src/xenbuild
+Patch file: /home/ross/src/xsa.patch
+Output directory: /home/ross/src/livepatch-build-tools/out
 
 
 Testing patch file...
@@ -32,22 +39,45 @@ Unapply patch and build with 4 CPU(s)...
 Extracting new and modified ELF sections...
 Processing xen/arch/x86/x86_emulate.o
 Creating patch module...
-xsa106.livepatch created successfully
+xsa.livepatch created successfully
 
-$ ls -lh out/xsa106.livepatch
--rw-rw-r--. 1 ross ross 418K Oct 12 12:02 out/xsa106.livepatch
+$ ls -lh out/xsa.livepatch
+-rwxrwxr-x. 1 ross ross 135K Jun 10 09:32 out/xsa.livepatch
+```
+
+Finally, copy the live patch to the host and load it:
+```
+$ scp out/xsa.livepatch myhost:
+$ ssh myhost 'xen-livepatch load xsa.livepatch'
+Uploading xsa.livepatch (135840 bytes)
+Performing apply:. completed
+$ ssh myhost 'xen-livepatch list'
+ ID | status
++
+xsa | APPLIED
 ```
 
 Project Status
 --
-This is prototype code:
- * There's no way to apply built patches
- * Patches cannot be built for some source patches
- * The output format does not correspond to the latest LivePatch design
-
-With no source patch modifications, live patches can be built for every
-XSA that applies to x86 back to XSA-90 except for XSA-97, XSA-111,
-XSA-112, and XSA-114 (83% success rate).
+Live patches can be built and applied for many changes, including most
+XSAs; however, there are still some cases which require changing the
+source patch to allow it to be built as a live patch.
+
+This tool currently supports x86 only.
+
+It is intended that some or all of this project will merge back into
+kpatch-build rather being maintained as a fork.
+
+Contributing
+
+Please send patches created with `git-format-patch` and an appropriate
+Signed-off-by: line to , CCing the maintainers
+listed below.
+
+Maintainers
+---
+* Ross Lagerwall 
+* Konrad Rzeszutek Wilk 
 
 License
 ---
-- 
2.7.4


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

Re: [Xen-devel] [PATCH 2/3] Update to use a .config file

[Ross Lagerwall]

On 06/15/2016 03:00 PM, Konrad Rzeszutek Wilk wrote:

On Wed, Jun 15, 2016 at 09:08:46AM +0100, Ross Lagerwall wrote:

On 06/14/2016 04:35 PM, Konrad Rzeszutek Wilk wrote:

On Fri, Jun 10, 2016 at 12:02:44PM +0100, Ross Lagerwall wrote:

Remove the old --xen-debug option, and instead, require the user to pass
a .config file matching the original build's .config.


Hm, that throws this off a bit for the older hypervisors (to which
I had backported livepatch). Perhaps we could add some logic to
check if common/Kconfig exist?


At this point rather than adding extra logic to support different
still-experimental versions, I'd rather just have a different branch. Maybe
have a branch per Xen release?



And I also wonder if the --xen-debug option removal should be a seperate
patch?



Well the two are related -- the motivation to use the .config is because the
debug flag is now controlled by the .config rather than the command-line
argument.


But not in the 4.7 that is going out - that 'debug=y' is non-Kconfig?




OK, I'll split it into two. Feel free to create a stable-47 branch in 
livepatch-build-tools.git with only the .config patch. Personally, I'd 
rather not spend much time backporting stuff to support a tech preview 
feature on an older branch.


--
Ross Lagerwall

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

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

[osstest service owner]

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

Regressions :-(

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

version targeted for testing:
 ovmf 0e2c6c552990edcd6352c2395860cb0df62b158d
baseline version:
 ovmf dc99315b8732b6e3032d01319d3f534d440b43d0

Last test of basis94748  2016-05-24 22:43:25 Z   50 days
Failing since 94750  2016-05-25 03:43:08 Z   50 days  109 attempts
Testing same since97280  2016-07-13 23:15:41 Z0 days1 attempts


People who touched revisions under test:
  Anandakrishnan Loganathan 
  Ard Biesheuvel 
  Bi, Dandan 
  Bret Barkelew 
  Bruce Cran 
  Bruce Cran 
  Chao Zhang 
  Cinnamon Shia 
  Cohen, Eugene 
  Dandan Bi 
  Darbin Reyes 
  david wei 
  Eric Dong 
  Eugene Cohen 
  Evan Lloyd 
  Evgeny Yakovlev 
  Feng Tian 
  Fu Siyuan 
  Fu, Siyuan 
  Gary Li 
  Gary Lin 
  Giri P Mudusuru 
  Graeme Gregory 
  Hao Wu 
  Hegde Nagaraj P 
  Hegde, Nagaraj P 
  hegdenag 
  Heyi Guo 
  Jan D?bro? 
  Jan Dabros 
  Jeff Fan 
  Jiaxin Wu 
  Jiewen Yao 
  Joe Zhou 
  Jordan Justen 
  Katie Dellaquila 
  Laszlo Ersek 
  Liming Gao 
  Lu, ShifeiX A 
  lushifex 
  Marcin Wojtas 
  Mark Rutland 
  Marvin H?user 
  Marvin Haeuser 
  Maurice Ma 
  Michael Zimmermann 
  Mudusuru, Giri P 
  Ni, Ruiyu 
  Qiu Shumin 
  Ruiyu Ni 
  Ruiyu Ni　
  Ryan Harkin 
  Sami Mujawar 
  Satya Yarlagadda 
  Shannon Zhao 
  Sriram Subramanian 
  Star Zeng 
  Subramanian, Sriram (EG Servers Platform SW) 
  Sunny Wang 
  Tapan Shah 
  Thomas Palmer 
  Yarlagadda, Satya P 
  Yonghong Zhu 
  Zhang Lubo 
  Zhang, Chao B 
  Zhang, Lubo 

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 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail



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.

(No revision log; it would be 9800 lines long.)

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

[Xen-devel] [PATCH LIVEPATCH-BUILD-TOOLS] Support "make install"

[Ross Lagerwall]

Add rules to support using "make install".

Use "make install DESTDIR=... PREFIX=..." to customize the installation
path.

Signed-off-by: Ross Lagerwall 
---
 Makefile| 10 ++
 livepatch-build | 20 +---
 2 files changed, 27 insertions(+), 3 deletions(-)

diff --git a/Makefile b/Makefile
index aa5d5b0..f96b150 100644
--- a/Makefile
+++ b/Makefile
@@ -1,5 +1,9 @@
 SHELL = /bin/sh
 CC= gcc
+INSTALL = install
+PREFIX ?= /usr/local
+BINDIR = $(DESTDIR)$(PREFIX)/bin
+LIBEXECDIR = $(DESTDIR)$(PREFIX)/libexec/livepatch-build-tools
 
 .PHONY: all install clean
 .DEFAULT: all
@@ -25,5 +29,11 @@ create-diff-object: $(CREATE_DIFF_OBJECT_OBJS)
 prelink: $(PRELINK_OBJS)
$(CC) $(CFLAGS) $^ -o $@ $(LDFLAGS)
 
+install: all
+   $(INSTALL) -d $(LIBEXECDIR)
+   $(INSTALL) $(TARGETS) livepatch-gcc $(LIBEXECDIR)
+   $(INSTALL) -d $(BINDIR)
+   $(INSTALL) livepatch-build $(BINDIR)
+
 clean:
$(RM) $(TARGETS) $(CREATE_DIFF_OBJECT_OBJS) $(PRELINK_OBJS) *.d insn/*.d
diff --git a/livepatch-build b/livepatch-build
index 8dc8889..5ef2c88 100755
--- a/livepatch-build
+++ b/livepatch-build
@@ -49,6 +49,18 @@ die() {
 exit 1
 }
 
+find_tools() {
+if [[ -e "$SCRIPTDIR/create-diff-object" ]]; then
+# Running from source tree
+TOOLSDIR="$SCRIPTDIR"
+elif [[ -e 
"$SCRIPTDIR/../libexec/livepatch-build-tools/create-diff-object" ]]; then
+# Running installed
+TOOLSDIR="$(readlink -f $SCRIPTDIR/../libexec/livepatch-build-tools)"
+else
+return 1
+fi
+}
+
 function make_patch_name()
 {
 PATCHNAME=$(basename "$1")
@@ -78,7 +90,7 @@ function build_special()
 cd "${SRCDIR}" || die
 
 # Capture .o files from the patched build
-export CROSS_COMPILE="${SCRIPTDIR}/livepatch-gcc "
+export CROSS_COMPILE="${TOOLSDIR}/livepatch-gcc "
 export LIVEPATCH_BUILD_DIR="$(pwd)/"
 export LIVEPATCH_CAPTURE_DIR="$OUTPUT/${name}"
 mkdir -p "$LIVEPATCH_CAPTURE_DIR"
@@ -112,7 +124,7 @@ function create_patch()
 mkdir -p "output/$(dirname $i)" || die
 echo "Processing ${i}"
 echo "Run create-diff-object on $i" >> 
"${OUTPUT}/create-diff-object.log"
-"${SCRIPTDIR}"/create-diff-object $debugopt $PRELINK "original/$i" 
"patched/$i" "$XENSYMS" "output/$i" &>> "${OUTPUT}/create-diff-object.log"
+"${TOOLSDIR}"/create-diff-object $debugopt $PRELINK "original/$i" 
"patched/$i" "$XENSYMS" "output/$i" &>> "${OUTPUT}/create-diff-object.log"
 rc="${PIPESTATUS[0]}"
 if [[ $rc = 139 ]]; then
 warn "create-diff-object SIGSEGV"
@@ -146,7 +158,7 @@ function create_patch()
 chmod +x "${PATCHNAME}.livepatch"
 else
 ld -r -o output.o --build-id=sha1 $(find output -type f -name "*.o") 
|| die
-"${SCRIPTDIR}"/prelink $debugopt output.o "${PATCHNAME}.livepatch" 
"$XENSYMS" &>> "${OUTPUT}/prelink.log" || die
+"${TOOLSDIR}"/prelink $debugopt output.o "${PATCHNAME}.livepatch" 
"$XENSYMS" &>> "${OUTPUT}/prelink.log" || die
 fi
 
 objcopy --add-section .livepatch.depends=depends.bin 
"${PATCHNAME}.livepatch"
@@ -168,6 +180,8 @@ usage() {
 echo "--prelink  Prelink" >&2
 }
 
+find_tools || die "can't find supporting tools"
+
 options=$(getopt -o hs:p:o:j:k:d -l 
"help,srcdir:patch:output:cpus:,skip:,debug,xen-debug,xen-syms:,depends:,prelink"
 -- "$@") || die "getopt failed"
 
 eval set -- "$options"
-- 
2.7.4


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

[Xen-devel] [PATCH v3 0/8] adjustments

[Corneliu ZUZU]

Corneliu ZUZU (8):
  1/8: asm-arm/atomic.h: fix arm32|arm64 macros duplication
Reviewed-by: Stefano Stabellini 
Changed:
* also moved mistakenly omitted atomic_xchg()
* arm empty line fixes moved here

  2/8: asm-x86/atomic.h: minor: proper atomic_inc_and_test() placement
Changed:
* arm empty line fixes moved from here (to 1/8)

  3/8: asm-arm/atomic.h: reorder macros to match x86-side
Reviewed-by: Stefano Stabellini 
Changed: 

  4/8: asm/atomic.h: common prototyping (add xen/atomic.h)
Reviewed-by: Andrew Cooper 
Changed:
* sample code for atomic_cmpxchg() (doc-comment in )
  updated to use atomic_read() instead of directly accessing v.counter

  5/8: fix: make atomic_read() param const
Reviewed-by: Andrew Cooper 
Changed: 

  New in this version:
  6/8: asm-arm/atomic.h: atomic_{inc,dec}_return: macros to inline functions
  7/8: arm/atomic.h: remove '__' prefix for __atomic_add_unless()
  8/8: asm-x86/atomic.h: implement missing, add common prototypes

 xen/include/asm-arm/arm32/atomic.h |  17 +--
 xen/include/asm-arm/arm64/atomic.h |  17 +--
 xen/include/asm-arm/atomic.h   |  55 --
 xen/include/asm-x86/atomic.h   | 151 +++
 xen/include/xen/atomic.h   | 207 +
 5 files changed, 296 insertions(+), 151 deletions(-)
 create mode 100644 xen/include/xen/atomic.h

-- 
2.5.0


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

[Xen-devel] [PATCH v3 1/8] asm-arm/atomic.h: fix arm32|arm64 macros duplication

[Corneliu ZUZU]

Move duplicate macros between asm-arm/arm32/atomic.h and asm-arm/arm64/atomic.h
to asm-arm/atomic.h.
Also empty line fixes.

Signed-off-by: Corneliu ZUZU 
Reviewed-by: Stefano Stabellini 
---
Changed since v2:
  * also moved mistakenly omitted atomic_xchg()
  * arm empty line fixes moved here
---
 xen/include/asm-arm/arm32/atomic.h | 15 ++-
 xen/include/asm-arm/arm64/atomic.h | 15 ++-
 xen/include/asm-arm/atomic.h   | 14 ++
 3 files changed, 18 insertions(+), 26 deletions(-)

diff --git a/xen/include/asm-arm/arm32/atomic.h 
b/xen/include/asm-arm/arm32/atomic.h
index 7ec712f..78de60f 100644
--- a/xen/include/asm-arm/arm32/atomic.h
+++ b/xen/include/asm-arm/arm32/atomic.h
@@ -8,6 +8,7 @@
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
  */
+
 #ifndef __ARCH_ARM_ARM32_ATOMIC__
 #define __ARCH_ARM_ARM32_ATOMIC__
 
@@ -147,20 +148,8 @@ static inline int __atomic_add_unless(atomic_t *v, int a, 
int u)
return oldval;
 }
 
-#define atomic_xchg(v, new) (xchg(&((v)->counter), new))
-
-#define atomic_inc(v)  atomic_add(1, v)
-#define atomic_dec(v)  atomic_sub(1, v)
-
-#define atomic_inc_and_test(v) (atomic_add_return(1, v) == 0)
-#define atomic_dec_and_test(v) (atomic_sub_return(1, v) == 0)
-#define atomic_inc_return(v)(atomic_add_return(1, v))
-#define atomic_dec_return(v)(atomic_sub_return(1, v))
-#define atomic_sub_and_test(i, v) (atomic_sub_return(i, v) == 0)
-
-#define atomic_add_negative(i,v) (atomic_add_return(i, v) < 0)
-
 #endif /* __ARCH_ARM_ARM32_ATOMIC__ */
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/asm-arm/arm64/atomic.h 
b/xen/include/asm-arm/arm64/atomic.h
index b49219e..d640bef 100644
--- a/xen/include/asm-arm/arm64/atomic.h
+++ b/xen/include/asm-arm/arm64/atomic.h
@@ -19,6 +19,7 @@
  * You should have received a copy of the GNU General Public License
  * along with this program.  If not, see .
  */
+
 #ifndef __ARCH_ARM_ARM64_ATOMIC
 #define __ARCH_ARM_ARM64_ATOMIC
 
@@ -113,8 +114,6 @@ static inline int atomic_cmpxchg(atomic_t *ptr, int old, 
int new)
return oldval;
 }
 
-#define atomic_xchg(v, new) (xchg(&((v)->counter), new))
-
 static inline int __atomic_add_unless(atomic_t *v, int a, int u)
 {
int c, old;
@@ -125,18 +124,8 @@ static inline int __atomic_add_unless(atomic_t *v, int a, 
int u)
return c;
 }
 
-#define atomic_inc(v)  atomic_add(1, v)
-#define atomic_dec(v)  atomic_sub(1, v)
-
-#define atomic_inc_and_test(v) (atomic_add_return(1, v) == 0)
-#define atomic_dec_and_test(v) (atomic_sub_return(1, v) == 0)
-#define atomic_inc_return(v)(atomic_add_return(1, v))
-#define atomic_dec_return(v)(atomic_sub_return(1, v))
-#define atomic_sub_and_test(i, v) (atomic_sub_return(i, v) == 0)
-
-#define atomic_add_negative(i,v) (atomic_add_return(i, v) < 0)
-
 #endif
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/asm-arm/atomic.h b/xen/include/asm-arm/atomic.h
index 29ab265..32771e9 100644
--- a/xen/include/asm-arm/atomic.h
+++ b/xen/include/asm-arm/atomic.h
@@ -138,7 +138,21 @@ static inline void _atomic_set(atomic_t *v, int i)
 # error "unknown ARM variant"
 #endif
 
+#define atomic_inc(v)   atomic_add(1, v)
+#define atomic_dec(v)   atomic_sub(1, v)
+
+#define atomic_inc_and_test(v)  (atomic_add_return(1, v) == 0)
+#define atomic_dec_and_test(v)  (atomic_sub_return(1, v) == 0)
+#define atomic_inc_return(v)(atomic_add_return(1, v))
+#define atomic_dec_return(v)(atomic_sub_return(1, v))
+#define atomic_sub_and_test(i, v) (atomic_sub_return(i, v) == 0)
+
+#define atomic_add_negative(i,v) (atomic_add_return(i, v) < 0)
+
+#define atomic_xchg(v, new) (xchg(&((v)->counter), new))
+
 #endif /* __ARCH_ARM_ATOMIC__ */
+
 /*
  * Local variables:
  * mode: C
-- 
2.5.0


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

[Xen-devel] [PATCH v3 2/8] asm-x86/atomic.h: minor: proper atomic_inc_and_test() placement

[Corneliu ZUZU]

Place atomic_inc_and_test() implementation after atomic_inc().
Also empty line fix.

Signed-off-by: Corneliu ZUZU 
---
Changed since v2: arm empty line fixes moved from here
---
 xen/include/asm-x86/atomic.h | 39 +++
 1 file changed, 19 insertions(+), 20 deletions(-)

diff --git a/xen/include/asm-x86/atomic.h b/xen/include/asm-x86/atomic.h
index d246b70..5f9f2dd 100644
--- a/xen/include/asm-x86/atomic.h
+++ b/xen/include/asm-x86/atomic.h
@@ -110,7 +110,6 @@ static inline int _atomic_read(atomic_t v)
 return v.counter;
 }
 
-
 /**
  * atomic_set - set atomic variable
  * @v: pointer of type atomic_t
@@ -217,6 +216,25 @@ static inline void atomic_inc(atomic_t *v)
 }
 
 /**
+ * atomic_inc_and_test - increment and test
+ * @v: pointer of type atomic_t
+ *
+ * Atomically increments @v by 1
+ * and returns true if the result is zero, or false for all
+ * other cases.
+ */
+static inline int atomic_inc_and_test(atomic_t *v)
+{
+unsigned char c;
+
+asm volatile (
+"lock; incl %0; sete %1"
+: "=m" (*(volatile int *)&v->counter), "=qm" (c)
+: "m" (*(volatile int *)&v->counter) : "memory" );
+return c != 0;
+}
+
+/**
  * atomic_dec - decrement atomic variable
  * @v: pointer of type atomic_t
  * 
@@ -250,25 +268,6 @@ static inline int atomic_dec_and_test(atomic_t *v)
 }
 
 /**
- * atomic_inc_and_test - increment and test 
- * @v: pointer of type atomic_t
- * 
- * Atomically increments @v by 1
- * and returns true if the result is zero, or false for all
- * other cases.
- */ 
-static inline int atomic_inc_and_test(atomic_t *v)
-{
-unsigned char c;
-
-asm volatile (
-"lock; incl %0; sete %1"
-: "=m" (*(volatile int *)&v->counter), "=qm" (c)
-: "m" (*(volatile int *)&v->counter) : "memory" );
-return c != 0;
-}
-
-/**
  * atomic_add_negative - add and test if negative
  * @v: pointer of type atomic_t
  * @i: integer value to add
-- 
2.5.0


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

[Xen-devel] [PATCH v3 3/8] asm-arm/atomic.h: reorder macros to match x86-side

[Corneliu ZUZU]

Reorder macro definitions to match x86-side.

Signed-off-by: Corneliu ZUZU 
Reviewed-by: Stefano Stabellini 
---
Changed since v2: 
---
 xen/include/asm-arm/atomic.h | 19 +--
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/xen/include/asm-arm/atomic.h b/xen/include/asm-arm/atomic.h
index 32771e9..620c636 100644
--- a/xen/include/asm-arm/atomic.h
+++ b/xen/include/asm-arm/atomic.h
@@ -138,16 +138,15 @@ static inline void _atomic_set(atomic_t *v, int i)
 # error "unknown ARM variant"
 #endif
 
-#define atomic_inc(v)   atomic_add(1, v)
-#define atomic_dec(v)   atomic_sub(1, v)
-
-#define atomic_inc_and_test(v)  (atomic_add_return(1, v) == 0)
-#define atomic_dec_and_test(v)  (atomic_sub_return(1, v) == 0)
-#define atomic_inc_return(v)(atomic_add_return(1, v))
-#define atomic_dec_return(v)(atomic_sub_return(1, v))
-#define atomic_sub_and_test(i, v) (atomic_sub_return(i, v) == 0)
-
-#define atomic_add_negative(i,v) (atomic_add_return(i, v) < 0)
+#define atomic_inc_return(v)(atomic_add_return(1, v))
+#define atomic_dec_return(v)(atomic_sub_return(1, v))
+
+#define atomic_sub_and_test(i, v)   (atomic_sub_return(i, v) == 0)
+#define atomic_inc(v)   atomic_add(1, v)
+#define atomic_inc_and_test(v)  (atomic_add_return(1, v) == 0)
+#define atomic_dec(v)   atomic_sub(1, v)
+#define atomic_dec_and_test(v)  (atomic_sub_return(1, v) == 0)
+#define atomic_add_negative(i,v)(atomic_add_return(i, v) < 0)
 
 #define atomic_xchg(v, new) (xchg(&((v)->counter), new))
 
-- 
2.5.0


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

[Xen-devel] [PATCH v3 4/8] asm/atomic.h: common prototyping (add xen/atomic.h)

[Corneliu ZUZU]

Create a common-side  to establish, among others, prototypes of
atomic functions called from common-code. Done to avoid introducing
inconsistencies between arch-side  headers when we make subtle
changes to one of them.

Some arm-side macros had to be turned into inline functions in the process.
Removed outdated comment ("NB. I've [...]").

Signed-off-by: Corneliu ZUZU 
Suggested-by: Andrew Cooper 
Reviewed-by: Andrew Cooper 
---
Changed since v2:
  * sample code for atomic_cmpxchg() (doc-comment in ) updated to
use atomic_read() instead of directly accessing v.counter
---
 xen/include/asm-arm/atomic.h |  45 
 xen/include/asm-x86/atomic.h | 103 +-
 xen/include/xen/atomic.h | 171 +++
 3 files changed, 202 insertions(+), 117 deletions(-)
 create mode 100644 xen/include/xen/atomic.h

diff --git a/xen/include/asm-arm/atomic.h b/xen/include/asm-arm/atomic.h
index 620c636..a79420a 100644
--- a/xen/include/asm-arm/atomic.h
+++ b/xen/include/asm-arm/atomic.h
@@ -2,6 +2,7 @@
 #define __ARCH_ARM_ATOMIC__
 
 #include 
+#include 
 #include 
 #include 
 
@@ -95,15 +96,6 @@ void __bad_atomic_size(void);
 default: __bad_atomic_size(); break;\
 }   \
 })
-
-/*
- * NB. I've pushed the volatile qualifier into the operations. This allows
- * fast accessors such as _atomic_read() and _atomic_set() which don't give
- * the compiler a fit.
- */
-typedef struct { int counter; } atomic_t;
-
-#define ATOMIC_INIT(i) { (i) }
 
 /*
  * On ARM, ordinary assignment (str instruction) doesn't clear the local
@@ -141,12 +133,35 @@ static inline void _atomic_set(atomic_t *v, int i)
 #define atomic_inc_return(v)(atomic_add_return(1, v))
 #define atomic_dec_return(v)(atomic_sub_return(1, v))
 
-#define atomic_sub_and_test(i, v)   (atomic_sub_return(i, v) == 0)
-#define atomic_inc(v)   atomic_add(1, v)
-#define atomic_inc_and_test(v)  (atomic_add_return(1, v) == 0)
-#define atomic_dec(v)   atomic_sub(1, v)
-#define atomic_dec_and_test(v)  (atomic_sub_return(1, v) == 0)
-#define atomic_add_negative(i,v)(atomic_add_return(i, v) < 0)
+static inline int atomic_sub_and_test(int i, atomic_t *v)
+{
+return atomic_sub_return(i, v) == 0;
+}
+
+static inline void atomic_inc(atomic_t *v)
+{
+atomic_add(1, v);
+}
+
+static inline int atomic_inc_and_test(atomic_t *v)
+{
+return atomic_add_return(1, v) == 0;
+}
+
+static inline void atomic_dec(atomic_t *v)
+{
+atomic_sub(1, v);
+}
+
+static inline int atomic_dec_and_test(atomic_t *v)
+{
+return atomic_sub_return(1, v) == 0;
+}
+
+static inline int atomic_add_negative(int i, atomic_t *v)
+{
+return atomic_add_return(i, v) < 0;
+}
 
 #define atomic_xchg(v, new) (xchg(&((v)->counter), new))
 
diff --git a/xen/include/asm-x86/atomic.h b/xen/include/asm-x86/atomic.h
index 5f9f2dd..3e99b03 100644
--- a/xen/include/asm-x86/atomic.h
+++ b/xen/include/asm-x86/atomic.h
@@ -2,6 +2,7 @@
 #define __ARCH_X86_ATOMIC__
 
 #include 
+#include 
 #include 
 
 #define build_read_atomic(name, size, type, reg, barrier) \
@@ -79,56 +80,21 @@ void __bad_atomic_size(void);
 } \
 })
 
-/*
- * NB. I've pushed the volatile qualifier into the operations. This allows
- * fast accessors such as _atomic_read() and _atomic_set() which don't give
- * the compiler a fit.
- */
-typedef struct { int counter; } atomic_t;
-
-#define ATOMIC_INIT(i) { (i) }
-
-/**
- * atomic_read - read atomic variable
- * @v: pointer of type atomic_t
- *
- * Atomically reads the value of @v.
- */
 static inline int atomic_read(atomic_t *v)
 {
 return read_atomic(&v->counter);
 }
 
-/**
- * _atomic_read - read atomic variable non-atomically
- * @v atomic_t
- *
- * Non-atomically reads the value of @v
- */
 static inline int _atomic_read(atomic_t v)
 {
 return v.counter;
 }
 
-/**
- * atomic_set - set atomic variable
- * @v: pointer of type atomic_t
- * @i: required value
- *
- * Atomically sets the value of @v to @i.
- */
 static inline void atomic_set(atomic_t *v, int i)
 {
 write_atomic(&v->counter, i);
 }
 
-/**
- * _atomic_set - set atomic variable non-atomically
- * @v: pointer of type atomic_t
- * @i: required value
- *
- * Non-atomically sets the value of @v to @i.
- */
 static inline void _atomic_set(atomic_t *v, int i)
 {
 v->counter = i;
@@ -139,13 +105,6 @@ static inline int atomic_cmpxchg(atomic_t *v, int old, int 
new)
 return cmpxchg(&v->counter, old, new);
 }
 
-/**
- * atomic_add - add integer to atomic variable
- * @i: integer value to add
- * @v: pointer of type atomic_t
- * 
- * Atomically adds @i to @v.
- */
 static inline void atomic_add(int i, atomic_t *v)
 {
 asm volatile (
@@ -154,25 +113,11 @@ static inline void atomic_add(int i, atomic_t *v)
 : "ir" (i), "m" (*(volatile int *)&v->counter) 

[Xen-devel] [PATCH v3 5/8] fix: make atomic_read() param const

[Corneliu ZUZU]

This wouldn't let me make a param of a function that used atomic_read() const.

Signed-off-by: Corneliu ZUZU 
Reviewed-by: Andrew Cooper 

---
Changed since v2: 
---
 xen/include/asm-arm/atomic.h | 2 +-
 xen/include/asm-x86/atomic.h | 2 +-
 xen/include/xen/atomic.h | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/include/asm-arm/atomic.h b/xen/include/asm-arm/atomic.h
index a79420a..78dad29 100644
--- a/xen/include/asm-arm/atomic.h
+++ b/xen/include/asm-arm/atomic.h
@@ -102,7 +102,7 @@ void __bad_atomic_size(void);
  * strex/ldrex monitor on some implementations. The reason we can use it for
  * atomic_set() is the clrex or dummy strex done on every exception return.
  */
-static inline int atomic_read(atomic_t *v)
+static inline int atomic_read(const atomic_t *v)
 {
 return *(volatile int *)&v->counter;
 }
diff --git a/xen/include/asm-x86/atomic.h b/xen/include/asm-x86/atomic.h
index 3e99b03..1729e29 100644
--- a/xen/include/asm-x86/atomic.h
+++ b/xen/include/asm-x86/atomic.h
@@ -80,7 +80,7 @@ void __bad_atomic_size(void);
 } \
 })
 
-static inline int atomic_read(atomic_t *v)
+static inline int atomic_read(const atomic_t *v)
 {
 return read_atomic(&v->counter);
 }
diff --git a/xen/include/xen/atomic.h b/xen/include/xen/atomic.h
index d072912..6827468 100644
--- a/xen/include/xen/atomic.h
+++ b/xen/include/xen/atomic.h
@@ -32,7 +32,7 @@ typedef struct { int counter; } atomic_t;
  *
  * Atomically reads the value of @v.
  */
-static inline int atomic_read(atomic_t *v);
+static inline int atomic_read(const atomic_t *v);
 
 /**
  * _atomic_read - read atomic variable non-atomically
-- 
2.5.0


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

[Xen-devel] [PATCH v3 6/8] asm-arm/atomic.h: atomic_{inc, dec}_return: macros to inline functions

[Corneliu ZUZU]

Turn atomic_inc_return and atomic_dec_return atomic.h macros to inline
functions.

Signed-off-by: Corneliu ZUZU 
---
 xen/include/asm-arm/atomic.h | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/xen/include/asm-arm/atomic.h b/xen/include/asm-arm/atomic.h
index 78dad29..c69aae6 100644
--- a/xen/include/asm-arm/atomic.h
+++ b/xen/include/asm-arm/atomic.h
@@ -130,9 +130,6 @@ static inline void _atomic_set(atomic_t *v, int i)
 # error "unknown ARM variant"
 #endif
 
-#define atomic_inc_return(v)(atomic_add_return(1, v))
-#define atomic_dec_return(v)(atomic_sub_return(1, v))
-
 static inline int atomic_sub_and_test(int i, atomic_t *v)
 {
 return atomic_sub_return(i, v) == 0;
@@ -143,6 +140,11 @@ static inline void atomic_inc(atomic_t *v)
 atomic_add(1, v);
 }
 
+static inline int atomic_inc_return(atomic_t *v)
+{
+return atomic_add_return(1, v);
+}
+
 static inline int atomic_inc_and_test(atomic_t *v)
 {
 return atomic_add_return(1, v) == 0;
@@ -153,6 +155,11 @@ static inline void atomic_dec(atomic_t *v)
 atomic_sub(1, v);
 }
 
+static inline int atomic_dec_return(atomic_t *v)
+{
+return atomic_sub_return(1, v);
+}
+
 static inline int atomic_dec_and_test(atomic_t *v)
 {
 return atomic_sub_return(1, v) == 0;
-- 
2.5.0


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

[Xen-devel] [PATCH v3 7/8] arm/atomic.h: remove '__' prefix for __atomic_add_unless()

[Corneliu ZUZU]

The built-in leading underscores ('__') don't serve any purpose, so rename
__atomic_add_unless() -> atomic_add_unless().

Signed-off-by: Corneliu ZUZU 
---
 xen/include/asm-arm/arm32/atomic.h | 2 +-
 xen/include/asm-arm/arm64/atomic.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/include/asm-arm/arm32/atomic.h 
b/xen/include/asm-arm/arm32/atomic.h
index 78de60f..dc95518 100644
--- a/xen/include/asm-arm/arm32/atomic.h
+++ b/xen/include/asm-arm/arm32/atomic.h
@@ -121,7 +121,7 @@ static inline int atomic_cmpxchg(atomic_t *ptr, int old, 
int new)
return oldval;
 }
 
-static inline int __atomic_add_unless(atomic_t *v, int a, int u)
+static inline int atomic_add_unless(atomic_t *v, int a, int u)
 {
int oldval, newval;
unsigned long tmp;
diff --git a/xen/include/asm-arm/arm64/atomic.h 
b/xen/include/asm-arm/arm64/atomic.h
index d640bef..f0e83be 100644
--- a/xen/include/asm-arm/arm64/atomic.h
+++ b/xen/include/asm-arm/arm64/atomic.h
@@ -114,7 +114,7 @@ static inline int atomic_cmpxchg(atomic_t *ptr, int old, 
int new)
return oldval;
 }
 
-static inline int __atomic_add_unless(atomic_t *v, int a, int u)
+static inline int atomic_add_unless(atomic_t *v, int a, int u)
 {
int c, old;
 
-- 
2.5.0


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

[Xen-devel] [PATCH v3 8/8] asm-x86/atomic.h: implement missing, add common prototypes

[Corneliu ZUZU]

- implement missing functions atomic_{sub,inc,dec}_return(), atomic_add_unless()
  on X86 and also add prototypes for them in common 

- add missing macro atomic_xchg for X86

Signed-off-by: Corneliu ZUZU 
---
 xen/include/asm-x86/atomic.h | 27 +++
 xen/include/xen/atomic.h | 36 
 2 files changed, 63 insertions(+)

diff --git a/xen/include/asm-x86/atomic.h b/xen/include/asm-x86/atomic.h
index 1729e29..101eded 100644
--- a/xen/include/asm-x86/atomic.h
+++ b/xen/include/asm-x86/atomic.h
@@ -126,6 +126,11 @@ static inline void atomic_sub(int i, atomic_t *v)
 : "ir" (i), "m" (*(volatile int *)&v->counter) );
 }
 
+static inline int atomic_sub_return(int i, atomic_t *v)
+{
+return arch_fetch_and_add(&v->counter, -i) - i;
+}
+
 static inline int atomic_sub_and_test(int i, atomic_t *v)
 {
 unsigned char c;
@@ -145,6 +150,11 @@ static inline void atomic_inc(atomic_t *v)
 : "m" (*(volatile int *)&v->counter) );
 }
 
+static inline int atomic_inc_return(atomic_t *v)
+{
+return atomic_add_return(1, v);
+}
+
 static inline int atomic_inc_and_test(atomic_t *v)
 {
 unsigned char c;
@@ -164,6 +174,11 @@ static inline void atomic_dec(atomic_t *v)
 : "m" (*(volatile int *)&v->counter) );
 }
 
+static inline int atomic_dec_return(atomic_t *v)
+{
+return atomic_sub_return(1, v);
+}
+
 static inline int atomic_dec_and_test(atomic_t *v)
 {
 unsigned char c;
@@ -186,4 +201,16 @@ static inline int atomic_add_negative(int i, atomic_t *v)
 return c;
 }
 
+static inline int atomic_add_unless(atomic_t *v, int a, int u)
+{
+int c, old;
+
+c = atomic_read(v);
+while (c != u && (old = atomic_cmpxchg(v, c, c + a)) != c)
+c = old;
+return c;
+}
+
+#define atomic_xchg(v, new) (xchg(&((v)->counter), new))
+
 #endif /* __ARCH_X86_ATOMIC__ */
diff --git a/xen/include/xen/atomic.h b/xen/include/xen/atomic.h
index 6827468..529213e 100644
--- a/xen/include/xen/atomic.h
+++ b/xen/include/xen/atomic.h
@@ -111,6 +111,15 @@ static inline int atomic_add_return(int i, atomic_t *v);
 static inline void atomic_sub(int i, atomic_t *v);
 
 /**
+ * atomic_sub_return - sub integer and return
+ * @i: integer value to sub
+ * @v: pointer of type atomic_t
+ *
+ * Atomically subtracts @i from @v and returns @v - @i.
+ */
+static inline int atomic_sub_return(int i, atomic_t *v);
+
+/**
  * atomic_sub_and_test - subtract value from variable and test result
  * @i: integer value to subtract
  * @v: pointer of type atomic_t
@@ -130,6 +139,14 @@ static inline int atomic_sub_and_test(int i, atomic_t *v);
 static inline void atomic_inc(atomic_t *v);
 
 /**
+ * atomic_inc_return - increment atomic variable and return
+ * @v: pointer of type atomic_t
+ *
+ * Atomically increments @v by 1 and returns @v + 1.
+ */
+static inline int atomic_inc_return(atomic_t *v);
+
+/**
  * atomic_inc_and_test - increment and test
  * @v: pointer of type atomic_t
  *
@@ -148,6 +165,14 @@ static inline int atomic_inc_and_test(atomic_t *v);
 static inline void atomic_dec(atomic_t *v);
 
 /**
+ * atomic_dec_return - decrement atomic variable and return
+ * @v: pointer of type atomic_t
+ *
+ * Atomically decrements @v by 1 and returns @v - 1.
+ */
+static inline int atomic_dec_return(atomic_t *v);
+
+/**
  * atomic_dec_and_test - decrement and test
  * @v: pointer of type atomic_t
  *
@@ -168,4 +193,15 @@ static inline int atomic_dec_and_test(atomic_t *v);
  */
 static inline int atomic_add_negative(int i, atomic_t *v);
 
+/**
+ * atomic_add_unless - add to atomic variable unless it has a specified value
+ * @v: pointer of type atomic_t
+ * @a: integer value to add
+ * @u: integer value @v must -not- be for the add to be performed
+ *
+ * If @v != @u, adds @a to @v and returns @v + @a.
+ * Otherwise returns @u (== @v).
+ */
+static inline int atomic_add_unless(atomic_t *v, int a, int u);
+
 #endif /* __XEN_ATOMIC_H__ */
-- 
2.5.0


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

Re: [Xen-devel] [PATCH v3 5/8] fix: make atomic_read() param const

[Andrew Cooper]

On 14/07/16 10:13, Corneliu ZUZU wrote:
> This wouldn't let me make a param of a function that used atomic_read() const.
>
> Signed-off-by: Corneliu ZUZU 
> Reviewed-by: Andrew Cooper 

You have dropped a Reviewed-by: Stefano Stabellini
 from v2.

~Andrew

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

Re: [Xen-devel] [PATCH v2 1/5] asm-arm/atomic.h: fix arm32|arm64 macros duplication

[Julien Grall]

On 14/07/16 06:11, Corneliu ZUZU wrote:

On 7/13/2016 10:12 PM, Julien Grall wrote:

Hi Corneliu,

On 13/07/2016 15:18, Corneliu ZUZU wrote:

Move duplicate macros between asm-arm/arm32/atomic.h and
asm-arm/arm64/atomic.h
to asm-arm/atomic.h.


asm-arm/arm*/atomic.h were a copy from Linux. I don't mind if we
diverge, however the file xen/arch/arm/README.primitives needs to be
update to mention the divergence with Linux.

Regards,



Julien,

AFAICT the README.LinuxPrimitives file specifies the Linux kernel
version from which the arm{32,64}/atomic.h files were imported as well
as the respective commit in the -Linux kernel- tree. I suppose that
information needn't be updated.
Could you be more specific on how I should modify that file?


To specify which helpers has been taken from Linux in those files. Until 
now, it was quite easy to figure out that we took all atomic_* helpers.


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v3 2/8] asm-x86/atomic.h: minor: proper atomic_inc_and_test() placement

[Andrew Cooper]

On 14/07/16 10:10, Corneliu ZUZU wrote:
> Place atomic_inc_and_test() implementation after atomic_inc().
> Also empty line fix.
>
> Signed-off-by: Corneliu ZUZU 

Reviewed-by: Andrew Cooper 
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 8/8] asm-x86/atomic.h: implement missing, add common prototypes

[Andrew Cooper]

On 14/07/16 10:14, Corneliu ZUZU wrote:
> - implement missing functions atomic_{sub,inc,dec}_return(), 
> atomic_add_unless()
>   on X86 and also add prototypes for them in common 
>
> - add missing macro atomic_xchg for X86
>
> Signed-off-by: Corneliu ZUZU 

Reviewed-by: Andrew Cooper 
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 5/8] fix: make atomic_read() param const

[Corneliu ZUZU]

On 7/14/2016 12:26 PM, Andrew Cooper wrote:

On 14/07/16 10:13, Corneliu ZUZU wrote:

This wouldn't let me make a param of a function that used atomic_read() const.

Signed-off-by: Corneliu ZUZU 
Reviewed-by: Andrew Cooper 

You have dropped a Reviewed-by: Stefano Stabellini
 from v2.

~Andrew



Intentionally dropped, he reviewed the empty line fixes in ARM atomic.h 
- which were now moved to 1/8 (which includes Reviewed-by: [...]).


Zuzu C.

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

Re: [Xen-devel] [PATCH v3 5/8] fix: make atomic_read() param const

[Corneliu ZUZU]

On 7/14/2016 12:26 PM, Andrew Cooper wrote:

On 14/07/16 10:13, Corneliu ZUZU wrote:

This wouldn't let me make a param of a function that used atomic_read() const.

Signed-off-by: Corneliu ZUZU 
Reviewed-by: Andrew Cooper 

You have dropped a Reviewed-by: Stefano Stabellini
 from v2.

~Andrew


Oh, that's right, sorry.

Zuzu C.


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

Re: [Xen-devel] [PATCH v2] libxl: trigger attach events for devices attached before xl devd startup

[Wei Liu]

On Mon, Jul 11, 2016 at 12:44:42PM +0200, Marek Marczykowski-Górecki wrote:
> When this daemon is started after creating backend device, that device
> will not be configured.
> 
> Racy situation:
> 1. driver domain is started
> 2. frontend domain is started (just after kicking driver domain off)
> 3. device in frontend domain is connected to the backend (as specified
>in frontend domain configuration)
> 4. xl devd is started in driver domain
> 
> End result is that backend device in driver domain is not configured
> (like network interface is not enabled), so the device doesn't work.
> 
> Fix this by artifically triggering events for devices already present in
> xenstore before xl devd is started. Do this only after xenstore watch is
> already registered, and only for devices not already initialized (in
> XenbusStateInitWait state).
> 
> Cc: Ian Jackson 
> Cc: Wei Liu 
> Signed-off-by: Marek Marczykowski-Górecki 
> ---
>  tools/libxl/libxl.c | 33 +
>  1 file changed, 33 insertions(+)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 1c81239..dd20e29 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -4743,6 +4743,12 @@ int libxl_device_events_handler(libxl_ctx *ctx,
>  uint32_t domid;
>  libxl__ddomain ddomain;
>  char *be_path;
> +char **kinds = NULL, **domains = NULL, **devs = NULL;
> +const char *sstate;
> +char *state_path;
> +int state;
> +unsigned int nkinds, ndomains, ndevs;
> +int i, j, k;
>  
>  ddomain.ao = ao;
>  LIBXL_SLIST_INIT(&ddomain.guests);
> @@ -4762,6 +4768,33 @@ int libxl_device_events_handler(libxl_ctx *ctx,
>  be_path);
>  if (rc) goto out;
>  
> +kinds = libxl__xs_directory(gc, XBT_NULL, be_path, &nkinds);
> +if (kinds) {
> +for (i = 0; i < nkinds; i++) {
> +domains = libxl__xs_directory(gc, XBT_NULL,
> +GCSPRINTF("%s/%s", be_path, kinds[i]), &ndomains);
> +if (!domains)
> +continue;
> +for (j = 0; j < ndomains; j++) {
> +devs = libxl__xs_directory(gc, XBT_NULL,
> +GCSPRINTF("%s/%s/%s", be_path, kinds[i], 
> domains[j]), &ndevs);
> +if (!devs)
> +continue;
> +for (k = 0; k < ndevs; k++) {
> +state_path = GCSPRINTF("%s/%s/%s/%s/state",
> +be_path, kinds[i], domains[j], devs[k]);
> +rc = libxl__xs_read_checked(gc, XBT_NULL, state_path, 
> &sstate);
> +if (rc)
> +continue;
> +state = atoi(sstate);

Need to check sstate != NULL before passing it to atoi, because
libxl__xs_read_checked can return NULL if there is no such entry in
xenstore.

> +if (state == XenbusStateInitWait)
> +backend_watch_callback(egc, &ddomain.watch,
> +be_path, state_path);

Nit, indentation.

Wei.

> +}
> +}
> +}
> +}
> +
>  return AO_INPROGRESS;
>  
>  out:
> -- 
> 2.5.5
> 

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

Re: [Xen-devel] [PATCH 1/2] xen: fix a (latent) cpupool-related race during domain destroy

[Andrew Cooper]

On 14/07/16 07:41, Dario Faggioli wrote:
> So, during domain destruction, we do:
>  cpupool_rm_domain()[ in domain_destroy() ]
>  sched_destroy_domain() [ in complete_domain_destroy() ]
>
> Therefore, there's a window during which, from the
> scheduler's point of view, a domain is still there, but
> without it being part of any cpupool.
>
> In fact, cpupool_rm_domain() does d->cpupool=NULL,
> and we don't allow anything like that to hold, for
> any domain with the only exception of the idle one.
> And if we stuble upon such a domain, there are ASSERT()s
> and BUG_ON()s that do trigger.
>
> This never happens, right now, but only because none
> of the functions containing one of those sanity checks
> are called during the above described window. However,
> Credit2 goes (during load balancing) through the list
> of domains assigned to a certain runqueue, and not only
> the ones that are running or runnable. If one of those
> domains had cpupool_rm_domain() called upon itself
> already, and we call one of those functions which checks
> for d->cpupool!=NULL... Boom!
>
> For example, while doing Credit2 development, calling
> something similar to __vcpu_has_soft_affinity() from
> balance_load(), makes `xl shutdown ' reliably
> crash (this is how I discovered this).
>
> On the other hand, cpupool_rm_domain() "only" does
> cpupool related bookkeeping, and there's no harm
> postponing it a little bit.
>
> Finally, considering that, during domain initialization,
> we do:
>  cpupool_add_domain()
>  sched_init_domain()
>
> It looks like it makes much more sense for the domain
> destroy path to look like the opposite of it, i.e.:
>  sched_destroy_domain()
>  cpupool_rm_domain()
>
> This patch does that, and it's considered worth, as it
> fixes a bug, even if only a latent one.
>
> Signed-off-by: Dario Faggioli 

As the cpupool bookkeeping is very closely related to the scheduler
bookkeeping, how about having the sched_*_domain() functions involve the
cpupool_*_domain() functions?

That way it can't get out-of-order like this in the future.

~Andrew

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

[Xen-devel] [seabios baseline-only test] 66564: tolerable FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 66564 seabios real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66564/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 66547
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 66547
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 66547

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail 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:
 seabios  54e3a88609da074aaae2f04e592026ebf82169dc
baseline version:
 seabios  13213a252286372efa5f72b4119faafd5dff5db1

Last test of basis66547  2016-07-08 11:17:27 Z5 days
Testing same since66564  2016-07-14 01:47:47 Z0 days1 attempts


People who touched revisions under test:
  Kevin O'Connor 
  Paolo Bonzini 

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



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 54e3a88609da074aaae2f04e592026ebf82169dc
Author: Paolo Bonzini 
Date:   Thu Jul 7 16:00:40 2016 +0200

smp: restore MSRs on S3 resume

Currently the MTRRs and MSR_IA32_FEATURE_CONTROL are not restored on S3
resume.  Because these have to be applied to all processors, SMP setup
has to be added to S3 resume.

There are two differences between the boot and resume paths.  First,
romfile_* is not usable in the resume paths so we separate out the
remaining common code to a new smp_scan function.  Second, smp_msr has
to be walked on the BSP as well, so we extract that out of handle_smp
and into a new function smp_write_msrs.  Then, resume can call
smp_write_msrs on the BSP followed by smp_scan to initialize the APs.

Reported-by: Laszlo Ersek 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Kevin O'Connor 

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

Re: [Xen-devel] [PATCH v3 8/8] asm-x86/atomic.h: implement missing, add common prototypes

[Corneliu ZUZU]

On 7/14/2016 12:29 PM, Andrew Cooper wrote:

On 14/07/16 10:14, Corneliu ZUZU wrote:

- implement missing functions atomic_{sub,inc,dec}_return(), atomic_add_unless()
   on X86 and also add prototypes for them in common 

- add missing macro atomic_xchg for X86

Signed-off-by: Corneliu ZUZU


Reviewed-by: Andrew Cooper 


I'm not sure about atomic_sub_return(int i, atomic_t *v) implementation 
- is it ok? (calling arch_fetch_and_add(&v->counter, -i) with 2nd 
argument negative).


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

Re: [Xen-devel] [PATCH v3 8/8] asm-x86/atomic.h: implement missing, add common prototypes

[Andrew Cooper]

On 14/07/16 10:39, Corneliu ZUZU wrote:
> On 7/14/2016 12:29 PM, Andrew Cooper wrote:
>> On 14/07/16 10:14, Corneliu ZUZU wrote:
>>> - implement missing functions atomic_{sub,inc,dec}_return(), 
>>> atomic_add_unless()
>>>   on X86 and also add prototypes for them in common 
>>>
>>> - add missing macro atomic_xchg for X86
>>>
>>> Signed-off-by: Corneliu ZUZU 
>>
>> Reviewed-by: Andrew Cooper 
>
> I'm not sure about atomic_sub_return(int i, atomic_t *v)
> implementation - is it ok? (calling arch_fetch_and_add(&v->counter,
> -i) with 2nd argument negative).

Looks ok to me.  Everything is signed integers in the internals.

There is a boundary condition when passing INT_MIN, but those exist
elsewhere as well.

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

Re: [Xen-devel] [PATCH v3 8/8] asm-x86/atomic.h: implement missing, add common prototypes

[Corneliu ZUZU]

On 7/14/2016 12:44 PM, Andrew Cooper wrote:

On 14/07/16 10:39, Corneliu ZUZU wrote:

On 7/14/2016 12:29 PM, Andrew Cooper wrote:

On 14/07/16 10:14, Corneliu ZUZU wrote:

- implement missing functions atomic_{sub,inc,dec}_return(), atomic_add_unless()
   on X86 and also add prototypes for them in common 

- add missing macro atomic_xchg for X86

Signed-off-by: Corneliu ZUZU


Reviewed-by: Andrew Cooper 


I'm not sure about atomic_sub_return(int i, atomic_t *v) 
implementation - is it ok? (calling arch_fetch_and_add(&v->counter, 
-i) with 2nd argument negative).


Looks ok to me.  Everything is signed integers in the internals.

There is a boundary condition when passing INT_MIN, but those exist 
elsewhere as well.


~Andrew


Thanks, thought so too - there should be no difference bit-wise when 
adding an unsigned int converted from an int vs adding the int directly.


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

[Xen-devel] [PATCH] x86/emulate: add support for movq xmm,xmm/m64

[Mihai Donțu]

Signed-off-by: Mihai Donțu 
---
 tools/tests/x86_emulator/test_x86_emulator.c | 23 +++
 xen/arch/x86/x86_emulate/x86_emulate.c   |  7 ---
 2 files changed, 27 insertions(+), 3 deletions(-)

diff --git a/tools/tests/x86_emulator/test_x86_emulator.c 
b/tools/tests/x86_emulator/test_x86_emulator.c
index c7f572a..d18b2d2 100644
--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -697,6 +697,29 @@ int main(int argc, char **argv)
 else
 printf("skipped\n");
 
+printf("%-40s", "Testing movq %%xmm0, 32(%%eax)...");
+if ( stack_exec && cpu_has_mmx )
+{
+decl_insn(movq_to_mem2);
+
+asm volatile ( "pcmpgtb %%xmm0, %%xmm0\n"
+put_insn(movq_to_mem2, "movq %%xmm0, 32(%%eax)")
+:: );
+
+*((unsigned long *)res + 4) = 0xbdbdbdbdbdbdbdbd;
+set_insn(movq_to_mem2);
+regs.ecx= 0;
+regs.eax= (unsigned long)res;
+rc = x86_emulate(&ctxt, &emulops);
+if ( rc != X86EMUL_OKAY || !check_eip(movq_to_mem2) )
+goto fail;
+if ( *((unsigned long *)res + 4) )
+goto fail;
+printf("okay\n");
+}
+else
+printf("skipped\n");
+
 printf("%-40s", "Testing movdqu %xmm2,(%ecx)...");
 if ( stack_exec && cpu_has_sse2 )
 {
diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c 
b/xen/arch/x86/x86_emulate/x86_emulate.c
index fe594ba..fcf5694 100644
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -245,7 +245,7 @@ static uint8_t twobyte_table[256] = {
 ImplicitOps, ImplicitOps, ImplicitOps, ImplicitOps,
 ImplicitOps, ImplicitOps, ImplicitOps, ImplicitOps,
 /* 0xD0 - 0xDF */
-0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+0, 0, 0, 0, 0, 0, ImplicitOps|ModRM, 0, 0, 0, 0, 0, 0, 0, 0, 0,
 /* 0xE0 - 0xEF */
 0, 0, 0, 0, 0, 0, 0, ImplicitOps|ModRM, 0, 0, 0, 0, 0, 0, 0, 0,
 /* 0xF0 - 0xFF */
@@ -4412,6 +4412,7 @@ x86_emulate(
 case 0x7f: /* movq mm,mm/m64 */
/* {,v}movdq{a,u} xmm,xmm/m128 */
/* vmovdq{a,u} ymm,ymm/m256 */
+case 0xd6: /* movq xmm,xmm/m64 */
 {
 uint8_t *buf = get_stub(stub);
 struct fpu_insn_ctxt fic = { .insn_bytes = 5 };
@@ -4429,9 +4430,9 @@ x86_emulate(
 case vex_66:
 case vex_f3:
 host_and_vcpu_must_have(sse2);
-buf[0] = 0x66; /* movdqa */
+buf[0] = 0x66; /* movq, movdqa */
 get_fpu(X86EMUL_FPU_xmm, &fic);
-ea.bytes = 16;
+ea.bytes = (b == 0xd6 ? 8 : 16);
 break;
 case vex_none:
 if ( b != 0xe7 )
-- 
2.9.1


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

Re: [Xen-devel] [PATCH] xen: remove xenstore watches of backends when terminating qemu

[Juergen Gross]

On 13/07/16 14:31, Juergen Gross wrote:
> Xenstore watches of the /local/domain//backend/ directories
> are never removed. This can lead to a memory leak in xenstored,
> especially when xenstored is running in another domain (this will be
> the case either for a system with xenstore-stubdom, or with driver
> domains running qemu-based backends).
> 
> Avoid this problem by calling xs_unwatch() for these directories when
> terminating qemu.
> 
> Signed-off-by: Juergen Gross 

Please ignore this patch. It is not needed. The issue in xenstored is
_not_ due to not removed watches, but due to non freed memory after
sending a watch event.


Juergen


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

Re: [Xen-devel] [PATCH v3 7/8] arm/atomic.h: remove '__' prefix for __atomic_add_unless()

[Julien Grall]

Hi Corneliu,

On 14/07/16 10:14, Corneliu ZUZU wrote:

The built-in leading underscores ('__') don't serve any purpose, so rename
__atomic_add_unless() -> atomic_add_unless().


The leading underscores are from the Linux code. We decided to keep 
those files unmodified to help syncing atomic code.


So I am not in favor of dropping the '__'. If you want to use these 
functions in the common code, then a wrapper in "asm-arm/atomic.h" 
should be introduced.


Regards,



Signed-off-by: Corneliu ZUZU 
---
  xen/include/asm-arm/arm32/atomic.h | 2 +-
  xen/include/asm-arm/arm64/atomic.h | 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/include/asm-arm/arm32/atomic.h 
b/xen/include/asm-arm/arm32/atomic.h
index 78de60f..dc95518 100644
--- a/xen/include/asm-arm/arm32/atomic.h
+++ b/xen/include/asm-arm/arm32/atomic.h
@@ -121,7 +121,7 @@ static inline int atomic_cmpxchg(atomic_t *ptr, int old, 
int new)
return oldval;
  }

-static inline int __atomic_add_unless(atomic_t *v, int a, int u)
+static inline int atomic_add_unless(atomic_t *v, int a, int u)
  {
int oldval, newval;
unsigned long tmp;
diff --git a/xen/include/asm-arm/arm64/atomic.h 
b/xen/include/asm-arm/arm64/atomic.h
index d640bef..f0e83be 100644
--- a/xen/include/asm-arm/arm64/atomic.h
+++ b/xen/include/asm-arm/arm64/atomic.h
@@ -114,7 +114,7 @@ static inline int atomic_cmpxchg(atomic_t *ptr, int old, 
int new)
return oldval;
  }

-static inline int __atomic_add_unless(atomic_t *v, int a, int u)
+static inline int atomic_add_unless(atomic_t *v, int a, int u)
  {
int c, old;




--
Julien Grall

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

Re: [Xen-devel] [PATCH v3 7/8] arm/atomic.h: remove '__' prefix for __atomic_add_unless()

[Corneliu ZUZU]

On 7/14/2016 1:00 PM, Julien Grall wrote:

Hi Corneliu,

On 14/07/16 10:14, Corneliu ZUZU wrote:
The built-in leading underscores ('__') don't serve any purpose, so 
rename

__atomic_add_unless() -> atomic_add_unless().


The leading underscores are from the Linux code. We decided to keep 
those files unmodified to help syncing atomic code.


So I am not in favor of dropping the '__'. If you want to use these 
functions in the common code, then a wrapper in "asm-arm/atomic.h" 
should be introduced.


Regards,


Ok, great. Either add a wrapper or maybe keeping the underscores on X86 
too and not including it's prototype in . What would you 
prefer?


Zuzu C.

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

Re: [Xen-devel] [PATCH v2 1/5] asm-arm/atomic.h: fix arm32|arm64 macros duplication

[Corneliu ZUZU]

On 7/14/2016 12:26 PM, Julien Grall wrote:



On 14/07/16 06:11, Corneliu ZUZU wrote:

On 7/13/2016 10:12 PM, Julien Grall wrote:

Hi Corneliu,

On 13/07/2016 15:18, Corneliu ZUZU wrote:

Move duplicate macros between asm-arm/arm32/atomic.h and
asm-arm/arm64/atomic.h
to asm-arm/atomic.h.


asm-arm/arm*/atomic.h were a copy from Linux. I don't mind if we
diverge, however the file xen/arch/arm/README.primitives needs to be
update to mention the divergence with Linux.

Regards,



Julien,

AFAICT the README.LinuxPrimitives file specifies the Linux kernel
version from which the arm{32,64}/atomic.h files were imported as well
as the respective commit in the -Linux kernel- tree. I suppose that
information needn't be updated.
Could you be more specific on how I should modify that file?


To specify which helpers has been taken from Linux in those files. 
Until now, it was quite easy to figure out that we took all atomic_* 
helpers.


Regards,



Ok, will look into that.

I suppose also adding:

diff -u linux/arch/arm64/include/asm/atomic.h 
xen/include/asm-arm/arm64/atomic.h
diff -u linux/arch/arm/include/asm/atomic.h 
xen/include/asm-arm/arm32/atomic.h


as it's done for the others helps?

Zuzu C.

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

Re: [Xen-devel] [PATCH v2 1/5] asm-arm/atomic.h: fix arm32|arm64 macros duplication

[Julien Grall]

On 14/07/16 11:11, Corneliu ZUZU wrote:

On 7/14/2016 12:26 PM, Julien Grall wrote:



On 14/07/16 06:11, Corneliu ZUZU wrote:

On 7/13/2016 10:12 PM, Julien Grall wrote:

Hi Corneliu,

On 13/07/2016 15:18, Corneliu ZUZU wrote:

Move duplicate macros between asm-arm/arm32/atomic.h and
asm-arm/arm64/atomic.h
to asm-arm/atomic.h.


asm-arm/arm*/atomic.h were a copy from Linux. I don't mind if we
diverge, however the file xen/arch/arm/README.primitives needs to be
update to mention the divergence with Linux.

Regards,



Julien,

AFAICT the README.LinuxPrimitives file specifies the Linux kernel
version from which the arm{32,64}/atomic.h files were imported as well
as the respective commit in the -Linux kernel- tree. I suppose that
information needn't be updated.
Could you be more specific on how I should modify that file?


To specify which helpers has been taken from Linux in those files.
Until now, it was quite easy to figure out that we took all atomic_*
helpers.

Regards,



Ok, will look into that.

I suppose also adding:

diff -u linux/arch/arm64/include/asm/atomic.h
xen/include/asm-arm/arm64/atomic.h
diff -u linux/arch/arm/include/asm/atomic.h
xen/include/asm-arm/arm32/atomic.h

as it's done for the others helps?


No, the other files are a verbatim copy of the Linux headers. It is not 
the case here.


Something like:

"Only the following functions were taken from Linux:
  - ...
  - ...
  - ...
"

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v4] xen/arm: Add a clock property

[Julien Grall]

Hi Dirk,

On 14/07/16 07:31, Dirk Behme wrote:

On 13.07.2016 23:03, Michael Turquette wrote:

Quoting Dirk Behme (2016-07-13 11:56:30)

On 13.07.2016 20:43, Stefano Stabellini wrote:

On Wed, 13 Jul 2016, Dirk Behme wrote:

On 13.07.2016 00:26, Michael Turquette wrote:

Quoting Dirk Behme (2016-07-12 00:46:45)

Clocks described by this property are reserved for use by Xen,
and the OS
must not alter their state any way, such as disabling or gating a
clock,
or modifying its rate. Ensuring this may impose constraints on
parent
clocks or other resources used by the clock tree.


Note that clk_prepare_enable will not prevent the rate from changing
(clk_set_rate) or a parent from changing (clk_set_parent). The
only way
to do this currently would be to set the following flags on the
effected
clocks:

CLK_SET_RATE_GATE
CLK_SET_PARENT_GATE




Regarding setting flags, I think we already talked about that. I
think the
conclusion was that in our case its not possible to manipulate the
flags in
the OS as this isn't intended to be done in cases like ours.
Therefore no API
is exported for this.

I.e. if we need to set these flags, we have to do that in Xen where
we add the
clocks to the hypervisor node in the device tree. And not in the
kernel patch
discussed here.


These are internal Linux flags, aren't they?



I've been under the impression that you can set clock "flags" via the
device tree. Seems I need to re-check that ;)


Right, you cannot set flags from the device tree. Also, setting these
flags is done by the clock provider driver, not a consumer. Xen is the
consumer.



Ok, thanks, then I think we can forget about using flags for the issue
we are discussing here.

Best regards

Dirk

P.S.: Would it be an option to merge the v4 patch we are discussing
here, then? From the discussion until here, it sounds to me that it's
the best option we have at the moment. Maybe improving it in the future,
then.


I think it is a good start, although I would like to see some rationale 
in the code and commit message about the behavior of the Linux with 
those clocks after this patch because it does not match the "contract".


Regards,

--
Julien Grall

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

Re: [Xen-devel] Converting heap page_infos to contiguous virtual

[George Dunlap]

On 13/07/16 21:57, Boris Ostrovsky wrote:
> On 07/13/2016 04:34 PM, Andrew Cooper wrote:
>> On 13/07/2016 21:17, Boris Ostrovsky wrote:
>>> On 07/13/2016 04:02 PM, Andrew Cooper wrote:
 On 13/07/16 20:44, Boris Ostrovsky wrote:
> I would like to clear a bunch of Xen heap pages at once (i.e. not
> page-by-page).
>
> Greatly simplifying things, let's say I grab (in common/page_alloc.c)
> pg = page_list_remove_head(&heap(node, zone, order)
>
> and then
>
> mfn_t mfn =
> _mfn(page_to_mfn(pg));
> char *va = mfn_to_virt(mfn_x(mfn));
> memset(va, 0, 4096 * (1 << order));
>
>
> Would it be valid to this?
 In principle, yes.  The frame_table is in order.

 However, mfn_to_virt() will blow up for RAM above the 5TB boundary.  You
 need to map_domain_page() to get a mapping.
>>> Right, but that would mean going page-by-page, which I want to avoid.
>>>
>>> Now, DIRECTMAP_SIZE is ~128TB (if my math is correct) --- doesn't it
>>> imply that it maps this big a range contiguously (modulo PDX hole)?
>> Your maths is correct, and yet you will end up with problems if you
>> trust it.
>>
>> That is the magic mode for the idle and monitor pagetables.  In the
>> context of a 64bit PV guest, the cutoff is at 5TB, at which point you
>> venture into the virtual address space reserved for guest kernel use. 
>> (It is rather depressing that the 64bit PV guest ABI is the factor
>> limiting Xen's maximum RAM usage.)
> 
> I don't know whether it would make any difference but the pages that I am
> talking about are not in use by any guest, they are free. (This question
> is for scrubbing rewrite that I am working on. Which apparently you
> figured out judged by what you are saying below)

Is this start-of-day scrubbing (when there are no guests), or scrubbing
on guest destruction?

If the former, it seems like it might not be too difficult to arrange
that we're in a context that has all the RAM mapped.

 -George


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

Re: [Xen-devel] [PATCH v4] xen/arm: Add a clock property

[Stefano Stabellini]

On Wed, 13 Jul 2016, Michael Turquette wrote:
> Quoting Dirk Behme (2016-07-13 11:56:30)
> > On 13.07.2016 20:43, Stefano Stabellini wrote:
> > > On Wed, 13 Jul 2016, Dirk Behme wrote:
> > >> On 13.07.2016 00:26, Michael Turquette wrote:
> > >>> Quoting Dirk Behme (2016-07-12 00:46:45)
> >  Clocks described by this property are reserved for use by Xen, and the 
> >  OS
> >  must not alter their state any way, such as disabling or gating a 
> >  clock,
> >  or modifying its rate. Ensuring this may impose constraints on parent
> >  clocks or other resources used by the clock tree.
> > >>>
> > >>> Note that clk_prepare_enable will not prevent the rate from changing
> > >>> (clk_set_rate) or a parent from changing (clk_set_parent). The only way
> > >>> to do this currently would be to set the following flags on the effected
> > >>> clocks:
> > >>>
> > >>> CLK_SET_RATE_GATE
> > >>> CLK_SET_PARENT_GATE
> > >>
> > >>
> > >>
> > >> Regarding setting flags, I think we already talked about that. I think 
> > >> the
> > >> conclusion was that in our case its not possible to manipulate the flags 
> > >> in
> > >> the OS as this isn't intended to be done in cases like ours. Therefore 
> > >> no API
> > >> is exported for this.
> > >>
> > >> I.e. if we need to set these flags, we have to do that in Xen where we 
> > >> add the
> > >> clocks to the hypervisor node in the device tree. And not in the kernel 
> > >> patch
> > >> discussed here.
> > >
> > > These are internal Linux flags, aren't they?
> > 
> > 
> > I've been under the impression that you can set clock "flags" via the 
> > device tree. Seems I need to re-check that ;)
> 
> Right, you cannot set flags from the device tree. Also, setting these
> flags is done by the clock provider driver, not a consumer. Xen is the
> consumer.

Just for disambiguation, I guess you are referring to the Xen code in
Linux (such as arch/arm/xen/enlighten.c), right?

We have "Xen", the hypervisor, which runs before Linux and it is a
separate component running at EL2, and we have Xen support in Linux,
such as arch/arm/xen and drivers/xen. These are drivers to communicate
with the Xen hypervisor and other components in a Xen system.

In this case, the Xen hypervisor would be the owner of the clock. Xen
support in Linux, specifically arch/arm/xen/enlighten.c, only comes into
the picture to "warn" Linux that shouldn't really be messing with the
clocks. I guess that from a Linux clock driver point of view, it is a
consumer.

I hope that helps.


> > > They cannot be set in Xen.
> > >
> > > If the only way to make sure that clk_set_rate and clk_set_parent fail
> > > on one of the clocks "owned" by Xen is to set CLK_SET_RATE_GATE and
> > > CLK_SET_PARENT_GATE, we'll have to do that. Even if it means introducing
> > > a new internal Linux API.
> > >
> > >
> > >>> And then enable the clocks. All calls to clk_set_parent and clk_set_rate
> > >>> with those clocks in the path will fail, so long as they are prepared
> > >>> and enabled. This implementation detail is specific to Linux and
> > >>> definitely should not go into the binding.
> > >>>
> > 
> >  This property is used to proxy clocks for devices Xen has taken 
> >  ownership
> >  of, such as UARTs, for which the associated clock controller(s) remain
> >  under the control of Dom0.
> > >>>
> > >>> I'm still not completely sure about this type of layering and whether or
> > >>> not it is sane. If you want Xen to manage the clock controller, AND you
> > >>> want Linux guests or dom0 to consume those clocks and manipulate them in
> > >>> other drivers, then this solution won't work.
> > >>>
> > >>> Regards,
> > >>> Mike
> > >>>
> > 
> >  Up to now, the workaround for this has been to use the Linux kernel
> >  command line parameter 'clk_ignore_unused'. See Xen bug
> > 
> >  http://bugs.xenproject.org/xen/bug/45
> > 
> >  too.
> > 
> >  Signed-off-by: Dirk Behme 
> >  ---
> >  Changes in v4: Switch to the xen.txt description proposed by Mark:
> >  https://www.spinics.net/lists/arm-kernel/msg516158.html
> > 
> >  Changes in v3: Use the xen.txt description proposed by Michael. Thanks!
> > 
> >  Changes in v2: Drop the Linux implementation details like
> >  clk_disable_unused
> >  in xen.txt.
> > 
> >    Documentation/devicetree/bindings/arm/xen.txt | 12 +++
> >    arch/arm/xen/enlighten.c  | 47
> >  +++
> >    2 files changed, 59 insertions(+)
> > 
> >  diff --git a/Documentation/devicetree/bindings/arm/xen.txt
> >  b/Documentation/devicetree/bindings/arm/xen.txt
> >  index c9b9321..437e50b 100644
> >  --- a/Documentation/devicetree/bindings/arm/xen.txt
> >  +++ b/Documentation/devicetree/bindings/arm/xen.txt
> >  @@ -17,6 +17,18 @@ the following properties:
> >  A GIC node is also requir

Re: [Xen-devel] [PATCH v4] xen/arm: Add a clock property

[Stefano Stabellini]

On Thu, 14 Jul 2016, Dirk Behme wrote:
> On 13.07.2016 21:07, Stefano Stabellini wrote:
> > On Wed, 13 Jul 2016, Dirk Behme wrote:
> > > On 13.07.2016 20:35, Stefano Stabellini wrote:
> > > > On Tue, 12 Jul 2016, Dirk Behme wrote:
> > > > > Clocks described by this property are reserved for use by Xen, and the
> > > > > OS
> > > > > must not alter their state any way, such as disabling or gating a
> > > > > clock,
> > > > > or modifying its rate. Ensuring this may impose constraints on parent
> > > > > clocks or other resources used by the clock tree.
> > > > > 
> > > > > This property is used to proxy clocks for devices Xen has taken
> > > > > ownership
> > > > > of, such as UARTs, for which the associated clock controller(s) remain
> > > > > under the control of Dom0.
> > > > > 
> > > > > Up to now, the workaround for this has been to use the Linux kernel
> > > > > command line parameter 'clk_ignore_unused'. See Xen bug
> > > > > 
> > > > > http://bugs.xenproject.org/xen/bug/45
> > > > > 
> > > > > too.
> > > > > 
> > > > > Signed-off-by: Dirk Behme 
> > > > > ---
> > > > > Changes in v4: Switch to the xen.txt description proposed by Mark:
> > > > > 
> > > > > https://www.spinics.net/lists/arm-kernel/msg516158.html
> > > > > 
> > > > > Changes in v3: Use the xen.txt description proposed by Michael.
> > > > > Thanks!
> > > > > 
> > > > > Changes in v2: Drop the Linux implementation details like
> > > > > clk_disable_unused
> > > > >  in xen.txt.
> > > > > 
> > > > >   Documentation/devicetree/bindings/arm/xen.txt | 12 +++
> > > > >   arch/arm/xen/enlighten.c  | 47
> > > > > +++
> > > > >   2 files changed, 59 insertions(+)
> > > > > 
> > > > > diff --git a/Documentation/devicetree/bindings/arm/xen.txt
> > > > > b/Documentation/devicetree/bindings/arm/xen.txt
> > > > > index c9b9321..437e50b 100644
> > > > > --- a/Documentation/devicetree/bindings/arm/xen.txt
> > > > > +++ b/Documentation/devicetree/bindings/arm/xen.txt
> > > > > @@ -17,6 +17,18 @@ the following properties:
> > > > > A GIC node is also required.
> > > > > This property is unnecessary when booting Dom0 using ACPI.
> > > > > 
> > > > > +Optional properties:
> > > > > +
> > > > > +- clocks: a list of phandle + clock-specifier pairs
> > > > > +  Clocks described by this property are reserved for use by Xen, and
> > > > > the
> > > > > +  OS must not alter their state any way, such as disabling or gating
> > > > > a
> > > > > +  clock, or modifying its rate. Ensuring this may impose constraints
> > > > > on
> > > > > +  parent clocks or other resources used by the clock tree.
> > > > > +
> > > > > +  Note: this property is used to proxy clocks for devices Xen has
> > > > > taken
> > > > > +  ownership of, such as UARTs, for which the associated clock
> > > > > +  controller(s) remain under the control of Dom0.
> > > > > +
> > > > >   To support UEFI on Xen ARM virtual platforms, Xen populates the FDT
> > > > > "uefi" node
> > > > >   under /hypervisor with following parameters:
> > > > > 
> > > > > diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> > > > > index 47acb36..5c546d0 100644
> > > > > --- a/arch/arm/xen/enlighten.c
> > > > > +++ b/arch/arm/xen/enlighten.c
> > > > > @@ -24,6 +24,7 @@
> > > > >   #include 
> > > > >   #include 
> > > > >   #include 
> > > > > +#include 
> > > > >   #include 
> > > > >   #include 
> > > > >   #include 
> > > > > @@ -444,6 +445,52 @@ static int __init xen_pm_init(void)
> > > > >   }
> > > > >   late_initcall(xen_pm_init);
> > > > > 
> > > > > +/*
> > > > > + * Check if we want to register some clocks, that they
> > > > > + * are not freed because unused by clk_disable_unused().
> > > > > + * E.g. the serial console clock.
> > > > > + */
> > > > > +static int __init xen_arm_register_clks(void)
> > > > > +{
> > > > > + struct clk *clk;
> > > > > + struct device_node *xen_node;
> > > > > + unsigned int i, count;
> > > > > + int ret = 0;
> > > > > +
> > > > > + xen_node = of_find_compatible_node(NULL, NULL, "xen,xen");
> > > > > + if (!xen_node) {
> > > > > + pr_err("Xen support was detected before, but it has
> > > > > disappeared\n");
> > > > > + return -EINVAL;
> > > > > + }
> > > > 
> > > > Given that this is a late initcall, the following should work:
> > > > 
> > > >  if (!xen_domain())
> > > >  return -ENODEV;
> > > 
> > > 
> > > Hmm, sorry, "should work" for what?
> > 
> > As a Xen check, if (!xen_domain()) is the common pattern.
> > 
> > > We need the xen_node from device tree, anyway.
> > 
> > In that case, what don't you just use the global xen_node in this file?
> 
> 
> With the recent code there is no global xen_node any more:
> 
> https://lists.xen.org/archives/html/xen-devel/2016-06/msg02878.html

Ops, I was looking at upstream. I forgot about those.

___
Xen-devel mailing list
Xen-devel@l

Re: [Xen-devel] [PATCH v4] xen/arm: Add a clock property

[Dirk Behme]

On 14.07.2016 12:14, Julien Grall wrote:

Hi Dirk,

On 14/07/16 07:31, Dirk Behme wrote:

On 13.07.2016 23:03, Michael Turquette wrote:

Quoting Dirk Behme (2016-07-13 11:56:30)

On 13.07.2016 20:43, Stefano Stabellini wrote:

On Wed, 13 Jul 2016, Dirk Behme wrote:

On 13.07.2016 00:26, Michael Turquette wrote:

Quoting Dirk Behme (2016-07-12 00:46:45)

Clocks described by this property are reserved for use by Xen,
and the OS
must not alter their state any way, such as disabling or gating a
clock,
or modifying its rate. Ensuring this may impose constraints on
parent
clocks or other resources used by the clock tree.


Note that clk_prepare_enable will not prevent the rate from changing
(clk_set_rate) or a parent from changing (clk_set_parent). The
only way
to do this currently would be to set the following flags on the
effected
clocks:

CLK_SET_RATE_GATE
CLK_SET_PARENT_GATE




Regarding setting flags, I think we already talked about that. I
think the
conclusion was that in our case its not possible to manipulate the
flags in
the OS as this isn't intended to be done in cases like ours.
Therefore no API
is exported for this.

I.e. if we need to set these flags, we have to do that in Xen where
we add the
clocks to the hypervisor node in the device tree. And not in the
kernel patch
discussed here.


These are internal Linux flags, aren't they?



I've been under the impression that you can set clock "flags" via the
device tree. Seems I need to re-check that ;)


Right, you cannot set flags from the device tree. Also, setting these
flags is done by the clock provider driver, not a consumer. Xen is the
consumer.



Ok, thanks, then I think we can forget about using flags for the issue
we are discussing here.

Best regards

Dirk

P.S.: Would it be an option to merge the v4 patch we are discussing
here, then? From the discussion until here, it sounds to me that it's
the best option we have at the moment. Maybe improving it in the future,
then.


I think it is a good start, although I would like to see some rationale
in the code and commit message about the behavior of the Linux with
those clocks after this patch because it does not match the "contract".



I'd be happy about any wording proposals :)


Best regards

Dirk

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

Re: [Xen-devel] Converting heap page_infos to contiguous virtual

[Andrew Cooper]

On 14/07/16 11:25, George Dunlap wrote:
> On 13/07/16 21:57, Boris Ostrovsky wrote:
>> On 07/13/2016 04:34 PM, Andrew Cooper wrote:
>>> On 13/07/2016 21:17, Boris Ostrovsky wrote:
 On 07/13/2016 04:02 PM, Andrew Cooper wrote:
> On 13/07/16 20:44, Boris Ostrovsky wrote:
>> I would like to clear a bunch of Xen heap pages at once (i.e. not
>> page-by-page).
>>
>> Greatly simplifying things, let's say I grab (in common/page_alloc.c)
>> pg = page_list_remove_head(&heap(node, zone, order)
>>
>> and then
>>
>> mfn_t mfn =
>> _mfn(page_to_mfn(pg));
>> char *va = mfn_to_virt(mfn_x(mfn));
>> memset(va, 0, 4096 * (1 << order));
>>
>>
>> Would it be valid to this?
> In principle, yes.  The frame_table is in order.
>
> However, mfn_to_virt() will blow up for RAM above the 5TB boundary.  You
> need to map_domain_page() to get a mapping.
 Right, but that would mean going page-by-page, which I want to avoid.

 Now, DIRECTMAP_SIZE is ~128TB (if my math is correct) --- doesn't it
 imply that it maps this big a range contiguously (modulo PDX hole)?
>>> Your maths is correct, and yet you will end up with problems if you
>>> trust it.
>>>
>>> That is the magic mode for the idle and monitor pagetables.  In the
>>> context of a 64bit PV guest, the cutoff is at 5TB, at which point you
>>> venture into the virtual address space reserved for guest kernel use. 
>>> (It is rather depressing that the 64bit PV guest ABI is the factor
>>> limiting Xen's maximum RAM usage.)
>> I don't know whether it would make any difference but the pages that I am
>> talking about are not in use by any guest, they are free. (This question
>> is for scrubbing rewrite that I am working on. Which apparently you
>> figured out judged by what you are saying below)
> Is this start-of-day scrubbing (when there are no guests), or scrubbing
> on guest destruction?
>
> If the former, it seems like it might not be too difficult to arrange
> that we're in a context that has all the RAM mapped.

This will be runtime scrubbing of pages.  This topic has come up at
several hackathons.

Currently, domain destroy on a 1TB VM takes ~10 mins of synchronously
scrubbing RAM in continuations of the domain_kill() hypercall (and those
databases VMs really like their RAM).

ISTR the plan was to have a page_info "dirty" flag and a dirty page list
which is scrubbed while idle (or per-node, more likely). 
alloc_{dom/xen}_heap_pages() can pull off the dirty or free list, doing
a small synchronous scrub if it was dirty and needs to be clean. 
domain_kill() can just do a pagelist_splice() to move all memory onto
the dirty list, and save 10 minutes per TB.  The boot time memory scrub
can then be implemented in terms of setting the dirty flag by default,
rather than being an explicit step.

(Although I really shouldn't be second-guessing what Boris is planning
to implement ;p)

~Andrew

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

Re: [Xen-devel] [PATCH v4] xen/arm: Add a clock property

[Stefano Stabellini]

On Thu, 14 Jul 2016, Dirk Behme wrote:
> On 13.07.2016 23:03, Michael Turquette wrote:
> > Quoting Dirk Behme (2016-07-13 11:56:30)
> > > On 13.07.2016 20:43, Stefano Stabellini wrote:
> > > > On Wed, 13 Jul 2016, Dirk Behme wrote:
> > > > > On 13.07.2016 00:26, Michael Turquette wrote:
> > > > > > Quoting Dirk Behme (2016-07-12 00:46:45)
> > > > > > > Clocks described by this property are reserved for use by Xen, and
> > > > > > > the OS
> > > > > > > must not alter their state any way, such as disabling or gating a
> > > > > > > clock,
> > > > > > > or modifying its rate. Ensuring this may impose constraints on
> > > > > > > parent
> > > > > > > clocks or other resources used by the clock tree.
> > > > > > 
> > > > > > Note that clk_prepare_enable will not prevent the rate from changing
> > > > > > (clk_set_rate) or a parent from changing (clk_set_parent). The only
> > > > > > way
> > > > > > to do this currently would be to set the following flags on the
> > > > > > effected
> > > > > > clocks:
> > > > > > 
> > > > > > CLK_SET_RATE_GATE
> > > > > > CLK_SET_PARENT_GATE
> > > > > 
> > > > > 
> > > > > 
> > > > > Regarding setting flags, I think we already talked about that. I think
> > > > > the
> > > > > conclusion was that in our case its not possible to manipulate the
> > > > > flags in
> > > > > the OS as this isn't intended to be done in cases like ours. Therefore
> > > > > no API
> > > > > is exported for this.
> > > > > 
> > > > > I.e. if we need to set these flags, we have to do that in Xen where we
> > > > > add the
> > > > > clocks to the hypervisor node in the device tree. And not in the
> > > > > kernel patch
> > > > > discussed here.
> > > > 
> > > > These are internal Linux flags, aren't they?
> > > 
> > > 
> > > I've been under the impression that you can set clock "flags" via the
> > > device tree. Seems I need to re-check that ;)
> > 
> > Right, you cannot set flags from the device tree. Also, setting these
> > flags is done by the clock provider driver, not a consumer. Xen is the
> > consumer.
> 
> 
> Ok, thanks, then I think we can forget about using flags for the issue we are
> discussing here.
> 
> Best regards
> 
> Dirk
> 
> P.S.: Would it be an option to merge the v4 patch we are discussing here,
> then? From the discussion until here, it sounds to me that it's the best
> option we have at the moment. Maybe improving it in the future, then.

It might be a step in the right direction, but it doesn't really prevent
clk_set_rate from changing properties of a clock owned by Xen.  This
patch is incomplete. We need to understand at least what it would take
to have a complete solution.

Michael, do you have any suggestions on how it would be possible to set
CLK_SET_RATE_GATE and CLK_SET_PARENT_GATE for those clocks in a proper
way?

Like you wrote, I would imagine it needs to be done by the clock
provider driver. Maybe to do that, it would be easier to have a new
device tree property on the clock node, rather than listing phandle and
clock-specifier pairs under the Xen node?


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

Re: [Xen-devel] [PATCH v3 2/2] qdisk - hw/block/xen_disk: grant copy implementation

[Wei Liu]

On Wed, Jun 22, 2016 at 10:38:53AM +0200, Paulina Szubarczyk wrote:
> Copy data operated on during request from/to local buffers to/from
> the grant references.
> 
> Before grant copy operation local buffers must be allocated what is
> done by calling ioreq_init_copy_buffers. For the 'read' operation,
> first, the qemu device invokes the read operation on local buffers
> and on the completion grant copy is called and buffers are freed.
> For the 'write' operation grant copy is performed before invoking
> write by qemu device.
> 
> A new value 'feature_grant_copy' is added to recognize when the
> grant copy operation is supported by a guest.
> The body of the function 'ioreq_runio_qemu_aio' is moved to
> 'ioreq_runio_qemu_aio_blk' and in the 'ioreq_runio_qemu_aio' depending
> on the support for grant copy according checks, initialization, grant
> operation are made, then the 'ioreq_runio_qemu_aio_blk' function is
> called.
> 
> Signed-off-by: Paulina Szubarczyk 
> ---
> Changes since v2:
> - to use the xengnttab_* function directly added -lxengnttab to configure
>   and include  in include/hw/xen/xen_common.h
> - in ioreq_copy removed an out path, changed a log level, made explicit 
>   assignement to 'xengnttab_copy_grant_segment'
> * I did not change the way of testing if grant_copy operation is implemented.
>   As far as I understand if the code from gnttab_unimp.c is used then the 
> gnttab 
>   device is unavailable and the handler to gntdev would be invalid. But 
>   if the handler is valid then the ioctl should return operation 
> unimplemented 
>   if the gntdev does not implement the operation.
> 
>  configure   |   2 +-
>  hw/block/xen_disk.c | 171 
> 
>  include/hw/xen/xen_common.h |   2 +
>  3 files changed, 162 insertions(+), 13 deletions(-)
> 
> diff --git a/configure b/configure
> index e41876a..355d3fa 100755
> --- a/configure
> +++ b/configure
> @@ -1843,7 +1843,7 @@ fi
>  # xen probe
>  
>  if test "$xen" != "no" ; then
> -  xen_libs="-lxenstore -lxenctrl -lxenguest"
> +  xen_libs="-lxenstore -lxenctrl -lxenguest -lxengnttab"
>  

First thing, -lxengnttab should be in xen_stable_libs.

The probing needs to be more sophisticated.

You need to probe the new function your added as well. Just a few lines
below xen_stable_libs there is a section for hand-coded probing source
code, which you would need to modify.

Assuming your gnttab change will be merged into 4.8 (the release under
development at the moment), you need to have a separate program for it.

After you've done proper probing, you will know which version of Xen
this qemu is compiling against.  And then, there should be some fallback
mechanism to compile and run this qemu with older version of xen. This
is not too hard because you can guard your code with feature flag or
ifdef (please consult Stefan and Anthony which method to use).

Feel free to ask questions. I will try my best to explain.

>  
> +blkdev->feature_grant_copy =
> +(xengnttab_grant_copy(blkdev->xendev.gnttabdev, 0, NULL) == 
> 0);

This is a bit problematic. As this patch stands, it won't compile on
older version of Xen because there is no such function there.

Wei.

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

Re: [Xen-devel] [PATCH v4] xen/arm: Add a clock property

[Dirk Behme]

On 14.07.2016 12:38, Stefano Stabellini wrote:

On Thu, 14 Jul 2016, Dirk Behme wrote:

On 13.07.2016 23:03, Michael Turquette wrote:

Quoting Dirk Behme (2016-07-13 11:56:30)

On 13.07.2016 20:43, Stefano Stabellini wrote:

On Wed, 13 Jul 2016, Dirk Behme wrote:

On 13.07.2016 00:26, Michael Turquette wrote:

Quoting Dirk Behme (2016-07-12 00:46:45)

Clocks described by this property are reserved for use by Xen, and
the OS
must not alter their state any way, such as disabling or gating a
clock,
or modifying its rate. Ensuring this may impose constraints on
parent
clocks or other resources used by the clock tree.


Note that clk_prepare_enable will not prevent the rate from changing
(clk_set_rate) or a parent from changing (clk_set_parent). The only
way
to do this currently would be to set the following flags on the
effected
clocks:

CLK_SET_RATE_GATE
CLK_SET_PARENT_GATE




Regarding setting flags, I think we already talked about that. I think
the
conclusion was that in our case its not possible to manipulate the
flags in
the OS as this isn't intended to be done in cases like ours. Therefore
no API
is exported for this.

I.e. if we need to set these flags, we have to do that in Xen where we
add the
clocks to the hypervisor node in the device tree. And not in the
kernel patch
discussed here.


These are internal Linux flags, aren't they?



I've been under the impression that you can set clock "flags" via the
device tree. Seems I need to re-check that ;)


Right, you cannot set flags from the device tree. Also, setting these
flags is done by the clock provider driver, not a consumer. Xen is the
consumer.



Ok, thanks, then I think we can forget about using flags for the issue we are
discussing here.

Best regards

Dirk

P.S.: Would it be an option to merge the v4 patch we are discussing here,
then? From the discussion until here, it sounds to me that it's the best
option we have at the moment. Maybe improving it in the future, then.


It might be a step in the right direction, but it doesn't really prevent
clk_set_rate from changing properties of a clock owned by Xen.  This
patch is incomplete.



Let me ask then: Do we have a practical example where it's not 
sufficient practically?


To my understanding, Xen people have been happy with the 
"clk_ignore_unused" workaround since ~2 years, now [1]. And I think the 
"clk_ignore_unused" workaround does mainly the same like the patch 
discussed here. It doesn't care regarding clk_set_rate from changing 
properties, too?


While I agree that the patch theoretically incomplete, if nobody has a 
real world example I would think that from practical point of view it's 
sufficient in a first step.


If this is the case, I'd propose to fix the practical issue in a first 
step with a patch (this one) which is sufficient to fix the issues the 
Xen users have. And update the code for theoretical future issues in a 
second step.


Best regards

Dirk

[1] http://bugs.xenproject.org/xen/bug/45



We need to understand at least what it would take
to have a complete solution.

Michael, do you have any suggestions on how it would be possible to set
CLK_SET_RATE_GATE and CLK_SET_PARENT_GATE for those clocks in a proper
way?

Like you wrote, I would imagine it needs to be done by the clock
provider driver. Maybe to do that, it would be easier to have a new
device tree property on the clock node, rather than listing phandle and
clock-specifier pairs under the Xen node?


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

Re: [Xen-devel] [PATCH v3 7/8] arm/atomic.h: remove '__' prefix for __atomic_add_unless()

[Stefano Stabellini]

On Thu, 14 Jul 2016, Corneliu ZUZU wrote:
> On 7/14/2016 1:00 PM, Julien Grall wrote:
> > Hi Corneliu,
> > 
> > On 14/07/16 10:14, Corneliu ZUZU wrote:
> > > The built-in leading underscores ('__') don't serve any purpose, so rename
> > > __atomic_add_unless() -> atomic_add_unless().
> > 
> > The leading underscores are from the Linux code. We decided to keep those
> > files unmodified to help syncing atomic code.
> > 
> > So I am not in favor of dropping the '__'. If you want to use these
> > functions in the common code, then a wrapper in "asm-arm/atomic.h" should be
> > introduced.
> > 
> > Regards,
> 
> Ok, great. Either add a wrapper or maybe keeping the underscores on X86 too
> and not including it's prototype in . What would you prefer?

Add a wrapper

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

Re: [Xen-devel] [PATCH v3 6/8] asm-arm/atomic.h: atomic_{inc, dec}_return: macros to inline functions

[Stefano Stabellini]

On Thu, 14 Jul 2016, Corneliu ZUZU wrote:
> Turn atomic_inc_return and atomic_dec_return atomic.h macros to inline
> functions.
> 
> Signed-off-by: Corneliu ZUZU 

Reviewed-by: Stefano Stabellini 


>  xen/include/asm-arm/atomic.h | 13 ++---
>  1 file changed, 10 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/include/asm-arm/atomic.h b/xen/include/asm-arm/atomic.h
> index 78dad29..c69aae6 100644
> --- a/xen/include/asm-arm/atomic.h
> +++ b/xen/include/asm-arm/atomic.h
> @@ -130,9 +130,6 @@ static inline void _atomic_set(atomic_t *v, int i)
>  # error "unknown ARM variant"
>  #endif
>  
> -#define atomic_inc_return(v)(atomic_add_return(1, v))
> -#define atomic_dec_return(v)(atomic_sub_return(1, v))
> -
>  static inline int atomic_sub_and_test(int i, atomic_t *v)
>  {
>  return atomic_sub_return(i, v) == 0;
> @@ -143,6 +140,11 @@ static inline void atomic_inc(atomic_t *v)
>  atomic_add(1, v);
>  }
>  
> +static inline int atomic_inc_return(atomic_t *v)
> +{
> +return atomic_add_return(1, v);
> +}
> +
>  static inline int atomic_inc_and_test(atomic_t *v)
>  {
>  return atomic_add_return(1, v) == 0;
> @@ -153,6 +155,11 @@ static inline void atomic_dec(atomic_t *v)
>  atomic_sub(1, v);
>  }
>  
> +static inline int atomic_dec_return(atomic_t *v)
> +{
> +return atomic_sub_return(1, v);
> +}
> +
>  static inline int atomic_dec_and_test(atomic_t *v)
>  {
>  return atomic_sub_return(1, v) == 0;
> -- 
> 2.5.0
> 

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

Re: [Xen-devel] [PATCH v3 4/8] asm/atomic.h: common prototyping (add xen/atomic.h)

[Stefano Stabellini]

On Thu, 14 Jul 2016, Corneliu ZUZU wrote:
> Create a common-side  to establish, among others, prototypes of
> atomic functions called from common-code. Done to avoid introducing
> inconsistencies between arch-side  headers when we make subtle
> changes to one of them.
> 
> Some arm-side macros had to be turned into inline functions in the process.
> Removed outdated comment ("NB. I've [...]").
> 
> Signed-off-by: Corneliu ZUZU 
> Suggested-by: Andrew Cooper 
> Reviewed-by: Andrew Cooper 

Reviewed-by: Stefano Stabellini 


> Changed since v2:
>   * sample code for atomic_cmpxchg() (doc-comment in ) updated 
> to
> use atomic_read() instead of directly accessing v.counter
> ---
>  xen/include/asm-arm/atomic.h |  45 
>  xen/include/asm-x86/atomic.h | 103 +-
>  xen/include/xen/atomic.h | 171 
> +++
>  3 files changed, 202 insertions(+), 117 deletions(-)
>  create mode 100644 xen/include/xen/atomic.h
> 
> diff --git a/xen/include/asm-arm/atomic.h b/xen/include/asm-arm/atomic.h
> index 620c636..a79420a 100644
> --- a/xen/include/asm-arm/atomic.h
> +++ b/xen/include/asm-arm/atomic.h
> @@ -2,6 +2,7 @@
>  #define __ARCH_ARM_ATOMIC__
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -95,15 +96,6 @@ void __bad_atomic_size(void);
>  default: __bad_atomic_size(); break;\
>  }   \
>  })
> -
> -/*
> - * NB. I've pushed the volatile qualifier into the operations. This allows
> - * fast accessors such as _atomic_read() and _atomic_set() which don't give
> - * the compiler a fit.
> - */
> -typedef struct { int counter; } atomic_t;
> -
> -#define ATOMIC_INIT(i) { (i) }
>  
>  /*
>   * On ARM, ordinary assignment (str instruction) doesn't clear the local
> @@ -141,12 +133,35 @@ static inline void _atomic_set(atomic_t *v, int i)
>  #define atomic_inc_return(v)(atomic_add_return(1, v))
>  #define atomic_dec_return(v)(atomic_sub_return(1, v))
>  
> -#define atomic_sub_and_test(i, v)   (atomic_sub_return(i, v) == 0)
> -#define atomic_inc(v)   atomic_add(1, v)
> -#define atomic_inc_and_test(v)  (atomic_add_return(1, v) == 0)
> -#define atomic_dec(v)   atomic_sub(1, v)
> -#define atomic_dec_and_test(v)  (atomic_sub_return(1, v) == 0)
> -#define atomic_add_negative(i,v)(atomic_add_return(i, v) < 0)
> +static inline int atomic_sub_and_test(int i, atomic_t *v)
> +{
> +return atomic_sub_return(i, v) == 0;
> +}
> +
> +static inline void atomic_inc(atomic_t *v)
> +{
> +atomic_add(1, v);
> +}
> +
> +static inline int atomic_inc_and_test(atomic_t *v)
> +{
> +return atomic_add_return(1, v) == 0;
> +}
> +
> +static inline void atomic_dec(atomic_t *v)
> +{
> +atomic_sub(1, v);
> +}
> +
> +static inline int atomic_dec_and_test(atomic_t *v)
> +{
> +return atomic_sub_return(1, v) == 0;
> +}
> +
> +static inline int atomic_add_negative(int i, atomic_t *v)
> +{
> +return atomic_add_return(i, v) < 0;
> +}
>  
>  #define atomic_xchg(v, new) (xchg(&((v)->counter), new))
>  
> diff --git a/xen/include/asm-x86/atomic.h b/xen/include/asm-x86/atomic.h
> index 5f9f2dd..3e99b03 100644
> --- a/xen/include/asm-x86/atomic.h
> +++ b/xen/include/asm-x86/atomic.h
> @@ -2,6 +2,7 @@
>  #define __ARCH_X86_ATOMIC__
>  
>  #include 
> +#include 
>  #include 
>  
>  #define build_read_atomic(name, size, type, reg, barrier) \
> @@ -79,56 +80,21 @@ void __bad_atomic_size(void);
>  } \
>  })
>  
> -/*
> - * NB. I've pushed the volatile qualifier into the operations. This allows
> - * fast accessors such as _atomic_read() and _atomic_set() which don't give
> - * the compiler a fit.
> - */
> -typedef struct { int counter; } atomic_t;
> -
> -#define ATOMIC_INIT(i) { (i) }
> -
> -/**
> - * atomic_read - read atomic variable
> - * @v: pointer of type atomic_t
> - *
> - * Atomically reads the value of @v.
> - */
>  static inline int atomic_read(atomic_t *v)
>  {
>  return read_atomic(&v->counter);
>  }
>  
> -/**
> - * _atomic_read - read atomic variable non-atomically
> - * @v atomic_t
> - *
> - * Non-atomically reads the value of @v
> - */
>  static inline int _atomic_read(atomic_t v)
>  {
>  return v.counter;
>  }
>  
> -/**
> - * atomic_set - set atomic variable
> - * @v: pointer of type atomic_t
> - * @i: required value
> - *
> - * Atomically sets the value of @v to @i.
> - */
>  static inline void atomic_set(atomic_t *v, int i)
>  {
>  write_atomic(&v->counter, i);
>  }
>  
> -/**
> - * _atomic_set - set atomic variable non-atomically
> - * @v: pointer of type atomic_t
> - * @i: required value
> - *
> - * Non-atomically sets the value of @v to @i.
> - */
>  static inline void _atomic_set(atomic_t *v, int i)
>  {
>  v->counter = i;
> @@ -139,13 +105,6 @@ static inline int atomic_cmpxchg(atomic_t *v, int old, 
> int new)
> 

Re: [Xen-devel] [PATCH 1/9] xen/arm: Simply the definition of PAGE_SIZE by using the macro _AC

[Stefano Stabellini]

On Wed, 22 Jun 2016, Julien Grall wrote:
> The macro _AC is used to define constant for both assembly and C.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


>  xen/include/asm-arm/config.h | 7 +--
>  1 file changed, 1 insertion(+), 6 deletions(-)
> 
> diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
> index 9417be6..a96f845 100644
> --- a/xen/include/asm-arm/config.h
> +++ b/xen/include/asm-arm/config.h
> @@ -176,12 +176,7 @@
>  #define FIXMAP_ACPI_END(FIXMAP_ACPI_BEGIN + NUM_FIXMAP_ACPI_PAGES - 1)  
> /* End mappings of ACPI tables */
>  
>  #define PAGE_SHIFT  12
> -
> -#ifndef __ASSEMBLY__
> -#define PAGE_SIZE   (1L << PAGE_SHIFT)
> -#else
> -#define PAGE_SIZE   (1 << PAGE_SHIFT)
> -#endif
> +#define PAGE_SIZE   (_AC(1,L) << PAGE_SHIFT)
>  #define PAGE_MASK   (~(PAGE_SIZE-1))
>  #define PAGE_FLAG_MASK  (~0)
>  
> -- 
> 1.9.1
> 

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

Re: [Xen-devel] [PATCH 2/9] xen/arm: traps: Second attempt to correctly use the content of HPFAR_EL2

[Stefano Stabellini]

On Wed, 22 Jun 2016, Julien Grall wrote:
> Commit c051618 "xen/arm: traps: Correctly interpret the content of the
> register HPFAR_EL2" attempted to fix the interpretation of HPFAR_EL2.
> 
> However, the register contains a 4KB-aligned address. This means that
> the reported address is not directly usable to know the faulting IPA.
> The offset in the 4KB page can be found by looking at the associated virtual
> address (FAR_EL2/HDFAR).
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


> ---
> 
> Cc: Tamas K Lengyel 
> 
> I overlooked the usage of HPFAR_EL2. This is currently only affecting
> memaccess. Rather that return that exact address, the address will
> always be the base addres of the 4KB page.
> 
> This would need to be backported up to Xen 4.6.
> ---
>  xen/arch/arm/traps.c | 12 
>  1 file changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 0709deb..742f7d3 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -2371,11 +2371,15 @@ done:
>  if (first) unmap_domain_page(first);
>  }
>  
> -static inline paddr_t get_faulting_ipa(void)
> +static inline paddr_t get_faulting_ipa(vaddr_t gva)
>  {
>  register_t hpfar = READ_SYSREG(HPFAR_EL2);
> +paddr_t ipa;
>  
> -return ((paddr_t)(hpfar & HPFAR_MASK) << (12 - 4));
> +ipa = (paddr_t)(hpfar & HPFAR_MASK) << (12 - 4);
> +ipa |= gva & ~PAGE_MASK;
> +
> +return ipa;
>  }
>  
>  static void do_trap_instr_abort_guest(struct cpu_user_regs *regs,
> @@ -2396,7 +2400,7 @@ static void do_trap_instr_abort_guest(struct 
> cpu_user_regs *regs,
>  };
>  
>  if ( hsr.iabt.s1ptw )
> -gpa = get_faulting_ipa();
> +gpa = get_faulting_ipa(gva);
>  else
>  {
>  /*
> @@ -2445,7 +2449,7 @@ static void do_trap_data_abort_guest(struct 
> cpu_user_regs *regs,
>  #endif
>  
>  if ( dabt.s1ptw )
> -info.gpa = get_faulting_ipa();
> +info.gpa = get_faulting_ipa(info.gva);
>  else
>  {
>  rc = gva_to_ipa(info.gva, &info.gpa, GV2M_READ);
> -- 
> 1.9.1
> 

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

Re: [Xen-devel] [PATCH 3/9] xen/arm: traps: Data Abort are always unconditional

[Stefano Stabellini]

On Wed, 22 Jun 2016, Julien Grall wrote:
> The HSR encoding for an exception from a data abort does not contain a
> conditional code (see G6-4264 in ARM DDI 0487A.i) because they are
> always conditional.
> 
> So drop the pointless condition check.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


>  xen/arch/arm/traps.c | 6 --
>  1 file changed, 6 deletions(-)
> 
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 742f7d3..2e84b5a 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -2435,12 +2435,6 @@ static void do_trap_data_abort_guest(struct 
> cpu_user_regs *regs,
>  int rc;
>  mmio_info_t info;
>  
> -if ( !check_conditional_instr(regs, hsr) )
> -{
> -advance_pc(regs, hsr);
> -return;
> -}
> -
>  info.dabt = dabt;
>  #ifdef CONFIG_ARM_32
>  info.gva = READ_CP32(HDFAR);
> -- 
> 1.9.1
> 

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

Re: [Xen-devel] [PATCH 4/9] xen/arm: traps: Simplify the switch in do_trap_*_abort_guest

[Stefano Stabellini]

On Wed, 22 Jun 2016, Julien Grall wrote:
> The fault status we care are all the form xx where xx is the lookup

 ^ in the form of

> level that gave the fault. We can simply the code by masking the 2 least

   ^ simplify

> significant bits.
> 
> Signed-off-by: Julien Grall 
> ---
>  xen/arch/arm/traps.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 2e84b5a..8a3fac0 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -2388,9 +2388,9 @@ static void do_trap_instr_abort_guest(struct 
> cpu_user_regs *regs,
>  int rc;
>  register_t gva = READ_SYSREG(FAR_EL2);
>  
> -switch ( hsr.iabt.ifsc & 0x3f )
> +switch ( hsr.iabt.ifsc & ~FSC_LL_MASK )
>  {
> -case FSC_FLT_PERM ... FSC_FLT_PERM + 3:
> +case FSC_FLT_PERM:
>  {

This is a good improvement in code readability. I would go one step
further and replace the switch with a simple if.


>  paddr_t gpa;
>  const struct npfec npfec = {
> @@ -2451,9 +2451,9 @@ static void do_trap_data_abort_guest(struct 
> cpu_user_regs *regs,
>  return; /* Try again */
>  }
>  
> -switch ( dabt.dfsc & 0x3f )
> +switch ( dabt.dfsc & ~FSC_LL_MASK )
>  {
> -case FSC_FLT_PERM ... FSC_FLT_PERM + 3:
> +case FSC_FLT_PERM:
>  {
>  const struct npfec npfec = {
>  .read_access = !dabt.write,

same here


> -- 
> 1.9.1
> 

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

Re: [Xen-devel] [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Wei Liu]

On Wed, Jul 13, 2016 at 01:08:57PM -0400, Boris Ostrovsky wrote:
> On 07/13/2016 11:22 AM, Julien Grall wrote:
> > Hello,
> >
> > On 12/07/2016 17:58, Boris Ostrovsky wrote:
> >> On 07/12/2016 12:10 PM, Julien Grall wrote:
> >>> On 12/07/2016 16:08, Boris Ostrovsky wrote:
>  On 07/12/2016 10:57 AM, Shannon Zhao wrote:
> > On 2016年07月12日 22:50, Wei Liu wrote:
> >> On Tue, Jul 12, 2016 at 10:42:07PM +0800, Shannon Zhao wrote:
> >> Does it mean we would need to update the slack
> >> to take into account the ACPI
> >> blob?
> >> Yes, we need to take into account the ACPI blob.
> >> Probably not in the
> >> slack but directly in mam_memkb.
> >> Sorry, I'm not sure understand this. I found the
> >> b_info->max_memkb but
> >> didn't find the slack you said. And how to fix this? Update
> >> b_info->max_memkb or the slack?
> >> Can you calculate the size of your payload and add that to
> >> max_memkb?
> >>
>  Yeah, but the size will be changed if we change the tables in the
>  future
>  and this also should consider x86, right?
> >> That could easily be solved by introducing a function to
> >> calculate the
> >> size, right?
> > Oh, I'm not familiar with this. Let's clarify on this. It can add the
> > size to max_memkb after generating the ACPI tables and before loading
> > the tables to guest space and it doesn't have to add the size at
> > libxl__domain_build_info_setdefault(), right?
> 
>  This was discussed before: ACPI tables are part of RAM whose size is
>  specified by the config file (and is reflected in max_memkb I
>  believe).
>  It may not be presented to the guest as RAM (i.e. on x86 it is labeled
>  by BIOS (or whoever) as a dedicated type in e820) but it still resides
>  in DIMMs.
> >>>
> >>> I don't think this was the conclusion of the thread. IHMO, "maxmem" is
> >>> the amount of RAM a guest could effectively use.
> >>>
> >>> Whilst the ACPI tables will be in the DIMM from the host point of
> >>> view. From a guest point of view it will be a ROM.
> >>
> >> The config file specifies resources provided by the host. How the guest
> >> views those resources is not important, I think.
> >
> > This would need to be clarified. For instance special pages (Xenstore,
> > Console...) are RAM from the host point of view but not taken into
> > account in the "maxmem" provided by the user. For my understanding,
> > some kB of the slack is used for that.
> 
> 
> Are these pages part of guest's address space?
> 
> 
> >
> >>
> >>>
> >>> It will affect some others part of the guest if we don't increment the
> >>> "maxmem" requested by the user. For ARM the ACPI blob will be exposed
> >>> at a specific address that is outside of the guest RAM (see the guest
> >>> memory layout in public/arch-arm.h).
> >>>
> >>> We chose this solution over putting in the RAM because the ACPI tables
> >>> are not easily relocatable (compare to the device tree, initrd and
> >>> kernel) so we could not take advantage of superpage in both stage-2
> >>> (hypervisor) and stage-1 (kernel) page table.
> >>
> >> Maybe this is something ARM-specific then. For x86 we will want to keep
> >> maxmem unchanged.
> >
> > I don't think what I described in my previous mail is ARM-specific.
> > The pressure will be more important on the TLBs, if Xen does not use
> > superpage in the stage 2 page tables (i.e EPT for x86) no matter the
> > architecture.
> >
> > IHMO, this seems to be a bigger drawback compare to add few more
> > kilobytes to maxmem in the toolstack for the ACPI blob. You will loose
> > them when creating the intermediate page table in any case.
> 
> 
> Why not have the guest ask for more memory in the config file then?
> 
> (OK, I can see that they can't ask for a few KB since we have MB
> resolution but they can ask for an extra 1MB)
> 

It would be trivial to have another option in xl.cfg to allow MB
granularity. But I don't think that's a good idea. Asking for more
memory when you don't really know how much is enough is not very useful.
If an admin can know how much is needed, surely the library can be
taught to obtain that knowledge, too.

We need to decide which model we should go with. And, if we decide to
diverge, document the difference between x86 and ARM model.

Wei.

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

[Xen-devel] [qemu-mainline test] 97282: regressions - trouble: broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 3 host-install(3) broken 
REGR. vs. 96791
 test-amd64-amd64-libvirt-xsm 11 guest-start   fail REGR. vs. 96791
 test-amd64-amd64-libvirt-pair 20 guest-start/debian   fail REGR. vs. 96791
 test-amd64-amd64-libvirt 11 guest-start   fail REGR. vs. 96791
 test-amd64-amd64-xl-qcow2 9 debian-di-install fail REGR. vs. 96791
 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 96791
 test-amd64-amd64-libvirt-vhd  9 debian-di-install fail REGR. vs. 96791

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

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-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail 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-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 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-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 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-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-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

version targeted for testing:
 qemuu9ec3025660bcd2f9d308efaf0618453f3696a137
baseline version:
 qemuu4f4a9ca4a4386c137301b3662faba076455ff15a

Last test of basis96791  2016-07-08 12:20:07 Z5 days
Failing since 97271  2016-07-13 13:44:26 Z0 days2 attempts
Testing same since97282  2016-07-14 00:13:27 Z0 days1 attempts


People who touched revisions under test:
  Alex Bennée 
  Alexander Yarygin 
  Anthony PERARD 
  Ashok Raj 
  Cornelia Huck 
  Daniel P. Berrange 
  David Gibson 
  David Hildenbrand 
  Denis V. Lunev 
  Eduardo Habkost 
  Eric Blake 
  Eugene (jno) Dvurechenski 
  Evgeny Yakovlev 
  Gerd Hoffmann 
  Gonglei 
  Haibin Wang 
  Haozhong Zhang 
  Igor Mammedov 
  James Hogan 
  Jeff Cody 
  Jing Liu 
  Leon Alrae 
  Mark Cave-Ayland 
  Markus Armbruster 
  Paolo Bonzini 
  Paul Burton 
  Peter Lieven 
  Peter Maydell 
  Pierre Morel 
  Richard Henderson 
  Samuel Damashek 
  Sascha Silbe 
  Sergey Sorokin 
  Stanislav Shmarov 
  Yi Min Zhao 
  Yongbok Kim 
  Zhang Shuaiyi 

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

Re: [Xen-devel] [PATCH 4/9] xen/arm: traps: Simplify the switch in do_trap_*_abort_guest

[Julien Grall]

Hi Stefano,

On 14/07/16 12:12, Stefano Stabellini wrote:

On Wed, 22 Jun 2016, Julien Grall wrote:

The fault status we care are all the form xx where xx is the lookup


  ^ in the form of


level that gave the fault. We can simply the code by masking the 2 least


^ simplify


significant bits.

Signed-off-by: Julien Grall 
---
  xen/arch/arm/traps.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 2e84b5a..8a3fac0 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2388,9 +2388,9 @@ static void do_trap_instr_abort_guest(struct 
cpu_user_regs *regs,
  int rc;
  register_t gva = READ_SYSREG(FAR_EL2);

-switch ( hsr.iabt.ifsc & 0x3f )
+switch ( hsr.iabt.ifsc & ~FSC_LL_MASK )
  {
-case FSC_FLT_PERM ... FSC_FLT_PERM + 3:
+case FSC_FLT_PERM:
  {


This is a good improvement in code readability. I would go one step
further and replace the switch with a simple if.


I would prefer to keep the switch case here. The patch #7 adds another 
case for do_trap_data_abort_guest because we should not emulate MMIO for 
any kind of fault as it is done today.


Also, I have got more fixes coming up which require the switch here.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Julien Grall]

Hello,

On 13/07/16 18:08, Boris Ostrovsky wrote:

On 07/13/2016 11:22 AM, Julien Grall wrote:

On 12/07/2016 17:58, Boris Ostrovsky wrote:

The config file specifies resources provided by the host. How the guest
views those resources is not important, I think.


This would need to be clarified. For instance special pages (Xenstore,
Console...) are RAM from the host point of view but not taken into
account in the "maxmem" provided by the user. For my understanding,
some kB of the slack is used for that.



Are these pages part of guest's address space?


Yes, they are used to communicate between the guest and the backend 
(xenconsole, xenstore,...).


Regards,

--
Julien Grall

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass

version targeted for testing:
 seabios  ae3f78f3fa1a4c32600132df2f78fa31b6d775f1
baseline version:
 seabios  54e3a88609da074aaae2f04e592026ebf82169dc

Last test of basis97272  2016-07-13 13:44:49 Z0 days
Testing same since97283  2016-07-14 01:44:45 Z0 days1 attempts


People who touched revisions under test:
  Kevin O'Connor 

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



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

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

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

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


Pushing revision :

+ branch=seabios
+ revision=ae3f78f3fa1a4c32600132df2f78fa31b6d775f1
+ . ./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 seabios 
ae3f78f3fa1a4c32600132df2f78fa31b6d775f1
+ branch=seabios
+ revision=ae3f78f3fa1a4c32600132df2f78fa31b6d775f1
+ . ./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=seabios
+ xenbranch=xen-unstable
+ '[' xseabios = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' xae3f78f3fa1a4c32600132df2f7

Re: [Xen-devel] [BUG] kernel BUG at drivers/block/xen-blkfront.c:1711

[Evgenii Shatokhin]

On 11.07.2016 15:04, Bob Liu wrote:



On 07/11/2016 04:50 PM, Evgenii Shatokhin wrote:

On 06.06.2016 11:42, Dario Faggioli wrote:

Just Cc-ing some Linux, block, and Xen on CentOS people...



Ping.

Any suggestions how to debug this or what might cause the problem?

Obviously, we cannot control Xen on the Amazon's servers. But perhaps there is 
something we can do at the kernel's side, is it?


On Mon, 2016-06-06 at 11:24 +0300, Evgenii Shatokhin wrote:

(Resending this bug report because the message I sent last week did
not
make it to the mailing list somehow.)

Hi,

One of our users gets kernel panics from time to time when he tries
to
use his Amazon EC2 instance with CentOS7 x64 in it [1]. Kernel panic
happens within minutes from the moment the instance starts. The
problem
does not show up every time, however.

The user first observed the problem with a custom kernel, but it was
found later that the stock kernel 3.10.0-327.18.2.el7.x86_64 from
CentOS7 was affected as well.


Please try this patch:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7b0767502b5db11cb1f0daef2d01f6d71b1192dc

Regards,
Bob



Unfortunately, it did not help. The same BUG_ON() in 
blkfront_setup_indirect() still triggers in our kernel based on RHEL's 
3.10.0-327.18.2, where I added the patch.


As far as I can see, the patch makes sure the indirect pages are added 
to the list only if (!info->feature_persistent) holds. I suppose it 
holds in our case and the pages are added to the list because the 
triggered BUG_ON() is here:


if (!info->feature_persistent && info->max_indirect_segments) {
<...>
BUG_ON(!list_empty(&info->indirect_pages));
<...>
}

So the problem is still out there somewhere, it seems.

Regards,
Evgenii



The part of the system log he was able to retrieve is attached. Here
is
the bug info, for convenience:


[2.246912] kernel BUG at drivers/block/xen-blkfront.c:1711!
[2.246912] invalid opcode:  [#1] SMP
[2.246912] Modules linked in: ata_generic pata_acpi
crct10dif_pclmul
crct10dif_common crc32_pclmul crc32c_intel ghash_clmulni_intel
xen_netfront xen_blkfront(+) aesni_intel lrw ata_piix gf128mul
glue_helper ablk_helper cryptd libata serio_raw floppy sunrpc
dm_mirror
dm_region_hash dm_log dm_mod scsi_transport_iscsi
[2.246912] CPU: 1 PID: 50 Comm: xenwatch Not tainted
3.10.0-327.18.2.el7.x86_64 #1
[2.246912] Hardware name: Xen HVM domU, BIOS 4.2.amazon
12/07/2015
[2.246912] task: 8800e9fcb980 ti: 8800e98bc000 task.ti:
8800e98bc000
[2.246912] RIP: 0010:[]  []
blkfront_setup_indirect+0x41f/0x430 [xen_blkfront]
[2.246912] RSP: 0018:8800e98bfcd0  EFLAGS: 00010283
[2.246912] RAX: 8800353e15c0 RBX: 8800e98c52c8 RCX:
0020
[2.246912] RDX: 8800353e15b0 RSI: 8800e98c52b8 RDI:
8800353e15d0
[2.246912] RBP: 8800e98bfd20 R08: 8800353e15b0 R09:
8800eb403c00
[2.246912] R10: a0155532 R11: ffe8 R12:
8800e98c4000
[2.246912] R13: 8800e98c52b8 R14: 0020 R15:
8800353e15c0
[2.246912] FS:  () GS:8800efc2()
knlGS:
[2.246912] CS:  0010 DS:  ES:  CR0: 80050033
[2.246912] CR2: 7f1b615ef000 CR3: e2b44000 CR4:
001406e0
[2.246912] DR0:  DR1:  DR2:

[2.246912] DR3:  DR6: 0ff0 DR7:
0400
[2.246912] Stack:
[2.246912]  0020 0001 0020a0157217
0100e98bfdbc
[2.246912]  27efa3ef 8800e98bfdbc 8800e98ce000
8800e98c4000
[2.246912]  8800e98ce040 0001 8800e98bfe08
a0155d4c
[2.246912] Call Trace:
[2.246912]  [] blkback_changed+0x4ec/0xfc8
[xen_blkfront]
[2.246912]  [] ? xenbus_gather+0x170/0x190
[2.246912]  [] ? __slab_free+0x10e/0x277
[2.246912]  []
xenbus_otherend_changed+0xad/0x110
[2.246912]  [] ? xenwatch_thread+0x77/0x180
[2.246912]  [] backend_changed+0x13/0x20
[2.246912]  [] xenwatch_thread+0x66/0x180
[2.246912]  [] ? wake_up_atomic_t+0x30/0x30
[2.246912]  [] ?
unregister_xenbus_watch+0x1f0/0x1f0
[2.246912]  [] kthread+0xcf/0xe0
[2.246912]  [] ?
kthread_create_on_node+0x140/0x140
[2.246912]  [] ret_from_fork+0x58/0x90
[2.246912]  [] ?
kthread_create_on_node+0x140/0x140
[2.246912] Code: e1 48 85 c0 75 ce 49 8d 84 24 40 01 00 00 48 89
45
b8 e9 91 fd ff ff 4c 89 ff e8 8d ae 06 e1 e9 f2 fc ff ff 31 c0 e9 2e
fe
ff ff <0f> 0b e8 9a 57 f2 e0 0f 0b 0f 1f 84 00 00 00 00 00 0f 1f 44
00
[2.246912] RIP  []
blkfront_setup_indirect+0x41f/0x430 [xen_blkfront]
[2.246912]  RSP 
[2.491574] ---[ end trace 8a9b992812627c71 ]---
[2.495618] Kernel panic - not syncing: Fatal exception


Xen versi

Re: [Xen-devel] [BUG] kernel BUG at drivers/block/xen-blkfront.c:1711

[Bob Liu]

On 07/14/2016 07:49 PM, Evgenii Shatokhin wrote:
> On 11.07.2016 15:04, Bob Liu wrote:
>>
>>
>> On 07/11/2016 04:50 PM, Evgenii Shatokhin wrote:
>>> On 06.06.2016 11:42, Dario Faggioli wrote:
 Just Cc-ing some Linux, block, and Xen on CentOS people...

>>>
>>> Ping.
>>>
>>> Any suggestions how to debug this or what might cause the problem?
>>>
>>> Obviously, we cannot control Xen on the Amazon's servers. But perhaps there 
>>> is something we can do at the kernel's side, is it?
>>>
 On Mon, 2016-06-06 at 11:24 +0300, Evgenii Shatokhin wrote:
> (Resending this bug report because the message I sent last week did
> not
> make it to the mailing list somehow.)
>
> Hi,
>
> One of our users gets kernel panics from time to time when he tries
> to
> use his Amazon EC2 instance with CentOS7 x64 in it [1]. Kernel panic
> happens within minutes from the moment the instance starts. The
> problem
> does not show up every time, however.
>
> The user first observed the problem with a custom kernel, but it was
> found later that the stock kernel 3.10.0-327.18.2.el7.x86_64 from
> CentOS7 was affected as well.
>>
>> Please try this patch:
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7b0767502b5db11cb1f0daef2d01f6d71b1192dc
>>
>> Regards,
>> Bob
>>
> 
> Unfortunately, it did not help. The same BUG_ON() in 
> blkfront_setup_indirect() still triggers in our kernel based on RHEL's 
> 3.10.0-327.18.2, where I added the patch.
> 
> As far as I can see, the patch makes sure the indirect pages are added to the 
> list only if (!info->feature_persistent) holds. I suppose it holds in our 
> case and the pages are added to the list because the triggered BUG_ON() is 
> here:
> 
> if (!info->feature_persistent && info->max_indirect_segments) {
> <...>
> BUG_ON(!list_empty(&info->indirect_pages));
> <...>
> }
> 

That's odd.
Could you please try to reproduce this issue with a recent upstream kernel?

Thanks,
Bob

> So the problem is still out there somewhere, it seems.
> 
> Regards,
> Evgenii
> 
>
> The part of the system log he was able to retrieve is attached. Here
> is
> the bug info, for convenience:
>
> 
> [2.246912] kernel BUG at drivers/block/xen-blkfront.c:1711!
> [2.246912] invalid opcode:  [#1] SMP
> [2.246912] Modules linked in: ata_generic pata_acpi
> crct10dif_pclmul
> crct10dif_common crc32_pclmul crc32c_intel ghash_clmulni_intel
> xen_netfront xen_blkfront(+) aesni_intel lrw ata_piix gf128mul
> glue_helper ablk_helper cryptd libata serio_raw floppy sunrpc
> dm_mirror
> dm_region_hash dm_log dm_mod scsi_transport_iscsi
> [2.246912] CPU: 1 PID: 50 Comm: xenwatch Not tainted
> 3.10.0-327.18.2.el7.x86_64 #1
> [2.246912] Hardware name: Xen HVM domU, BIOS 4.2.amazon
> 12/07/2015
> [2.246912] task: 8800e9fcb980 ti: 8800e98bc000 task.ti:
> 8800e98bc000
> [2.246912] RIP: 0010:[]  []
> blkfront_setup_indirect+0x41f/0x430 [xen_blkfront]
> [2.246912] RSP: 0018:8800e98bfcd0  EFLAGS: 00010283
> [2.246912] RAX: 8800353e15c0 RBX: 8800e98c52c8 RCX:
> 0020
> [2.246912] RDX: 8800353e15b0 RSI: 8800e98c52b8 RDI:
> 8800353e15d0
> [2.246912] RBP: 8800e98bfd20 R08: 8800353e15b0 R09:
> 8800eb403c00
> [2.246912] R10: a0155532 R11: ffe8 R12:
> 8800e98c4000
> [2.246912] R13: 8800e98c52b8 R14: 0020 R15:
> 8800353e15c0
> [2.246912] FS:  () GS:8800efc2()
> knlGS:
> [2.246912] CS:  0010 DS:  ES:  CR0: 80050033
> [2.246912] CR2: 7f1b615ef000 CR3: e2b44000 CR4:
> 001406e0
> [2.246912] DR0:  DR1:  DR2:
> 
> [2.246912] DR3:  DR6: 0ff0 DR7:
> 0400
> [2.246912] Stack:
> [2.246912]  0020 0001 0020a0157217
> 0100e98bfdbc
> [2.246912]  27efa3ef 8800e98bfdbc 8800e98ce000
> 8800e98c4000
> [2.246912]  8800e98ce040 0001 8800e98bfe08
> a0155d4c
> [2.246912] Call Trace:
> [2.246912]  [] blkback_changed+0x4ec/0xfc8
> [xen_blkfront]
> [2.246912]  [] ? xenbus_gather+0x170/0x190
> [2.246912]  [] ? __slab_free+0x10e/0x277
> [2.246912]  []
> xenbus_otherend_changed+0xad/0x110
> [2.246912]  [] ? xenwatch_thread+0x77/0x180
> [2.246912]  [] backend_changed+0x13/0x20
> [2.246912]  [] xenwatch_thread+0x66/0x180
> [2.246912]  [] ? wake_up_atomic_t+0x30/0x30
> [2.246912]  [] ?
> unr

Re: [Xen-devel] [Qemu-block] [PATCH 05/17] block: Convert BB interface to byte-based discards

[Stefan Hajnoczi]

On Wed, Jun 22, 2016 at 09:51:02AM -0600, Eric Blake wrote:
> Change sector-based blk_discard(), blk_co_discard(), and
> blk_aio_discard() to instead be byte-based *_pdiscard()
> functions.  NBD gets a lot simpler now that ignoring the
> unaligned portion of a byte-based discard request is handled
> under the hood by the block layer.
> 
> Signed-off-by: Eric Blake 
> ---
>  include/sysemu/block-backend.h |  9 -
>  block/block-backend.c  | 25 +++--
>  block/mirror.c |  5 +++--
>  hw/block/xen_disk.c|  7 ---
>  hw/ide/core.c  |  6 --
>  hw/scsi/scsi-disk.c|  8 
>  nbd/server.c   | 19 +--
>  qemu-io-cmds.c |  3 +--
>  8 files changed, 36 insertions(+), 46 deletions(-)

Reviewed-by: Stefan Hajnoczi 


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

Re: [Xen-devel] Converting heap page_infos to contiguous virtual

[Julien Grall]

Hi,

On 14/07/16 11:34, Andrew Cooper wrote:

On 14/07/16 11:25, George Dunlap wrote:

On 13/07/16 21:57, Boris Ostrovsky wrote:

On 07/13/2016 04:34 PM, Andrew Cooper wrote:

On 13/07/2016 21:17, Boris Ostrovsky wrote:

On 07/13/2016 04:02 PM, Andrew Cooper wrote:

On 13/07/16 20:44, Boris Ostrovsky wrote:

I would like to clear a bunch of Xen heap pages at once (i.e. not
page-by-page).

Greatly simplifying things, let's say I grab (in common/page_alloc.c)
 pg = page_list_remove_head(&heap(node, zone, order)

and then

 mfn_t mfn =
_mfn(page_to_mfn(pg));
 char *va = mfn_to_virt(mfn_x(mfn));
 memset(va, 0, 4096 * (1 << order));


Would it be valid to this?

In principle, yes.  The frame_table is in order.

However, mfn_to_virt() will blow up for RAM above the 5TB boundary.  You
need to map_domain_page() to get a mapping.

Right, but that would mean going page-by-page, which I want to avoid.

Now, DIRECTMAP_SIZE is ~128TB (if my math is correct) --- doesn't it
imply that it maps this big a range contiguously (modulo PDX hole)?

Your maths is correct, and yet you will end up with problems if you
trust it.

That is the magic mode for the idle and monitor pagetables.  In the
context of a 64bit PV guest, the cutoff is at 5TB, at which point you
venture into the virtual address space reserved for guest kernel use.
(It is rather depressing that the 64bit PV guest ABI is the factor
limiting Xen's maximum RAM usage.)

I don't know whether it would make any difference but the pages that I am
talking about are not in use by any guest, they are free. (This question
is for scrubbing rewrite that I am working on. Which apparently you
figured out judged by what you are saying below)

Is this start-of-day scrubbing (when there are no guests), or scrubbing
on guest destruction?

If the former, it seems like it might not be too difficult to arrange
that we're in a context that has all the RAM mapped.


This will be runtime scrubbing of pages.  This topic has come up at
several hackathons.


Is it a feature that will be implemented in common code? If so, bear in 
mind that ARM 32-bit hypervisor does not have all the memory mapped 
(actually only Xen heap is mapped).


Regards,

--
Julien Grall

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

Re: [Xen-devel] [BUG] kernel BUG at drivers/block/xen-blkfront.c:1711

[Evgenii Shatokhin]

On 14.07.2016 15:04, Bob Liu wrote:


On 07/14/2016 07:49 PM, Evgenii Shatokhin wrote:

On 11.07.2016 15:04, Bob Liu wrote:



On 07/11/2016 04:50 PM, Evgenii Shatokhin wrote:

On 06.06.2016 11:42, Dario Faggioli wrote:

Just Cc-ing some Linux, block, and Xen on CentOS people...



Ping.

Any suggestions how to debug this or what might cause the problem?

Obviously, we cannot control Xen on the Amazon's servers. But perhaps there is 
something we can do at the kernel's side, is it?


On Mon, 2016-06-06 at 11:24 +0300, Evgenii Shatokhin wrote:

(Resending this bug report because the message I sent last week did
not
make it to the mailing list somehow.)

Hi,

One of our users gets kernel panics from time to time when he tries
to
use his Amazon EC2 instance with CentOS7 x64 in it [1]. Kernel panic
happens within minutes from the moment the instance starts. The
problem
does not show up every time, however.

The user first observed the problem with a custom kernel, but it was
found later that the stock kernel 3.10.0-327.18.2.el7.x86_64 from
CentOS7 was affected as well.


Please try this patch:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7b0767502b5db11cb1f0daef2d01f6d71b1192dc

Regards,
Bob



Unfortunately, it did not help. The same BUG_ON() in blkfront_setup_indirect() 
still triggers in our kernel based on RHEL's 3.10.0-327.18.2, where I added the 
patch.

As far as I can see, the patch makes sure the indirect pages are added to the list 
only if (!info->feature_persistent) holds. I suppose it holds in our case and 
the pages are added to the list because the triggered BUG_ON() is here:

 if (!info->feature_persistent && info->max_indirect_segments) {
 <...>
 BUG_ON(!list_empty(&info->indirect_pages));
 <...>
 }



That's odd.
Could you please try to reproduce this issue with a recent upstream kernel?


Yes, will try to.



Thanks,
Bob


So the problem is still out there somewhere, it seems.

Regards,
Evgenii



The part of the system log he was able to retrieve is attached. Here
is
the bug info, for convenience:


[2.246912] kernel BUG at drivers/block/xen-blkfront.c:1711!
[2.246912] invalid opcode:  [#1] SMP
[2.246912] Modules linked in: ata_generic pata_acpi
crct10dif_pclmul
crct10dif_common crc32_pclmul crc32c_intel ghash_clmulni_intel
xen_netfront xen_blkfront(+) aesni_intel lrw ata_piix gf128mul
glue_helper ablk_helper cryptd libata serio_raw floppy sunrpc
dm_mirror
dm_region_hash dm_log dm_mod scsi_transport_iscsi
[2.246912] CPU: 1 PID: 50 Comm: xenwatch Not tainted
3.10.0-327.18.2.el7.x86_64 #1
[2.246912] Hardware name: Xen HVM domU, BIOS 4.2.amazon
12/07/2015
[2.246912] task: 8800e9fcb980 ti: 8800e98bc000 task.ti:
8800e98bc000
[2.246912] RIP: 0010:[]  []
blkfront_setup_indirect+0x41f/0x430 [xen_blkfront]
[2.246912] RSP: 0018:8800e98bfcd0  EFLAGS: 00010283
[2.246912] RAX: 8800353e15c0 RBX: 8800e98c52c8 RCX:
0020
[2.246912] RDX: 8800353e15b0 RSI: 8800e98c52b8 RDI:
8800353e15d0
[2.246912] RBP: 8800e98bfd20 R08: 8800353e15b0 R09:
8800eb403c00
[2.246912] R10: a0155532 R11: ffe8 R12:
8800e98c4000
[2.246912] R13: 8800e98c52b8 R14: 0020 R15:
8800353e15c0
[2.246912] FS:  () GS:8800efc2()
knlGS:
[2.246912] CS:  0010 DS:  ES:  CR0: 80050033
[2.246912] CR2: 7f1b615ef000 CR3: e2b44000 CR4:
001406e0
[2.246912] DR0:  DR1:  DR2:

[2.246912] DR3:  DR6: 0ff0 DR7:
0400
[2.246912] Stack:
[2.246912]  0020 0001 0020a0157217
0100e98bfdbc
[2.246912]  27efa3ef 8800e98bfdbc 8800e98ce000
8800e98c4000
[2.246912]  8800e98ce040 0001 8800e98bfe08
a0155d4c
[2.246912] Call Trace:
[2.246912]  [] blkback_changed+0x4ec/0xfc8
[xen_blkfront]
[2.246912]  [] ? xenbus_gather+0x170/0x190
[2.246912]  [] ? __slab_free+0x10e/0x277
[2.246912]  []
xenbus_otherend_changed+0xad/0x110
[2.246912]  [] ? xenwatch_thread+0x77/0x180
[2.246912]  [] backend_changed+0x13/0x20
[2.246912]  [] xenwatch_thread+0x66/0x180
[2.246912]  [] ? wake_up_atomic_t+0x30/0x30
[2.246912]  [] ?
unregister_xenbus_watch+0x1f0/0x1f0
[2.246912]  [] kthread+0xcf/0xe0
[2.246912]  [] ?
kthread_create_on_node+0x140/0x140
[2.246912]  [] ret_from_fork+0x58/0x90
[2.246912]  [] ?
kthread_create_on_node+0x140/0x140
[2.246912] Code: e1 48 85 c0 75 ce 49 8d 84 24 40 01 00 00 48 89
45
b8 e9 91 fd ff ff 4c 89 ff e8 8d ae 06 e1 e9 f2 fc ff ff 31 c0 e9 2e
fe
ff ff <0f> 0b e8 9a 57 f2 e0 0f 0b 0f 1f 84 00 00 00 00 00 0f 1f 44
00
[2.246912] RIP  []
blkfront_setup_indirect+0x41f/0x430 [xen_blkf

[Xen-devel] Linux 3.18 and Linux 4.1 reproducible OOM crashes

[Ian Jackson]

osstest service owner writes ("[linux-3.18 test] 97278: regressions - FAIL"):
> flight 97278 linux-3.18 real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/97278/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
...
>  test-amd64-amd64-xl   6 xen-bootfail REGR. vs. 96188

Loads of these.  It seems it can't boot at all.  Seems to affect amd64
dom0 kernels but not i386 or armhf.  (See flight 97279 for 4.1
results.)

It seems that the oom killer is tripping.  Obviously something is
seriously wrong.

It seems likely that this is a real bug, but whether it's in Xen or
Linux is not clear right now.  If it's in Linux it's because a similar
patch has been backported to both.

Below is serial log extract (from the job mentioned above).

Ian.


Jul 14 00:27:33.715871 [   22.813518] rc.local invoked oom-killer: 
gfp_mask=0x84d0, order=0, oom_score_adj=0

Jul 14 00:27:33.899843 [   22.813541] rc.local cpuset=/ mems_allowed=0

Jul 14 00:27:33.907821 [   22.813550] CPU: 0 PID: 2676 Comm: rc.local Not 
tainted 3.18.37 #1

Jul 14 00:27:33.907861 [   22.813556] Hardware name: Intel Corporation 
SandyBridge Platform/To be filled by O.E.M., BIOS 
S1200BT.86B.02.00.0042.050820141549 05/08/2014

Jul 14 00:27:33.923914 [   22.813565]   8800024b7968 
817dcab5 84d0

Jul 14 00:27:33.931995 [   22.813573]   8800024b79c8 
8118082f 8800024b7988

Jul 14 00:27:33.940021 [   22.813582]  8114c315 817e5ee9 
0001 8800024b79c8

Jul 14 00:27:33.948034 [   22.813590] Call Trace:

Jul 14 00:27:33.948065 [   22.813600]  [] dump_stack+0x7c/0x98

Jul 14 00:27:33.955838 [   22.813609]  [] 
dump_header.isra.11+0x8f/0x1e0

Jul 14 00:27:33.963831 [   22.813616]  [] ? 
__delayacct_freepages_end+0x45/0x50

Jul 14 00:27:33.963872 [   22.813677]  [] ? 
_raw_spin_unlock_irqrestore+0x29/0x90

Jul 14 00:27:33.971868 [   22.813685]  [] ? 
___ratelimit+0xae/0x160

Jul 14 00:27:33.979838 [   22.813691]  [] 
oom_kill_process+0x20c/0x370

Jul 14 00:27:33.987847 [   22.813699]  [] ? 
has_capability_noaudit+0x19/0x20

Jul 14 00:27:33.987888 [   22.813706]  [] 
out_of_memory+0x211/0x330

Jul 14 00:27:33.995847 [   22.813714]  [] 
__alloc_pages_nodemask+0xb11/0xb50

Jul 14 00:27:34.003844 [   22.813721]  [] 
__get_free_pages+0x12/0x70

Jul 14 00:27:34.011845 [   22.813728]  [] 
get_zeroed_page+0x11/0x20

Jul 14 00:27:34.011882 [   22.813735]  [] 
__pud_alloc+0x21/0x120

Jul 14 00:27:34.019841 [   22.813742]  [] 
handle_mm_fault+0x352/0xd50

Jul 14 00:27:34.027863 [   22.813749]  [] ? 
follow_page_mask+0x2f/0x4f0

Jul 14 00:27:34.035848 [   22.813756]  [] ? find_vma+0x62/0x70

Jul 14 00:27:34.035885 [   22.813763]  [] 
__get_user_pages+0x178/0x660

Jul 14 00:27:34.043839 [   22.813770]  [] 
get_user_pages+0x4d/0x50

Jul 14 00:27:34.051847 [   22.813776]  [] 
copy_strings.isra.26+0x176/0x310

Jul 14 00:27:34.051886 [   22.813782]  [] 
copy_strings_kernel+0x3a/0x60

Jul 14 00:27:34.059844 [   22.813789]  [] 
do_execve_common.isra.33+0x418/0x680

Jul 14 00:27:34.067846 [   22.813795]  [] SyS_execve+0x24/0x30

Jul 14 00:27:34.075839 [   22.813801]  [] 
stub_execve+0x69/0xa0

Jul 14 00:27:34.075876 [   22.813807] Mem-Info:

Jul 14 00:27:34.083841 [   22.813810] DMA per-cpu:

Jul 14 00:27:34.083872 [   22.813813] CPU0: hi:0, btch:   1 usd:   0

Jul 14 00:27:34.083905 [   22.813817] CPU1: hi:0, btch:   1 usd:   0

Jul 14 00:27:34.091848 [   22.813821] CPU2: hi:0, btch:   1 usd:   0

Jul 14 00:27:34.099849 [   22.813825] CPU3: hi:0, btch:   1 usd:   0

Jul 14 00:27:34.099885 [   22.813829] DMA32 per-cpu:

Jul 14 00:27:34.107837 [   22.813833] CPU0: hi:  186, btch:  31 usd:  88

Jul 14 00:27:34.107872 [   22.813837] CPU1: hi:  186, btch:  31 usd:  72

Jul 14 00:27:34.115855 [   22.813841] CPU2: hi:  186, btch:  31 usd:  47

Jul 14 00:27:34.115892 [   22.813845] CPU3: hi:  186, btch:  31 usd: 171

Jul 14 00:27:34.123844 [   22.813852] active_anon:0 inactive_anon:0 
isolated_anon:0

Jul 14 00:27:34.131837 [   22.813852]  active_file:0 inactive_file:0 
isolated_file:0

Jul 14 00:27:34.131873 [   22.813852]  unevictable:69 dirty:9 writeback:0 
unstable:0

Jul 14 00:27:34.139847 [   22.813852]  free:1036 slab_reclaimable:1887 
slab_unreclaimable:4091

Jul 14 00:27:34.147839 [   22.813852]  mapped:4099 shmem:154 pagetables:706 
bounce:0

Jul 14 00:27:34.155836 [   22.813852]  free_cma:0

Jul 14 00:27:34.155867 [   22.813875] DMA free:1680kB min:96kB low:120kB 
high:144kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB 
unevictable:4kB isolated(anon):0kB isolated(file):0kB present:15976kB 
managed:15892kB mlocked:1048kB dirty:0kB writeback:0kB mapped:408kB shmem:8kB 
slab_reclaimable:92kB slab_unreclaimable:328kB kernel_stack:64kB 
pagetables:148kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB 
pages_scanned:0 all_unre

[Xen-devel] [distros-debian-wheezy test] 66566: tolerable trouble: blocked/broken

[Platform Team regression test user]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 build-armhf-pvops 3 host-install(3)  broken like 44432
 build-armhf   3 host-install(3)  broken like 44432
 build-amd64-pvops 3 host-install(3)  broken like 44432
 build-i3863 host-install(3)  broken like 44432
 build-i386-pvops  3 host-install(3)  broken like 44432
 build-amd64   3 host-install(3)  broken like 44432

Tests which did not succeed, but are not blocking:
 test-amd64-i386-amd64-wheezy-netboot-pygrub  1 build-check(1)  blocked n/a
 test-amd64-i386-i386-wheezy-netboot-pvgrub  1 build-check(1)   blocked n/a
 test-amd64-amd64-i386-wheezy-netboot-pygrub  1 build-check(1)  blocked n/a
 test-amd64-amd64-amd64-wheezy-netboot-pvgrub  1 build-check(1) blocked n/a

baseline version:
 flight   44432

jobs:
 build-amd64  broken  
 build-armhf  broken  
 build-i386   broken  
 build-amd64-pvopsbroken  
 build-armhf-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-amd64-wheezy-netboot-pvgrub blocked 
 test-amd64-i386-i386-wheezy-netboot-pvgrub   blocked 
 test-amd64-i386-amd64-wheezy-netboot-pygrub  blocked 
 test-amd64-amd64-i386-wheezy-netboot-pygrub  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.


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

Re: [Xen-devel] [PATCH 0/8] x86: audit and remove needless module.h includes

[Ingo Molnar]

* Paul Gortmaker  wrote:

> To that end, I have done allmodconfig, allyesconfig and allnoconfig
> for both 32 bit and 64 bit x86 with these changes on the linux-next
> from today, which presumably has an up to date copy of tip in it.

It does, still I get this on allnoconfig with your patches applied:

arch/x86/kernel/setup_percpu.c: In function ‘setup_percpu_segment’:
arch/x86/kernel/setup_percpu.c:159:2: error: implicit declaration of function 
‘pack_descriptor’ [-Werror=implicit-function-declaration]
  pack_descriptor(&gdt, per_cpu_offset(cpu), 0xF,
  ^
arch/x86/kernel/setup_percpu.c:162:2: error: implicit declaration of function 
‘write_gdt_entry’ [-Werror=implicit-function-declaration]
  write_gdt_entry(get_cpu_gdt_table(cpu),
  ^
arch/x86/kernel/setup_percpu.c:162:18: error: implicit declaration of function 
‘get_cpu_gdt_table’ [-Werror=implicit-function-declaration]
  write_gdt_entry(get_cpu_gdt_table(cpu),

I'll continue testing with the setup_percpu.c change left out.

Thanks,

Ingo

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

Re: [Xen-devel] Converting heap page_infos to contiguous virtual

[Andrew Cooper]

On 14/07/16 13:42, Julien Grall wrote:
> Hi,
>
> On 14/07/16 11:34, Andrew Cooper wrote:
>> On 14/07/16 11:25, George Dunlap wrote:
>>> On 13/07/16 21:57, Boris Ostrovsky wrote:
 On 07/13/2016 04:34 PM, Andrew Cooper wrote:
> On 13/07/2016 21:17, Boris Ostrovsky wrote:
>> On 07/13/2016 04:02 PM, Andrew Cooper wrote:
>>> On 13/07/16 20:44, Boris Ostrovsky wrote:
 I would like to clear a bunch of Xen heap pages at once (i.e. not
 page-by-page).

 Greatly simplifying things, let's say I grab (in
 common/page_alloc.c)
  pg = page_list_remove_head(&heap(node, zone, order)

 and then

  mfn_t mfn =
 _mfn(page_to_mfn(pg));
  char *va = mfn_to_virt(mfn_x(mfn));
  memset(va, 0, 4096 * (1 << order));


 Would it be valid to this?
>>> In principle, yes.  The frame_table is in order.
>>>
>>> However, mfn_to_virt() will blow up for RAM above the 5TB
>>> boundary.  You
>>> need to map_domain_page() to get a mapping.
>> Right, but that would mean going page-by-page, which I want to
>> avoid.
>>
>> Now, DIRECTMAP_SIZE is ~128TB (if my math is correct) --- doesn't it
>> imply that it maps this big a range contiguously (modulo PDX hole)?
> Your maths is correct, and yet you will end up with problems if you
> trust it.
>
> That is the magic mode for the idle and monitor pagetables.  In the
> context of a 64bit PV guest, the cutoff is at 5TB, at which point you
> venture into the virtual address space reserved for guest kernel use.
> (It is rather depressing that the 64bit PV guest ABI is the factor
> limiting Xen's maximum RAM usage.)
 I don't know whether it would make any difference but the pages
 that I am
 talking about are not in use by any guest, they are free. (This
 question
 is for scrubbing rewrite that I am working on. Which apparently you
 figured out judged by what you are saying below)
>>> Is this start-of-day scrubbing (when there are no guests), or scrubbing
>>> on guest destruction?
>>>
>>> If the former, it seems like it might not be too difficult to arrange
>>> that we're in a context that has all the RAM mapped.
>>
>> This will be runtime scrubbing of pages.  This topic has come up at
>> several hackathons.
>
> Is it a feature that will be implemented in common code? If so, bear
> in mind that ARM 32-bit hypervisor does not have all the memory mapped
> (actually only Xen heap is mapped).

Nor does x86, on boxes with more than 5TB of RAM.

Where possible, we should try to make it common, but it will depend on
exactly how similar the heap implementations are.

~Andrew

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

Re: [Xen-devel] [PATCH] Add optional ACPI device for Windows Continuum

[Andrew Cooper]

On 13/07/16 10:16, Owen Smith wrote:
> Windows 10 supports a specific ACPI device for handling the
> switch between tablet mode and desktop mode. The meer existance
> of this device is the mimimum to allow tablet/desktop mode to
> be switched.
> Tablet mode referes to the "undocked" state where all applications
> are forced full screen and additional touch screen elements are
> added, such as touch keyboard, larger icons and menus, and touch
> gestures for ease of use.
>
> Signed-off-by: Owen Smith 

Are there any docs which can be referenced about this device?

> ---
>  tools/firmware/hvmloader/acpi/Makefile  |  4 ++--
>  tools/firmware/hvmloader/acpi/build.c   | 11 ++
>  tools/firmware/hvmloader/acpi/ssdt_conv.asl | 31 
> +
>  tools/libxl/libxl_types.idl |  1 +
>  tools/libxl/xl_cmdimpl.c|  1 +
>  5 files changed, 46 insertions(+), 2 deletions(-)
>  create mode 100644 tools/firmware/hvmloader/acpi/ssdt_conv.asl
>
> diff --git a/tools/firmware/hvmloader/acpi/Makefile 
> b/tools/firmware/hvmloader/acpi/Makefile
> index d3e882a..d75c7af 100644
> --- a/tools/firmware/hvmloader/acpi/Makefile
> +++ b/tools/firmware/hvmloader/acpi/Makefile
> @@ -25,7 +25,7 @@ CFLAGS += $(CFLAGS_xeninclude)
>  vpath iasl $(PATH)
>  all: acpi.a
>  
> -ssdt_s3.h ssdt_s4.h ssdt_pm.h ssdt_tpm.h: %.h: %.asl iasl
> +ssdt_s3.h ssdt_s4.h ssdt_conv.h ssdt_pm.h ssdt_tpm.h: %.h: %.asl iasl
>   iasl -vs -p $* -tc $<
>   sed -e 's/AmlCode/$*/g' $*.hex >$@
>   rm -f $*.hex $*.aml
> @@ -56,7 +56,7 @@ iasl:
>   @echo 
>   @exit 1
>  
> -build.o: ssdt_s3.h ssdt_s4.h ssdt_pm.h ssdt_tpm.h
> +build.o: ssdt_s3.h ssdt_s4.h ssdt_conv.h ssdt_pm.h ssdt_tpm.h
>  
>  acpi.a: $(OBJS)
>   $(AR) rc $@ $(OBJS)
> diff --git a/tools/firmware/hvmloader/acpi/build.c 
> b/tools/firmware/hvmloader/acpi/build.c
> index 1f7103e..6485ac8 100644
> --- a/tools/firmware/hvmloader/acpi/build.c
> +++ b/tools/firmware/hvmloader/acpi/build.c
> @@ -18,6 +18,7 @@
>  #include "acpi2_0.h"
>  #include "ssdt_s3.h"
>  #include "ssdt_s4.h"
> +#include "ssdt_conv.h"
>  #include "ssdt_tpm.h"
>  #include "ssdt_pm.h"
>  #include "../config.h"
> @@ -398,6 +399,16 @@ static int construct_secondary_tables(unsigned long 
> *table_ptrs,
>  printf("S4 disabled\n");
>  }
>  
> +if ( !strncmp(xenstore_read("platform/acpi_conv", "1"), "1", 1) )
> +{
> +ssdt = mem_alloc(sizeof(ssdt_conv), 16);
> +if (!ssdt) return -1;
> +memcpy(ssdt, ssdt_conv, sizeof(ssdt_conv));
> +table_ptrs[nr_tables++] = (unsigned long)ssdt;
> +} else {
> +printf("Conv disabled\n");
> +}

I would drop this else clause.  It isn't interesting in the general
case, and anyone who doesn't know exactly what Conv is will be confused
by it.

> +
>  /* TPM TCPA and SSDT. */
>  tis_hdr = (uint16_t *)0xFED40F00;
>  if ( (tis_hdr[0] == tis_signature[0]) &&
> diff --git a/tools/firmware/hvmloader/acpi/ssdt_conv.asl 
> b/tools/firmware/hvmloader/acpi/ssdt_conv.asl
> new file mode 100644
> index 000..6e20340
> --- /dev/null
> +++ b/tools/firmware/hvmloader/acpi/ssdt_conv.asl
> @@ -0,0 +1,31 @@
> +/*
> + * ssdt_conv.asl
> + *
> + * Copyright (c) 2015  Citrix Systems, Inc.

Year.

> + *
> + * 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 .

Be aware that there is currently an ongoing effort to re-licence all the
apci work as LGPL, and move the acpi/ subdirectory into being a separate
standalone library.

~Andrew

> + */
> +
> +DefinitionBlock ("SSDT_CONV.aml", "SSDT", 2, "Xen", "HVM", 0)
> +{
> +Device(CONV)
> +{
> +Method(_HID, 0x0, NotSerialized)
> +{
> +Return("ID9001")
> +}
> +Name(_CID, "PNP0C60")
> +}
> +}
> +


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

Re: [Xen-devel] Converting heap page_infos to contiguous virtual

[Andrew Cooper]

On 13/07/16 22:43, Boris Ostrovsky wrote:
> On 07/13/2016 05:06 PM, Andrew Cooper wrote:
>> On 13/07/2016 21:57, Boris Ostrovsky wrote:
>>> On 07/13/2016 04:34 PM, Andrew Cooper wrote:
 On 13/07/2016 21:17, Boris Ostrovsky wrote:
> On 07/13/2016 04:02 PM, Andrew Cooper wrote:
>> On 13/07/16 20:44, Boris Ostrovsky wrote:
>>> I would like to clear a bunch of Xen heap pages at once (i.e. not
>>> page-by-page).
>>>
>>> Greatly simplifying things, let's say I grab (in common/page_alloc.c)
>>> pg = page_list_remove_head(&heap(node, zone, order)
>>>
>>> and then
>>>
>>> mfn_t mfn =
>>> _mfn(page_to_mfn(pg));
>>> char *va = mfn_to_virt(mfn_x(mfn));
>>> memset(va, 0, 4096 * (1 << order));
>>>
>>>
>>> Would it be valid to this?
>> In principle, yes.  The frame_table is in order.
>>
>> However, mfn_to_virt() will blow up for RAM above the 5TB boundary.  You
>> need to map_domain_page() to get a mapping.
> Right, but that would mean going page-by-page, which I want to avoid.
>
> Now, DIRECTMAP_SIZE is ~128TB (if my math is correct) --- doesn't it
> imply that it maps this big a range contiguously (modulo PDX hole)?
 Your maths is correct, and yet you will end up with problems if you
 trust it.

 That is the magic mode for the idle and monitor pagetables.  In the
 context of a 64bit PV guest, the cutoff is at 5TB, at which point you
 venture into the virtual address space reserved for guest kernel use. 
 (It is rather depressing that the 64bit PV guest ABI is the factor
 limiting Xen's maximum RAM usage.)
>>> I don't know whether it would make any difference but the pages that I am
>>> talking about are not in use by any guest, they are free. (This question
>>> is for scrubbing rewrite that I am working on. Which apparently you
>>> figured out judged by what you are saying below)
>> Being free is not relevant.  It depends whether current is a 64bit PV
>> guest or not.  Even in the idle loop, we don't context switch away from
>> current's pagetables.
>
> Can we force switch to idle (i.e. a non-64b PV guest) when we know
> it would be useful for mapping/scrubbing? The cost of TLB flush (if that
> was the reason) may be small compared to advantages brought by
> fast mapping during scrubbing.

It sounds like a plausible option, but would need some numbers to back
it up.

However, I would recommend getting something functioning first, before
trying to optimise it.

There is probably a lot to be gained simply by improving clear_page().

~Andrew

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

Re: [Xen-devel] [PATCH 4/9] xen/arm: traps: Simplify the switch in do_trap_*_abort_guest

[Stefano Stabellini]

On Thu, 14 Jul 2016, Julien Grall wrote:
> Hi Stefano,
> 
> On 14/07/16 12:12, Stefano Stabellini wrote:
> > On Wed, 22 Jun 2016, Julien Grall wrote:
> > > The fault status we care are all the form xx where xx is the lookup
> > 
> >   ^ in the form of
> > 
> > > level that gave the fault. We can simply the code by masking the 2 least
> > 
> > ^ simplify
> > 
> > > significant bits.
> > > 
> > > Signed-off-by: Julien Grall 
> > > ---
> > >   xen/arch/arm/traps.c | 8 
> > >   1 file changed, 4 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> > > index 2e84b5a..8a3fac0 100644
> > > --- a/xen/arch/arm/traps.c
> > > +++ b/xen/arch/arm/traps.c
> > > @@ -2388,9 +2388,9 @@ static void do_trap_instr_abort_guest(struct
> > > cpu_user_regs *regs,
> > >   int rc;
> > >   register_t gva = READ_SYSREG(FAR_EL2);
> > > 
> > > -switch ( hsr.iabt.ifsc & 0x3f )
> > > +switch ( hsr.iabt.ifsc & ~FSC_LL_MASK )
> > >   {
> > > -case FSC_FLT_PERM ... FSC_FLT_PERM + 3:
> > > +case FSC_FLT_PERM:
> > >   {
> > 
> > This is a good improvement in code readability. I would go one step
> > further and replace the switch with a simple if.
> 
> I would prefer to keep the switch case here. The patch #7 adds another case
> for do_trap_data_abort_guest because we should not emulate MMIO for any kind
> of fault as it is done today.
> 
> Also, I have got more fixes coming up which require the switch here.

all right

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

Re: [Xen-devel] [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Stefano Stabellini]

On Wed, 13 Jul 2016, Julien Grall wrote:
> Hello,
> 
> On 12/07/2016 17:58, Boris Ostrovsky wrote:
> > On 07/12/2016 12:10 PM, Julien Grall wrote:
> > > On 12/07/2016 16:08, Boris Ostrovsky wrote:
> > > > On 07/12/2016 10:57 AM, Shannon Zhao wrote:
> > > > > On 2016年07月12日 22:50, Wei Liu wrote:
> > > > > > On Tue, Jul 12, 2016 at 10:42:07PM +0800, Shannon Zhao wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > > Does it mean we would need
> > > > > > > > > > > > > > > > > > > > > > > > > > to update the slack
> > > > > > > > > > > > > > > > > > > > > > > > > > to take into account the
> > > > > > > > > > > > > > > > > > > > > > > > > > ACPI
> > > > > > > > > > > > > > > > > > > > > > > > > > blob?
> > > > > > > > > > > > > > > > > > Yes, we need to take into account the ACPI
> > > > > > > > > > > > > > > > > > blob.
> > > > > > > > > > > > > > > > > > Probably not in the
> > > > > > > > > > > > > > > > > > slack but directly in mam_memkb.
> > > > > > > > > > > > > > Sorry, I'm not sure understand this. I found the
> > > > > > > > > > > > > > b_info->max_memkb but
> > > > > > > > > > > > > > didn't find the slack you said. And how to fix this?
> > > > > > > > > > > > > > Update
> > > > > > > > > > > > > > b_info->max_memkb or the slack?
> > > > > > > > > > Can you calculate the size of your payload and add that to
> > > > > > > > > > max_memkb?
> > > > > > > > > > 
> > > > > > > > Yeah, but the size will be changed if we change the tables in
> > > > > > > > the
> > > > > > > > future
> > > > > > > > and this also should consider x86, right?
> > > > > > That could easily be solved by introducing a function to calculate
> > > > > > the
> > > > > > size, right?
> > > > > Oh, I'm not familiar with this. Let's clarify on this. It can add the
> > > > > size to max_memkb after generating the ACPI tables and before loading
> > > > > the tables to guest space and it doesn't have to add the size at
> > > > > libxl__domain_build_info_setdefault(), right?
> > > > 
> > > > This was discussed before: ACPI tables are part of RAM whose size is
> > > > specified by the config file (and is reflected in max_memkb I believe).
> > > > It may not be presented to the guest as RAM (i.e. on x86 it is labeled
> > > > by BIOS (or whoever) as a dedicated type in e820) but it still resides
> > > > in DIMMs.
> > > 
> > > I don't think this was the conclusion of the thread. IHMO, "maxmem" is
> > > the amount of RAM a guest could effectively use.
> > > 
> > > Whilst the ACPI tables will be in the DIMM from the host point of
> > > view. From a guest point of view it will be a ROM.
> > 
> > The config file specifies resources provided by the host. How the guest
> > views those resources is not important, I think.
> 
> This would need to be clarified. For instance special pages (Xenstore,
> Console...) are RAM from the host point of view but not taken into account in
> the "maxmem" provided by the user. For my understanding, some kB of the slack
> is used for that.
> 
> > 
> > > 
> > > It will affect some others part of the guest if we don't increment the
> > > "maxmem" requested by the user. For ARM the ACPI blob will be exposed
> > > at a specific address that is outside of the guest RAM (see the guest
> > > memory layout in public/arch-arm.h).
> > > 
> > > We chose this solution over putting in the RAM because the ACPI tables
> > > are not easily relocatable (compare to the device tree, initrd and
> > > kernel) so we could not take advantage of superpage in both stage-2
> > > (hypervisor) and stage-1 (kernel) page table.
> > 
> > Maybe this is something ARM-specific then. For x86 we will want to keep
> > maxmem unchanged.
> 
> I don't think what I described in my previous mail is ARM-specific. The
> pressure will be more important on the TLBs, if Xen does not use superpage in
> the stage 2 page tables (i.e EPT for x86) no matter the architecture.
> 
> IHMO, this seems to be a bigger drawback compare to add few more kilobytes to
> maxmem in the toolstack for the ACPI blob. You will loose them when creating
> the intermediate page table in any case.

I agree with Julien. On ARM we have to increase maxmem because I don't
think that shattering a superpage is acceptable for just a few KBs. In
fact, it's not much about increasing maxmem, but it's about keeping the
allocation of guest memory to the value passed by the user in "memory",
so that it can be done in the most efficient way possible. (I am
assuming users are going to allocate VMs of 2048MB, rather than 2049MB.)

I wouldn't want to end up adding to the performance tuning page on the
wiki "Make sure to add 1 more MB to the memory of your VM to get the
most out of the system."

I know that the location of the ACPI blob on x86 is different in guest
memory space, but it seems to me that the problem would be the same. Do
you have 1 gigabyte pages in stage-2 on x86? If so, I would think twice
about this. Otherwise, if you only have 4K and 2MB allocations, then it
might not make that muc

[Xen-devel] [xen-unstable baseline-only test] 66565: tolerable FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 build-i386-rumpuserxen6 xen-buildfail   like 66553
 build-amd64-rumpuserxen   6 xen-buildfail   like 66553
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 66553
 test-amd64-amd64-i386-pvgrub 10 guest-start  fail   like 66553
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 66553

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-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 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  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-midway   12 migrate-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-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  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-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-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-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
 test-amd64-i386-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-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass

version targeted for testing:
 xen  ea210c52abb6458e39f5365f7f2c3abb9c191c47
baseline version:
 xen  7da483b0236d8974cc97f81780dcf8e559a63175

Last test of basis66553  2016-07-09 15:19:35 Z4 days
Testing same since66565  2016-07-14 03:19:07 Z0 days1 attempts


People who touched revisions under test:
  Corneliu ZUZU 
  Elena Ufimtseva 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Juergen Gross 
  Julien Grall 
  Kevin Tian 
  Konrad Rzeszutek Wilk 
  Razvan Cojocaru 
  Stefano Stabellini 
  Tamas K Lengyel 
  Tim Deegan 
  Vitaly Kuznetsov 
  Wei Liu 

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

Re: [Xen-devel] [PATCH 5/9] xen/arm: Provide macros to help creating workaround helpers

[Stefano Stabellini]

On Wed, 22 Jun 2016, Julien Grall wrote:
> Workarounds may require to execute a different path when the platform
> is affected by the associated erratum. Furthermore, this may need to
> be called in the common code.
> 
> To avoid too much intrusion/overhead, the workaround helpers need to
> be a nop on architecture which will never have the workaround and have
> to be quick to check whether the platform requires it.
> 
> The alternative framework is used to transform the check in a single
> instruction. When the framework is not available, the helper will have
> ~6 instructions including 1 instruction load.
> 
> The macro will create a handler called check_workaround_x with
>  the erratum number.
> 
> For instance, the line bellow will create a workaround helper for
> erratum #424242 which is enabled when the capability
> ARM64_WORKAROUND_424242 is set and only available for ARM64:
> 
> CHECK_WORKAROUND_HELPER(424242, ARM64_WORKAROUND_42424242, CONFIG_ARM64)
> 
> Signed-off-by: Julien Grall 

It looks good to me. CC'ing Konrad which is more knowledgeable than me
about ALTERNATIVE.


>  xen/include/asm-arm/cpuerrata.h | 39 +++
>  1 file changed, 39 insertions(+)
> 
> diff --git a/xen/include/asm-arm/cpuerrata.h b/xen/include/asm-arm/cpuerrata.h
> index fe93beb..b9d8dfc 100644
> --- a/xen/include/asm-arm/cpuerrata.h
> +++ b/xen/include/asm-arm/cpuerrata.h
> @@ -1,8 +1,47 @@
>  #ifndef __ARM_CPUERRATA_H
>  #define __ARM_CPUERRATA_H
>  
> +#include 
> +#include 
> +#include 
> +
>  void check_local_cpu_errata(void);
>  
> +#ifdef CONFIG_ALTERNATIVE
> +
> +#define CHECK_WORKAROUND_HELPER(erratum, feature, arch) \
> +static inline bool_t check_workaround_##erratum(void)   \
> +{   \
> +if ( !IS_ENABLED(arch) )\
> +return 0;   \
> +else\
> +{   \
> +bool_t ret; \
> +\
> +asm volatile (ALTERNATIVE("mov %0, #0", \
> +  "mov %0, #1", \
> +  feature)  \
> +  : "=r" (ret));\
> +\
> +return unlikely(ret);   \
> +}   \
> +}
> +
> +#else /* CONFIG_ALTERNATIVE */
> +
> +#define CHECK_WORKAROUND_HELPER(erratum, feature, arch) \
> +static inline bool_t check_workaround_##erratum(void)   \
> +{   \
> +if ( !IS_ENABLED(arch) )\
> +return 0;   \
> +else\
> +return unlikely(cpus_have_cap(feature));\
> +}
> +
> +#endif
> +
> +#undef CHECK_WORKAROUND_HELPER
> +
>  #endif /* __ARM_CPUERRATA_H */
>  /*
>   * Local variables:
> -- 
> 1.9.1
> 

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

Re: [Xen-devel] [PATCH V3 04/10] arm/gic-v3: Parse per-cpu redistributor entry in GICC subtable

[Julien Grall]

Hi Shanker,

On 27/06/16 21:33, Shanker Donthineni wrote:

The redistributor address can be specified either as part of GICC or
GICR subtable depending on the power domain. The current driver
doesn't support parsing redistributor entry that is defined in GICC
subtable. The GIC CPU subtable entry holds the associated Redistributor
base address if it is not on always-on power domain.

The per CPU Redistributor size is not defined in ACPI specification.
Set the GICR region size to SZ_256K if the GIC hardware is capable of
Direct Virtual LPI Injection feature, SZ_128K otherwise.

This patch adds necessary code to handle both types of Redistributors
base addresses.

Signed-off-by: Shanker Donthineni 


Based on the discussion, this patch looks good to me:

Acked-by: Julien Grall 

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH V3 01/10] arm/gic-v3: Use acpi_table_parse_madt() to parse MADT subtables

[Stefano Stabellini]

On Mon, 27 Jun 2016, Shanker Donthineni wrote:
> The function acpi_table_parse_madt() does the same functionality as
> function acpi_parse_entries() expect it takes a few arguments.
> 
> Signed-off-by: Shanker Donthineni 

I committed patches 1 to 7


>  xen/arch/arm/gic-v3.c | 27 ++-
>  1 file changed, 6 insertions(+), 21 deletions(-)
> 
> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
> index 8d3f149..166f1c1 100644
> --- a/xen/arch/arm/gic-v3.c
> +++ b/xen/arch/arm/gic-v3.c
> @@ -1390,28 +1390,15 @@ gic_acpi_get_madt_redistributor_num(struct 
> acpi_subtable_header *header,
>  
>  static void __init gicv3_acpi_init(void)
>  {
> -struct acpi_table_header *table;
>  struct rdist_region *rdist_regs;
> -acpi_status status;
>  int count, i;
>  
> -status = acpi_get_table(ACPI_SIG_MADT, 0, &table);
> -
> -if ( ACPI_FAILURE(status) )
> -{
> -const char *msg = acpi_format_exception(status);
> -
> -panic("GICv3: Failed to get MADT table, %s", msg);
> -}
> -
>  /*
>   * Find distributor base address. We expect one distributor entry since
>   * ACPI 5.0 spec neither support multi-GIC instances nor GIC cascade.
>   */
> -count = acpi_parse_entries(ACPI_SIG_MADT, sizeof(struct acpi_table_madt),
> -   gic_acpi_parse_madt_distributor, table,
> -   ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR, 0);
> -
> +count = acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR,
> +  gic_acpi_parse_madt_distributor, 0);
>  if ( count <= 0 )
>  panic("GICv3: No valid GICD entries exists");
>  
> @@ -1420,9 +1407,8 @@ static void __init gicv3_acpi_init(void)
>dbase);
>  
>  /* Get number of redistributor */
> -count = acpi_parse_entries(ACPI_SIG_MADT, sizeof(struct acpi_table_madt),
> -   gic_acpi_get_madt_redistributor_num, table,
> -   ACPI_MADT_TYPE_GENERIC_REDISTRIBUTOR, 0);
> +count = acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_REDISTRIBUTOR,
> +  gic_acpi_get_madt_redistributor_num, 0);
>  if ( count <= 0 )
>  panic("GICv3: No valid GICR entries exists");
>  
> @@ -1458,9 +1444,8 @@ static void __init gicv3_acpi_init(void)
>  gicv3.rdist_regions= rdist_regs;
>  
>  /* Collect CPU base addresses */
> -count = acpi_parse_entries(ACPI_SIG_MADT, sizeof(struct acpi_table_madt),
> -   gic_acpi_parse_madt_cpu, table,
> -   ACPI_MADT_TYPE_GENERIC_INTERRUPT, 0);
> +count = acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_INTERRUPT,
> +  gic_acpi_parse_madt_cpu, 0);
>  if ( count <= 0 )
>  panic("GICv3: No valid GICC entries exists");
>  
> -- 
> Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc. 
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
> a Linux Foundation Collaborative Project
> 

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-libvirt5 libvirt-build fail REGR. vs. 97003
 build-armhf-libvirt   5 libvirt-build fail REGR. vs. 97003

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  55d8daa07e7419a929efd677923a428e3d76345b
baseline version:
 libvirt  32916b1699489584f66a53eaac322313803cabcc

Last test of basis97003  2016-07-11 04:22:49 Z3 days
Testing same since97286  2016-07-14 04:20:26 Z0 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Chen Hanxiao 
  Daniel P. Berrange 
  Eric Blake 
  Jim Fehlig 
  Ján Tomko 
  Luyao Huang 
  Martin Kletzander 
  Maxim Perevedentsev 
  Michal Privoznik 
  Nishith Shah 
  Olga Krishtal 
  Peter Krempa 
  Tomasz Flendrich 
  Tomáš Golembiovský 
  Yan Fu 

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  fail
 build-i386-libvirt   fail
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmblocked 
 test-amd64-amd64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm blocked 
 test-amd64-i386-libvirt-xsm  blocked 
 test-amd64-amd64-libvirt pass
 test-armhf-armhf-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair blocked 
 test-armhf-armhf-libvirt-qcow2   blocked 
 test-armhf-armhf-libvirt-raw blocked 
 test-amd64-amd64-libvirt-vhd pass



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

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

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

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


Not pushing.

(No revision log; it would be 894 lines long.)

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

[Xen-devel] [PATCH v6 1/2] xsm: rework policy_buffer globals

[Daniel De Graaf]

This makes the buffers function parameters instead of globals, in
preparation for adding alternate locations for the policy.

Signed-off-by: Daniel De Graaf 
Reviewed-by: Jan Beulich 
---

Changes since v5:
 - Adjusted __init annotation placement
 - Removed unneeded cast to char*

 xen/include/xsm/xsm.h| 13 ++---
 xen/xsm/flask/hooks.c|  2 +-
 xen/xsm/flask/include/security.h |  2 +-
 xen/xsm/flask/ss/policydb.h  |  2 +-
 xen/xsm/flask/ss/services.c  |  2 +-
 xen/xsm/xsm_core.c   | 17 +++--
 xen/xsm/xsm_policy.c | 21 ++---
 7 files changed, 31 insertions(+), 28 deletions(-)

diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 4b8843d..e83dca2 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -43,9 +43,6 @@ enum xsm_default {
 };
 typedef enum xsm_default xsm_default_t;
 
-extern char *policy_buffer;
-extern u32 policy_size;
-
 struct xsm_operations {
 void (*security_domaininfo) (struct domain *d,
 struct xen_domctl_getdomaininfo *info);
@@ -740,12 +737,14 @@ extern int xsm_multiboot_init(unsigned long *module_map,
   void *(*bootstrap_map)(const module_t *));
 extern int xsm_multiboot_policy_init(unsigned long *module_map,
  const multiboot_info_t *mbi,
- void *(*bootstrap_map)(const module_t *));
+ void *(*bootstrap_map)(const module_t *),
+ void **policy_buffer,
+ size_t *policy_size);
 #endif
 
 #ifdef CONFIG_HAS_DEVICE_TREE
 extern int xsm_dt_init(void);
-extern int xsm_dt_policy_init(void);
+extern int xsm_dt_policy_init(void **policy_buffer, size_t *policy_size);
 extern bool has_xsm_magic(paddr_t);
 #endif
 
@@ -755,9 +754,9 @@ extern struct xsm_operations dummy_xsm_ops;
 extern void xsm_fixup_ops(struct xsm_operations *ops);
 
 #ifdef CONFIG_FLASK
-extern void flask_init(void);
+extern void flask_init(const void *policy_buffer, size_t policy_size);
 #else
-static inline void flask_init(void)
+static inline void flask_init(const void *policy_buffer, size_t policy_size)
 {
 }
 #endif
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 2692a6f..ec6f5b4 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1815,7 +1815,7 @@ static struct xsm_operations flask_ops = {
 .xen_version = flask_xen_version,
 };
 
-__init void flask_init(void)
+void __init flask_init(const void *policy_buffer, size_t policy_size)
 {
 int ret = -ENOENT;
 
diff --git a/xen/xsm/flask/include/security.h b/xen/xsm/flask/include/security.h
index 1da020d..ec8b442 100644
--- a/xen/xsm/flask/include/security.h
+++ b/xen/xsm/flask/include/security.h
@@ -52,7 +52,7 @@ enum flask_bootparam_t {
 extern enum flask_bootparam_t flask_bootparam;
 extern int flask_mls_enabled;
 
-int security_load_policy(void * data, size_t len);
+int security_load_policy(const void *data, size_t len);
 
 struct av_decision {
 u32 allowed;
diff --git a/xen/xsm/flask/ss/policydb.h b/xen/xsm/flask/ss/policydb.h
index 238a042..d3b409a 100644
--- a/xen/xsm/flask/ss/policydb.h
+++ b/xen/xsm/flask/ss/policydb.h
@@ -277,7 +277,7 @@ extern int policydb_read(struct policydb *p, void *fp);
 #define TARGET_XEN_OLD 0
 
 struct policy_file {
-char *data;
+const char *data;
 size_t len;
 };
 
diff --git a/xen/xsm/flask/ss/services.c b/xen/xsm/flask/ss/services.c
index 86f94c9..b2c5c44 100644
--- a/xen/xsm/flask/ss/services.c
+++ b/xen/xsm/flask/ss/services.c
@@ -1353,7 +1353,7 @@ static int security_preserve_bools(struct policydb *p);
  * This function will flush the access vector cache after
  * loading the new policy.
  */
-int security_load_policy(void *data, size_t len)
+int security_load_policy(const void *data, size_t len)
 {
 struct policydb oldpolicydb, newpolicydb;
 struct sidtab oldsidtab, newsidtab;
diff --git a/xen/xsm/xsm_core.c b/xen/xsm/xsm_core.c
index 8df1a3c..3d132be 100644
--- a/xen/xsm/xsm_core.c
+++ b/xen/xsm/xsm_core.c
@@ -36,7 +36,7 @@ static inline int verify(struct xsm_operations *ops)
 return 0;
 }
 
-static int __init xsm_core_init(void)
+static int __init xsm_core_init(const void *policy_buffer, size_t policy_size)
 {
 if ( verify(&dummy_xsm_ops) )
 {
@@ -46,7 +46,7 @@ static int __init xsm_core_init(void)
 }
 
 xsm_ops = &dummy_xsm_ops;
-flask_init();
+flask_init(policy_buffer, policy_size);
 
 return 0;
 }
@@ -57,12 +57,15 @@ int __init xsm_multiboot_init(unsigned long *module_map,
   void *(*bootstrap_map)(const module_t *))
 {
 int ret = 0;
+void *policy_buffer = NULL;
+size_t policy_size = 0;
 
 printk("XSM Framework v" XSM_FRAMEWORK_VERSION " initialized\n");
 
 if ( XSM_MAGIC )
 {
-ret = xsm_multiboot_policy_init(module_map, m

[Xen-devel] [PATCH v6 2/2] xsm: add a default policy to .init.data

[Daniel De Graaf]

This adds a Kconfig option and support for including the XSM policy from
tools/flask/policy in the hypervisor so that the bootloader does not
need to provide a policy to get sane behavior from an XSM-enabled
hypervisor.  The policy provided by the bootloader, if present, will
override the built-in policy.

The XSM policy is not moved out of tools because that remains the
primary location for installing and configuring the policy.

Signed-off-by: Daniel De Graaf 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Jan Beulich 
---

No changes from v5.

 Config.mk   |  6 ++
 INSTALL | 10 --
 docs/misc/xen-command-line.markdown | 16 +---
 docs/misc/xsm-flask.txt | 30 +++---
 xen/common/Kconfig  | 20 
 xen/include/xsm/xsm.h   |  5 +
 xen/xsm/flask/.gitignore|  1 +
 xen/xsm/flask/Makefile  | 13 -
 xen/xsm/flask/gen-policy.py | 23 +++
 xen/xsm/xsm_core.c  |  8 
 10 files changed, 107 insertions(+), 25 deletions(-)
 create mode 100644 xen/xsm/flask/.gitignore
 create mode 100644 xen/xsm/flask/gen-policy.py

diff --git a/Config.mk b/Config.mk
index 723e129..01316ae 100644
--- a/Config.mk
+++ b/Config.mk
@@ -147,6 +147,12 @@ export XEN_HAS_BUILD_ID=y
 build_id_linker := --build-id=sha1
 endif
 
+ifndef XEN_HAS_CHECKPOLICY
+CHECKPOLICY ?= checkpolicy
+XEN_HAS_CHECKPOLICY := $(shell $(CHECKPOLICY) -h 2>&1 | grep -q xen && 
echo y || echo n)
+export XEN_HAS_CHECKPOLICY
+endif
+
 # as-insn: Check whether assembler supports an instruction.
 # Usage: cflags-y += $(call as-insn "insn",option-yes,option-no)
 as-insn = $(if $(shell echo 'void _(void) { asm volatile ( $(2) ); }' \
diff --git a/INSTALL b/INSTALL
index 616a67a..9759354 100644
--- a/INSTALL
+++ b/INSTALL
@@ -269,10 +269,16 @@ Building the python tools may fail unless certain options 
are passed to
 setup.py. Config.mk contains additional info how to use this variable.
 PYTHON_PREFIX_ARG=
 
-The hypervisor may be build with XSM/Flask support, which can be changed
+The hypervisor may be built with XSM/Flask support, which can be changed
 by running:
 make -C xen menuconfig
-and enabling XSM/Flask in the 'Common Features' menu.
+and enabling XSM/Flask in the 'Common Features' menu.  A security policy
+is required to use XSM/Flask; if the SELinux policy compiler is
+available, the policy from tools can be included in the hypervisor.
+This option is enabled by default if XSM is enabled and the compiler
+(checkpolicy) is found.  The location of this executable can be set
+using the environment variable.
+CHECKPOLICY=
 
 Do a build for coverage.
 coverage=y
diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 2a088ca..5500242 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -712,13 +712,15 @@ enabled by running either:
   with untrusted guests.  If a policy is provided by the bootloader, it will be
   loaded; errors will be reported to the ring buffer but will not prevent
   booting.  The policy can be changed to enforcing mode using "xl setenforce".
-* `enforcing`: This requires a security policy to be provided by the bootloader
-  and will enter enforcing mode prior to the creation of domain 0.  If a valid
-  policy is not provided, the hypervisor will not continue booting.
-* `late`: This disables loading of the security policy from the bootloader.
-  FLASK will be enabled but will not enforce access controls until a policy is
-  loaded by a domain using "xl loadpolicy".  Once a policy is loaded, FLASK 
will
-  run in enforcing mode unless "xl setenforce" has changed that setting.
+* `enforcing`: This will cause the security server to enter enforcing mode 
prior
+  to the creation of domain 0.  If an valid policy is not provided by the
+  bootloader and no built-in policy is present, the hypervisor will not 
continue
+  booting.
+* `late`: This disables loading of the built-in security policy or the policy
+  provided by the bootloader.  FLASK will be enabled but will not enforce 
access
+  controls until a policy is loaded by a domain using "xl loadpolicy".  Once a
+  policy is loaded, FLASK will run in enforcing mode unless "xl setenforce" has
+  changed that setting.
 * `disabled`: This causes the XSM framework to revert to the dummy module.  The
   dummy module provides the same security policy as is used when compiling the
   hypervisor without support for XSM.  The xsm\_op hypercall can also be used 
to
diff --git a/docs/misc/xsm-flask.txt b/docs/misc/xsm-flask.txt
index 2f42585..62f15dd 100644
--- a/docs/misc/xsm-flask.txt
+++ b/docs/misc/xsm-flask.txt
@@ -141,21 +141,21 @@ only type enforcement is used and the user and role are 
set to system_u and
 system_r for all domains.
 
 The FLASK security framework is mostly 

Re: [Xen-devel] [PATCH v6 1/2] xsm: rework policy_buffer globals

[Andrew Cooper]

On 14/07/16 15:18, Daniel De Graaf wrote:
> This makes the buffers function parameters instead of globals, in
> preparation for adding alternate locations for the policy.
>
> Signed-off-by: Daniel De Graaf 
> Reviewed-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH v6 2/2] xsm: add a default policy to .init.data

[Andrew Cooper]

On 14/07/16 15:18, Daniel De Graaf wrote:
> This adds a Kconfig option and support for including the XSM policy from
> tools/flask/policy in the hypervisor so that the bootloader does not
> need to provide a policy to get sane behavior from an XSM-enabled
> hypervisor.  The policy provided by the bootloader, if present, will
> override the built-in policy.
>
> The XSM policy is not moved out of tools because that remains the
> primary location for installing and configuring the policy.
>
> Signed-off-by: Daniel De Graaf 
> Reviewed-by: Konrad Rzeszutek Wilk 
> Reviewed-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH 6/9] xen/arm: Use check_workaround to handle the erratum 766422

[Stefano Stabellini]

On Wed, 22 Jun 2016, Julien Grall wrote:
> Currently, Xen is reading the MIDR everytime it has to check whether
> the processor is affected by the erratum 766422.
> 
> This could take advantage of the new capability bitfields to detect
> whether the processor is affected at boot time.
> 
> With this patch, the number of instructions to check the erratum is
> going down from ~13 (including 2 loads and a co-processor access) to
> ~6 instructions (include 1 load).

The patch looks good but the midr bits were actually already stored in
cpu_data.  See:


> -/* Erratum 766422: only Cortex A15 r0p4 is affected */
> -#define cpu_has_erratum_766422() \
> -(unlikely(current_cpu_data.midr.bits == 0x410fc0f4))

We weren't really accessing MIDR every time. Am I missing something?

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

Re: [Xen-devel] [PATCH 6/9] xen/arm: Use check_workaround to handle the erratum 766422

[Julien Grall]

Hi Stefano,

On 14/07/16 15:34, Stefano Stabellini wrote:

On Wed, 22 Jun 2016, Julien Grall wrote:

Currently, Xen is reading the MIDR everytime it has to check whether
the processor is affected by the erratum 766422.

This could take advantage of the new capability bitfields to detect
whether the processor is affected at boot time.

With this patch, the number of instructions to check the erratum is
going down from ~13 (including 2 loads and a co-processor access) to
~6 instructions (include 1 load).


The patch looks good but the midr bits were actually already stored in
cpu_data.  See:



-/* Erratum 766422: only Cortex A15 r0p4 is affected */
-#define cpu_has_erratum_766422() \
-(unlikely(current_cpu_data.midr.bits == 0x410fc0f4))


We weren't really accessing MIDR every time. Am I missing something?


The wording in the commit message is not clear. By "accessing the MDIR 
every time" I meant that the stored MIDR is checked every single time.


current_cpu_data turns into a complex series of assembly instructions to 
get the data of the current CPU which involves 2 loads.


I will rewrite the commit message in the next version.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH] Add optional ACPI device for Windows Continuum

[Owen Smith]

> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: 14 July 2016 14:21
> To: Owen Smith; xen-de...@lists.xenproject.org
> Subject: Re: [Xen-devel] [PATCH] Add optional ACPI device for Windows
> Continuum
> 
> On 13/07/16 10:16, Owen Smith wrote:
> > Windows 10 supports a specific ACPI device for handling the switch
> > between tablet mode and desktop mode. The meer existance of this
> > device is the mimimum to allow tablet/desktop mode to be switched.
> > Tablet mode referes to the "undocked" state where all applications are
> > forced full screen and additional touch screen elements are added,
> > such as touch keyboard, larger icons and menus, and touch gestures for
> > ease of use.
> >
> > Signed-off-by: Owen Smith 
> 
> Are there any docs which can be referenced about this device?
> 

I must have missed the links from the comment
https://msdn.microsoft.com/en-us/library/windows/hardware/dn917883(v=vs.85).aspx
https://msdn.microsoft.com/en-us/library/windows/hardware/dn457868(v=vs.85).aspx

> > ---
> >  tools/firmware/hvmloader/acpi/Makefile  |  4 ++--
> >  tools/firmware/hvmloader/acpi/build.c   | 11 ++
> >  tools/firmware/hvmloader/acpi/ssdt_conv.asl | 31
> +
> >  tools/libxl/libxl_types.idl |  1 +
> >  tools/libxl/xl_cmdimpl.c|  1 +
> >  5 files changed, 46 insertions(+), 2 deletions(-)  create mode 100644
> > tools/firmware/hvmloader/acpi/ssdt_conv.asl
> >
> > diff --git a/tools/firmware/hvmloader/acpi/Makefile
> > b/tools/firmware/hvmloader/acpi/Makefile
> > index d3e882a..d75c7af 100644
> > --- a/tools/firmware/hvmloader/acpi/Makefile
> > +++ b/tools/firmware/hvmloader/acpi/Makefile
> > @@ -25,7 +25,7 @@ CFLAGS += $(CFLAGS_xeninclude)  vpath iasl $(PATH)
> >  all: acpi.a
> >
> > -ssdt_s3.h ssdt_s4.h ssdt_pm.h ssdt_tpm.h: %.h: %.asl iasl
> > +ssdt_s3.h ssdt_s4.h ssdt_conv.h ssdt_pm.h ssdt_tpm.h: %.h: %.asl iasl
> > iasl -vs -p $* -tc $<
> > sed -e 's/AmlCode/$*/g' $*.hex >$@
> > rm -f $*.hex $*.aml
> > @@ -56,7 +56,7 @@ iasl:
> > @echo
> > @exit 1
> >
> > -build.o: ssdt_s3.h ssdt_s4.h ssdt_pm.h ssdt_tpm.h
> > +build.o: ssdt_s3.h ssdt_s4.h ssdt_conv.h ssdt_pm.h ssdt_tpm.h
> >
> >  acpi.a: $(OBJS)
> > $(AR) rc $@ $(OBJS)
> > diff --git a/tools/firmware/hvmloader/acpi/build.c
> > b/tools/firmware/hvmloader/acpi/build.c
> > index 1f7103e..6485ac8 100644
> > --- a/tools/firmware/hvmloader/acpi/build.c
> > +++ b/tools/firmware/hvmloader/acpi/build.c
> > @@ -18,6 +18,7 @@
> >  #include "acpi2_0.h"
> >  #include "ssdt_s3.h"
> >  #include "ssdt_s4.h"
> > +#include "ssdt_conv.h"
> >  #include "ssdt_tpm.h"
> >  #include "ssdt_pm.h"
> >  #include "../config.h"
> > @@ -398,6 +399,16 @@ static int construct_secondary_tables(unsigned
> long *table_ptrs,
> >  printf("S4 disabled\n");
> >  }
> >
> > +if ( !strncmp(xenstore_read("platform/acpi_conv", "1"), "1", 1) )
> > +{
> > +ssdt = mem_alloc(sizeof(ssdt_conv), 16);
> > +if (!ssdt) return -1;
> > +memcpy(ssdt, ssdt_conv, sizeof(ssdt_conv));
> > +table_ptrs[nr_tables++] = (unsigned long)ssdt;
> > +} else {
> > +printf("Conv disabled\n");
> > +}
> 
> I would drop this else clause.  It isn't interesting in the general case, and
> anyone who doesn't know exactly what Conv is will be confused by it.
> 

Sure

> > +
> >  /* TPM TCPA and SSDT. */
> >  tis_hdr = (uint16_t *)0xFED40F00;
> >  if ( (tis_hdr[0] == tis_signature[0]) && diff --git
> > a/tools/firmware/hvmloader/acpi/ssdt_conv.asl
> > b/tools/firmware/hvmloader/acpi/ssdt_conv.asl
> > new file mode 100644
> > index 000..6e20340
> > --- /dev/null
> > +++ b/tools/firmware/hvmloader/acpi/ssdt_conv.asl
> > @@ -0,0 +1,31 @@
> > +/*
> > + * ssdt_conv.asl
> > + *
> > + * Copyright (c) 2015  Citrix Systems, Inc.
> 
> Year.
> 

Ok

> > + *
> > + * 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 .
> 
> Be aware that there is currently an ongoing effort to re-licence all the apci
> work as LGPL, and move the acpi/ subdirectory into being a separate
> standalone library.
> 
> ~Andrew
> 
> > + */
> > +
> > +DefinitionBlock ("SSDT_CONV.aml", "SSDT", 2, "Xen", "HVM", 0) {
> > +Device(CONV)
> > +{
> > +Method(_HID, 0x0, NotSerialized)
> > 

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

[osstest service owner]

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

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  950e6bcc335db96003cb360109a82c8b51e2957f
baseline version:
 xen  a07e920bbffc5cd64c8e4902b9fbca746bb81aff

Last test of basis97276  2016-07-13 18:01:21 Z0 days
Testing same since97302  2016-07-14 12:02:04 Z0 days1 attempts


People who touched revisions under test:
  Julien Grall 

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=950e6bcc335db96003cb360109a82c8b51e2957f
+ . ./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 
950e6bcc335db96003cb360109a82c8b51e2957f
+ branch=xen-unstable-smoke
+ revision=950e6bcc335db96003cb360109a82c8b51e2957f
+ . ./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
+ '[' x950e6bcc335db96003cb360109a82c8b51e2957f = 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/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 
'git://cache:9419/https://github

[Xen-devel] [PATCH v2] XSM-Policy: allow source domain access to setpodtarget and getpodtarget for ballooning.

[Anshul Makkar]

Access to setpodtarget and getpodtarget is required by dom0 to set the balloon
targets for domU. The patch gives source domain (dom0) access to set
this target for domU and resolve the following permission denied erro
message during ballooning :
avc:  denied  { setpodtarget } for domid=0 target=9
scontext=system_u:system_r:dom0_t
tcontext=system_u:system_r:domU_t tclass=domain

Signed-off-by: Anshul Makkar 
Acked-by: Daniel De Graaf 
---
Changed Since V1:
 * added getpodtarget.

 tools/flask/policy/modules/xen.if | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/flask/policy/modules/xen.if 
b/tools/flask/policy/modules/xen.if
index 8c43c28..dbefa1e 100644
--- a/tools/flask/policy/modules/xen.if
+++ b/tools/flask/policy/modules/xen.if
@@ -83,7 +83,8 @@ define(`create_domain_build_label', `
 define(`manage_domain', `
allow $1 $2:domain { getdomaininfo getvcpuinfo getaffinity
getaddrsize pause unpause trigger shutdown destroy
-   setaffinity setdomainmaxmem getscheduler resume };
+   setaffinity setdomainmaxmem getscheduler resume
+   setpodtarget getpodtarget };
 allow $1 $2:domain2 set_vnumainfo;
 ')
 
-- 
1.9.1


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

Re: [Xen-devel] [PATCH 1/2] xen: fix a (latent) cpupool-related race during domain destroy

[Dario Faggioli]

On Thu, 2016-07-14 at 10:37 +0100, Andrew Cooper wrote:
> On 14/07/16 07:41, Dario Faggioli wrote:
> > 
> > So, during domain destruction, we do:
> >  cpupool_rm_domain()[ in domain_destroy() ]
> >  sched_destroy_domain() [ in complete_domain_destroy() ]
> > 
> > Therefore, there's a window during which, from the
> > scheduler's point of view, a domain is still there, but
> > without it being part of any cpupool.
> > 
> > [...]
> >
> > On the other hand, cpupool_rm_domain() "only" does
> > cpupool related bookkeeping, and there's no harm
> > postponing it a little bit.
> > 
> > Finally, considering that, during domain initialization,
> > we do:
> >  cpupool_add_domain()
> >  sched_init_domain()
> > 
> > It looks like it makes much more sense for the domain
> > destroy path to look like the opposite of it, i.e.:
> >  sched_destroy_domain()
> >  cpupool_rm_domain()
> > 
> > This patch does that, and it's considered worth, as it
> > fixes a bug, even if only a latent one.
> > 
> > Signed-off-by: Dario Faggioli 
> As the cpupool bookkeeping is very closely related to the scheduler
> bookkeeping, how about having the sched_*_domain() functions involve
> the
> cpupool_*_domain() functions?
> 
That's certainly a good point.

At minimum, I certainly can (and probably should have :-P) put a couple
of ASSERT()-s in place.

However, both cpupool_add_domain() and cpupool_rm_domain() are called
only once, and I guess I can make them go into sched_init_domain() and
sched_destroy_domain(), respectively.

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



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

Re: [Xen-devel] [PATCH 1/2] xen: fix a (latent) cpupool-related race during domain destroy

[Andrew Cooper]

On 14/07/16 15:54, Dario Faggioli wrote:
> On Thu, 2016-07-14 at 10:37 +0100, Andrew Cooper wrote:
>> On 14/07/16 07:41, Dario Faggioli wrote:
>>> So, during domain destruction, we do:
>>>  cpupool_rm_domain()[ in domain_destroy() ]
>>>  sched_destroy_domain() [ in complete_domain_destroy() ]
>>>
>>> Therefore, there's a window during which, from the
>>> scheduler's point of view, a domain is still there, but
>>> without it being part of any cpupool.
>>>
>>> [...]
>>>
>>> On the other hand, cpupool_rm_domain() "only" does
>>> cpupool related bookkeeping, and there's no harm
>>> postponing it a little bit.
>>>
>>> Finally, considering that, during domain initialization,
>>> we do:
>>>  cpupool_add_domain()
>>>  sched_init_domain()
>>>
>>> It looks like it makes much more sense for the domain
>>> destroy path to look like the opposite of it, i.e.:
>>>  sched_destroy_domain()
>>>  cpupool_rm_domain()
>>>
>>> This patch does that, and it's considered worth, as it
>>> fixes a bug, even if only a latent one.
>>>
>>> Signed-off-by: Dario Faggioli 
>> As the cpupool bookkeeping is very closely related to the scheduler
>> bookkeeping, how about having the sched_*_domain() functions involve
>> the
>> cpupool_*_domain() functions?
>>
> That's certainly a good point.
>
> At minimum, I certainly can (and probably should have :-P) put a couple
> of ASSERT()-s in place.
>
> However, both cpupool_add_domain() and cpupool_rm_domain() are called
> only once, and I guess I can make them go into sched_init_domain() and
> sched_destroy_domain(), respectively.

I think that would be the most robust solution.

~Andrew

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

Re: [Xen-devel] [PATCH 7/9] xen/arm: traps: MMIO should only be emulated for fault translation

[Stefano Stabellini]

On Wed, 22 Jun 2016, Julien Grall wrote:
> The function do_trap_data_abort_guest assumes that a stage-2 data abort
> can only be taken for a translation fault or permission fault today.
> 
> Whilst this is true today, it might not be in the future. Rather than
> emulating the MMIO for any fault other than the permission one, print
> a warning message when the fault is not handled by Xen.
> 
> Signed-off-by: Julien Grall 
> ---
>  xen/arch/arm/traps.c | 51 ---
>  1 file changed, 28 insertions(+), 23 deletions(-)
> 
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 785e3e9..591de3c 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -2468,35 +2468,40 @@ static void do_trap_data_abort_guest(struct 
> cpu_user_regs *regs,
>  /* Trap was triggered by mem_access, work here is done */
>  if ( !rc )
>  return;
> +break;
>  }
> -break;
> -}
> -
> -if ( dabt.s1ptw )
> -goto bad_data_abort;
> +case FSC_FLT_TRANS:
> +if ( dabt.s1ptw )
> +goto bad_data_abort;
>  
> -/* XXX: Decode the instruction if ISS is not valid */
> -if ( !dabt.valid )
> -goto bad_data_abort;
> +/* XXX: Decode the instruction if ISS is not valid */
> +if ( !dabt.valid )
> +goto bad_data_abort;
>  
> -/*
> - * Erratum 766422: Thumb store translation fault to Hypervisor may
> - * not have correct HSR Rt value.
> - */
> -if ( check_workaround_766422() && (regs->cpsr & PSR_THUMB) && dabt.write 
> )
> -{
> -rc = decode_instruction(regs, &info.dabt);
> -if ( rc )
> +/*
> + * Erratum 766422: Thumb store translation fault to Hypervisor may
> + * not have correct HSR Rt value.
> + */
> +if ( check_workaround_766422() && (regs->cpsr & PSR_THUMB) &&
> + dabt.write )
>  {
> -gprintk(XENLOG_DEBUG, "Unable to decode instruction\n");
> -goto bad_data_abort;
> +rc = decode_instruction(regs, &info.dabt);
> +if ( rc )
> +{
> +gprintk(XENLOG_DEBUG, "Unable to decode instruction\n");
> +goto bad_data_abort;
> +}
>  }
> -}
>  
> -if (handle_mmio(&info))
> -{
> -advance_pc(regs, hsr);
> -return;
> +if ( handle_mmio(&info) )
> +{
> +advance_pc(regs, hsr);
> +return;
> +}
> +break;
> +default:
> +gprintk(XENLOG_WARNING, "Unsupported DFSC: HSR=%#x DFSC=%#x\n",
> +hsr.bits, dabt.dfsc);

Given that bad_data_abort, which is right after, will print HSR again, I
would remove it from this message as it's redundant.


>  }
>  
>  bad_data_abort:
> -- 
> 1.9.1
> 

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

Re: [Xen-devel] [PATCH v6 1/2] xsm: rework policy_buffer globals

[Andrew Cooper]

On 14/07/16 15:18, Daniel De Graaf wrote:
> This makes the buffers function parameters instead of globals, in
> preparation for adding alternate locations for the policy.
>
> Signed-off-by: Daniel De Graaf 
> Reviewed-by: Jan Beulich 
> ---

Reviewed and committed both patches.

~Andrew

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

Re: [Xen-devel] [PATCH v2] XSM-Policy: allow source domain access to setpodtarget and getpodtarget for ballooning.

[Andrew Cooper]

On 14/07/16 15:46, Anshul Makkar wrote:
> Access to setpodtarget and getpodtarget is required by dom0 to set the balloon
> targets for domU. The patch gives source domain (dom0) access to set
> this target for domU and resolve the following permission denied erro
> message during ballooning :
> avc:  denied  { setpodtarget } for domid=0 target=9
> scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:domU_t tclass=domain
>
> Signed-off-by: Anshul Makkar 
> Acked-by: Daniel De Graaf 

Committed, thanks.

~Andrew

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

Re: [Xen-devel] [PATCH 0/8] x86: audit and remove needless module.h includes

[Paul Gortmaker]

[Re: [PATCH 0/8] x86: audit and remove needless module.h includes] On 
14/07/2016 (Thu 15:04) Ingo Molnar wrote:

> 
> * Paul Gortmaker  wrote:
> 
> > To that end, I have done allmodconfig, allyesconfig and allnoconfig
> > for both 32 bit and 64 bit x86 with these changes on the linux-next
> > from today, which presumably has an up to date copy of tip in it.
> 
> It does, still I get this on allnoconfig with your patches applied:

Took me a while to figure out why I didn't see this; I was able to
finally reproduce it on x86-32 with allnoconfig but CONFIG_SMP=y.

> 
> arch/x86/kernel/setup_percpu.c: In function ‘setup_percpu_segment’:
> arch/x86/kernel/setup_percpu.c:159:2: error: implicit declaration of function 
> ‘pack_descriptor’ [-Werror=implicit-function-declaration]
>   pack_descriptor(&gdt, per_cpu_offset(cpu), 0xF,
>   ^
> arch/x86/kernel/setup_percpu.c:162:2: error: implicit declaration of function 
> ‘write_gdt_entry’ [-Werror=implicit-function-declaration]
>   write_gdt_entry(get_cpu_gdt_table(cpu),
>   ^
> arch/x86/kernel/setup_percpu.c:162:18: error: implicit declaration of 
> function 
> ‘get_cpu_gdt_table’ [-Werror=implicit-function-declaration]
>   write_gdt_entry(get_cpu_gdt_table(cpu),

All three of these guys live in asm/desc.h and adding that to the top of
arch/x86/kernel/setup_percpu.c asm include list seems to fix the
reproducer I now have here.

> 
> I'll continue testing with the setup_percpu.c change left out.

Let me know if you want a resend or if you want to just add the
asm/desc.h locally or ...

Paul.
--

> 
> Thanks,
> 
>   Ingo

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

Re: [Xen-devel] [PATCH 8/9] xen/arm: traps: Avoid unnecessary VA -> IPA translation in abort handlers

[Stefano Stabellini]

On Wed, 22 Jun 2016, Julien Grall wrote:
> Translating a VA to a IPA is expensive. Currently, Xen is assuming that
> HPFAR_EL2 is only valid when the stage-2 data/instruction abort happened
> during a translation table walk of a first stage translation (i.e S1PTW
> is set).
> 
> However, based on the ARM ARM (D7.2.34 in DDI 0487A.j), the register is
> also valid when the data/instruction abort occured for a translation
> fault.
> 
> With this change, the VA -> IPA translation will only happen for
> permission faults that are not related to a translation table of a
> first stage translation.
> 
> Signed-off-by: Julien Grall 
>
>  xen/arch/arm/traps.c | 22 +++---
>  1 file changed, 19 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 591de3c..0edc2cc 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -2383,13 +2383,28 @@ static inline paddr_t get_faulting_ipa(vaddr_t gva)
>  return ipa;
>  }
>  
> +static inline bool hpfar_is_valid(bool s1ptw, uint8_t fsc)
> +{
> +/*
> + * HPFAR is valid if one of the following cases are true:
> + *  1. the stage 2 fault happen during a stage 1 page table walk
> + *  (the bit ESR_EL2.S1PTW is set)
> + *  2. the fault was due to a translation fault
> + *
> + * Note that technically HPFAR is valid for other cases, but they
> + * are currently not supported by Xen.
> + */
> +return s1ptw || (fsc == FSC_FLT_TRANS);
> +}
> +
>  static void do_trap_instr_abort_guest(struct cpu_user_regs *regs,
>const union hsr hsr)
>  {
>  int rc;
>  register_t gva = READ_SYSREG(FAR_EL2);
> +uint8_t fsc = hsr.iabt.ifsc & ~FSC_LL_MASK;
>  
> -switch ( hsr.iabt.ifsc & ~FSC_LL_MASK )
> +switch ( fsc )
>  {
>  case FSC_FLT_PERM:
>  {
> @@ -2400,7 +2415,7 @@ static void do_trap_instr_abort_guest(struct 
> cpu_user_regs *regs,
>  .kind = hsr.iabt.s1ptw ? npfec_kind_in_gpt : npfec_kind_with_gla
>  };
>  
> -if ( hsr.iabt.s1ptw )
> +if ( hpfar_is_valid(hsr.iabt.s1ptw, fsc) )
>  gpa = get_faulting_ipa(gva);
>  else
>  {
> @@ -2435,6 +2450,7 @@ static void do_trap_data_abort_guest(struct 
> cpu_user_regs *regs,
>  const struct hsr_dabt dabt = hsr.dabt;
>  int rc;
>  mmio_info_t info;
> +uint8_t fsc = hsr.dabt.dfsc & ~FSC_LL_MASK;

You should be able to modify the switch in this case too, right?


>  info.dabt = dabt;
>  #ifdef CONFIG_ARM_32
> @@ -2443,7 +2459,7 @@ static void do_trap_data_abort_guest(struct 
> cpu_user_regs *regs,
>  info.gva = READ_SYSREG64(FAR_EL2);
>  #endif
>  
> -if ( dabt.s1ptw )
> +if ( hpfar_is_valid(hsr.iabt.s1ptw, fsc) )
>  info.gpa = get_faulting_ipa(info.gva);
>  else
>  {
> -- 
> 1.9.1
> 

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

Re: [Xen-devel] [PATCH 7/9] xen/arm: traps: MMIO should only be emulated for fault translation

[Stefano Stabellini]

On Thu, 14 Jul 2016, Julien Grall wrote:
> Hi Stefano,
> 
> On 14/07/16 16:06, Stefano Stabellini wrote:
> > On Wed, 22 Jun 2016, Julien Grall wrote:
> > > -if (handle_mmio(&info))
> > > -{
> > > -advance_pc(regs, hsr);
> > > -return;
> > > +if ( handle_mmio(&info) )
> > > +{
> > > +advance_pc(regs, hsr);
> > > +return;
> > > +}
> > > +break;
> > > +default:
> > > +gprintk(XENLOG_WARNING, "Unsupported DFSC: HSR=%#x DFSC=%#x\n",
> > > +hsr.bits, dabt.dfsc);
> > 
> > Given that bad_data_abort, which is right after, will print HSR again, I
> > would remove it from this message as it's redundant.
> 
> I agree this is redundant, however the message below will only be printed in
> debug build because a guest could trigger it easily. The message above is here
> to catch any possible misconfiguration of stage-2 page table or hardware issue
> (ECC error, address size, TLB conflict...) and could be seen in non-debug
> build.

Fair enough, it will just look a bit weird in the source code.

Reviewed-by: Stefano Stabellini 

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

Re: [Xen-devel] [PATCH 7/9] xen/arm: traps: MMIO should only be emulated for fault translation

[Julien Grall]

On 14/07/16 16:28, Stefano Stabellini wrote:

On Thu, 14 Jul 2016, Julien Grall wrote:

Hi Stefano,

On 14/07/16 16:06, Stefano Stabellini wrote:

On Wed, 22 Jun 2016, Julien Grall wrote:

-if (handle_mmio(&info))
-{
-advance_pc(regs, hsr);
-return;
+if ( handle_mmio(&info) )
+{
+advance_pc(regs, hsr);
+return;
+}
+break;
+default:
+gprintk(XENLOG_WARNING, "Unsupported DFSC: HSR=%#x DFSC=%#x\n",
+hsr.bits, dabt.dfsc);


Given that bad_data_abort, which is right after, will print HSR again, I
would remove it from this message as it's redundant.


I agree this is redundant, however the message below will only be printed in
debug build because a guest could trigger it easily. The message above is here
to catch any possible misconfiguration of stage-2 page table or hardware issue
(ECC error, address size, TLB conflict...) and could be seen in non-debug
build.


Fair enough, it will just look a bit weird in the source code.


Would a comment in the source code make it less weird?



Reviewed-by: Stefano Stabellini 



--
Julien Grall

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

Re: [Xen-devel] [PATCH 7/9] xen/arm: traps: MMIO should only be emulated for fault translation

[Julien Grall]

Hi Stefano,

On 14/07/16 16:06, Stefano Stabellini wrote:

On Wed, 22 Jun 2016, Julien Grall wrote:

-if (handle_mmio(&info))
-{
-advance_pc(regs, hsr);
-return;
+if ( handle_mmio(&info) )
+{
+advance_pc(regs, hsr);
+return;
+}
+break;
+default:
+gprintk(XENLOG_WARNING, "Unsupported DFSC: HSR=%#x DFSC=%#x\n",
+hsr.bits, dabt.dfsc);


Given that bad_data_abort, which is right after, will print HSR again, I
would remove it from this message as it's redundant.


I agree this is redundant, however the message below will only be 
printed in debug build because a guest could trigger it easily. The 
message above is here to catch any possible misconfiguration of stage-2 
page table or hardware issue (ECC error, address size, TLB conflict...) 
and could be seen in non-debug build.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH V3 01/10] arm/gic-v3: Use acpi_table_parse_madt() to parse MADT subtables

[Shanker Donthineni]

Hi Stefano/Juilen

On 07/14/2016 09:18 AM, Stefano Stabellini wrote:

On Mon, 27 Jun 2016, Shanker Donthineni wrote:

The function acpi_table_parse_madt() does the same functionality as
function acpi_parse_entries() expect it takes a few arguments.

Signed-off-by: Shanker Donthineni 

I committed patches 1 to 7



Thanks, I'll post the remaining patches for code review.


--
Shanker Donthineni
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.


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

Re: [Xen-devel] [PATCH 8/9] xen/arm: traps: Avoid unnecessary VA -> IPA translation in abort handlers

[Julien Grall]

On 14/07/16 16:27, Stefano Stabellini wrote:

On Wed, 22 Jun 2016, Julien Grall wrote:

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 591de3c..0edc2cc 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2383,13 +2383,28 @@ static inline paddr_t get_faulting_ipa(vaddr_t gva)


[..]


  static void do_trap_instr_abort_guest(struct cpu_user_regs *regs,
const union hsr hsr)
  {
  int rc;
  register_t gva = READ_SYSREG(FAR_EL2);
+uint8_t fsc = hsr.iabt.ifsc & ~FSC_LL_MASK;

-switch ( hsr.iabt.ifsc & ~FSC_LL_MASK )
+switch ( fsc )
  {
  case FSC_FLT_PERM:
  {
@@ -2400,7 +2415,7 @@ static void do_trap_instr_abort_guest(struct 
cpu_user_regs *regs,
  .kind = hsr.iabt.s1ptw ? npfec_kind_in_gpt : npfec_kind_with_gla
  };

-if ( hsr.iabt.s1ptw )
+if ( hpfar_is_valid(hsr.iabt.s1ptw, fsc) )
  gpa = get_faulting_ipa(gva);
  else
  {
@@ -2435,6 +2450,7 @@ static void do_trap_data_abort_guest(struct cpu_user_regs 
*regs,
  const struct hsr_dabt dabt = hsr.dabt;
  int rc;
  mmio_info_t info;
+uint8_t fsc = hsr.dabt.dfsc & ~FSC_LL_MASK;


You should be able to modify the switch in this case too, right?


Correct. I am thinking to pull the changes in patch #4 to avoid 
extra-changes in this patch.


Regards,

--
Julien Grall

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

Re: [Xen-devel] [v9 00/19] QEMU:Xen stubdom vTPM for HVM virtual machine(QEMU Part)

[Stefano Stabellini]

Hi Quan,

thanks for CC'ing me. sstabell...@kernel.org is the right address to
reach me now.

I am also CC'ing Anthony Perard who is Xen co-maintainer in QEMU.

Cheers,

Stefano

On Wed, 13 Jul 2016, Xu, Quan wrote:
> Emil, Thanks for your  effort ( today I just come back to return my laptop).
> 
> btw, sstabell...@kernel.org may be the right email.
>  Stefan / Stefano,  could you help us review these patches? Thanks in 
> advance!!
> 
> Quan 
> 
>  
> On July 10, 2016 7:48 PM, Emil Condrea  wrote:
> > *INTRODUCTION*
> > The goal of virtual Trusted Platform Module (vTPM) is to provide a TPM
> > functionality to virtual machines (Fedora, Ubuntu, Redhat, Windows .etc).
> > This allows programs to interact with a TPM in a virtual machine the same 
> > way
> > they interact with a TPM on the physical system. Each virtual machine gets 
> > its
> > own unique, emulated, software TPM. Each major component of vTPM is
> > implemented as a stubdom, providing secure separation guaranteed by the
> > hypervisor.
> > 
> > The vTPM stubdom is a Xen mini-OS domain that emulates a TPM for the
> > virtual machine to use. It is a small wrapper around the Berlios TPM 
> > emulator.
> > TPM commands are passed from mini-os TPM backend driver.
> > 
> > *ARCHITECTURE*
> > The architecture of stubdom vTPM for HVM virtual machine:
> > 
> > ++
> > | Windows/Linux DomU | ...
> > ||  ^|
> > |v  ||
> > |  Qemu tpm1.2 Tis   |
> > ||  ^|
> > |v  ||
> > | XenStubdoms backend|
> > ++
> >  |  ^
> >  v  |
> > ++
> > |  XenDevOps |
> > ++
> >  |  ^
> >  v  |
> > ++
> > |  mini-os/tpmback   |
> > ||  ^|
> > |v  ||
> > |   vtpm-stubdom | ...
> > ||  ^|
> > |v  ||
> > |  mini-os/tpmfront  |
> > ++
> >  |  ^
> >  v  |
> > ++
> > |  mini-os/tpmback   |
> > ||  ^|
> > |v  ||
> > |  vtpmmgr-stubdom   |
> > ||  ^|
> > |v  ||
> > |  mini-os/tpm_tis   |
> > ++
> >  |  ^
> >  v  |
> > ++
> > |Hardware TPM|
> > ++
> > 
> >  * Windows/Linux DomU:
> > The HVM based guest that wants to use a vTPM. There may be
> > more than one of these.
> > 
> >  * Qemu tpm1.2 Tis:
> > Implementation of the tpm1.2 Tis interface for HVM virtual
> > machines. It is Qemu emulation device.
> > 
> >  * vTPM xenstubdoms driver:
> > Qemu vTPM driver. This driver provides vtpm initialization
> > and sending data and commends to a para-virtualized vtpm
> > stubdom.
> > 
> >  * XenDevOps:
> > Register Xen stubdom vTPM frontend driver, and transfer any
> > request/repond between TPM xenstubdoms driver and Xen vTPM
> > stubdom. Facilitate communications between Xen vTPM stubdom
> > and vTPM xenstubdoms driver.
> > 
> >  * mini-os/tpmback:
> > Mini-os TPM backend driver. The Linux frontend driver connects
> > to this backend driver to facilitate communications between the
> > Linux DomU and its vTPM. This driver is also used by vtpmmgr
> > stubdom to communicate with vtpm-stubdom.
> > 
> >  * vtpm-stubdom:
> > A mini-os stub domain that implements a vTPM. There is a
> > one to one mapping between running vtpm-stubdom instances and
> > logical vtpms on the system. The vTPM Platform Configuration
> > Registers (PCRs) are all initialized to zero.
> > 
> >  * mini-os/tpmfront:
> > Mini-os TPM frontend driver. The vTPM mini-os domain vtpm
> > stubdom uses this driver to communicate with vtpmmgr-stubdom.
> > This driver could also be used separately to implement a mini-os
> > domain that wishes to use a vTPM of its own.
> > 
> >  * vtpmmgr-stubdom:
> > A mini-os domain that implements the vTPM manager. There is only
> > one vTPM manager and it should be running during the entire lifetime
> > of the machine. vtpmmgr domain securely stores encryption keys for
> > each of the vtpms and accesses to the hardware TPM to get the root of
> > trust for the entire system.
> > 
> >  * mini-os/tpm_tis:
> > Mini-os TPM version 1.2 TPM Interface Specification (TIS) driver.
> > This driver used by vtpmmgr-stubdom to talk directly to the h

Re: [Xen-devel] [PATCH 8/9] xen/arm: traps: Avoid unnecessary VA -> IPA translation in abort handlers

[Stefano Stabellini]

On Thu, 14 Jul 2016, Julien Grall wrote:
> On 14/07/16 16:27, Stefano Stabellini wrote:
> > On Wed, 22 Jun 2016, Julien Grall wrote:
> > > diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> > > index 591de3c..0edc2cc 100644
> > > --- a/xen/arch/arm/traps.c
> > > +++ b/xen/arch/arm/traps.c
> > > @@ -2383,13 +2383,28 @@ static inline paddr_t get_faulting_ipa(vaddr_t
> > > gva)
> 
> [..]
> 
> > >   static void do_trap_instr_abort_guest(struct cpu_user_regs *regs,
> > > const union hsr hsr)
> > >   {
> > >   int rc;
> > >   register_t gva = READ_SYSREG(FAR_EL2);
> > > +uint8_t fsc = hsr.iabt.ifsc & ~FSC_LL_MASK;
> > > 
> > > -switch ( hsr.iabt.ifsc & ~FSC_LL_MASK )
> > > +switch ( fsc )
> > >   {
> > >   case FSC_FLT_PERM:
> > >   {
> > > @@ -2400,7 +2415,7 @@ static void do_trap_instr_abort_guest(struct
> > > cpu_user_regs *regs,
> > >   .kind = hsr.iabt.s1ptw ? npfec_kind_in_gpt :
> > > npfec_kind_with_gla
> > >   };
> > > 
> > > -if ( hsr.iabt.s1ptw )
> > > +if ( hpfar_is_valid(hsr.iabt.s1ptw, fsc) )
> > >   gpa = get_faulting_ipa(gva);
> > >   else
> > >   {
> > > @@ -2435,6 +2450,7 @@ static void do_trap_data_abort_guest(struct
> > > cpu_user_regs *regs,
> > >   const struct hsr_dabt dabt = hsr.dabt;
> > >   int rc;
> > >   mmio_info_t info;
> > > +uint8_t fsc = hsr.dabt.dfsc & ~FSC_LL_MASK;
> > 
> > You should be able to modify the switch in this case too, right?
> 
> Correct. I am thinking to pull the changes in patch #4 to avoid extra-changes
> in this patch.

Sure

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

Re: [Xen-devel] [PATCH 9/9] xen/arm: arm64: Add Cortex-A57 erratum 834220 workaround

[Stefano Stabellini]

On Wed, 22 Jun 2016, Julien Grall wrote:
> The ARM erratum applies to certain revisions of Cortex-A57. The
> processor may report a Stage 2 translation fault as the result of
> Stage 1 fault for load crossing a page boundary when there is a
> permission fault or device memory fault at stage 1 and a translation
> fault at Stage 2.
> 
> So Xen needs to check that Stage 1 translation does not generate a fault
> before handling the Stage 2 fault. If it is a Stage 1 translation fault,
> return to the guest to let the processor injecting the correct fault.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


>  docs/misc/arm/silicon-errata.txt |  1 +
>  xen/arch/arm/Kconfig | 21 +
>  xen/arch/arm/cpuerrata.c |  9 +
>  xen/arch/arm/traps.c |  5 +++--
>  xen/include/asm-arm/cpuerrata.h  |  1 +
>  xen/include/asm-arm/cpufeature.h |  3 ++-
>  6 files changed, 37 insertions(+), 3 deletions(-)
> 
> diff --git a/docs/misc/arm/silicon-errata.txt 
> b/docs/misc/arm/silicon-errata.txt
> index 220f724..c9854c3 100644
> --- a/docs/misc/arm/silicon-errata.txt
> +++ b/docs/misc/arm/silicon-errata.txt
> @@ -47,3 +47,4 @@ stable hypervisors.
>  | ARM| Cortex-A53  | #819472 | ARM64_ERRATUM_819472  
>   |
>  | ARM| Cortex-A57  | #852523 | N/A   
>   |
>  | ARM| Cortex-A57  | #832075 | ARM64_ERRATUM_832075  
>   |
> +| ARM| Cortex-A57  | #834220 | ARM64_ERRATUM_834220  
>   |
> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> index e26c4c8..871c243 100644
> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -142,6 +142,27 @@ config ARM64_ERRATUM_832075
>  
> If unsure, say Y.
>  
> +config ARM64_ERRATUM_834220
> + bool "Cortex-A57: 834220: Stage 2 translation fault might be 
> incorrectly reported in presence of a Stage 1 fault"
> + default y
> + depends on ARM_64
> + help
> +   This option adds an alternative code sequence to work around ARM
> +   erratum 834220 on Cortex-A57 parts up to r1p2.
> +
> +   Affected Cortex-A57 parts might report a Stage 2 translation
> +   fault as the result of a Stage 1 fault for load crossing a
> +   page boundary when there is a permission or device memory
> +   alignment fault at Stage 1 and a translation fault at Stage 2.
> +
> +   The workaround is to verify that the Stage 1 translation
> +   doesn't generate a fault before handling the Stage 2 fault.
> +   Please note that this does not necessarily enable the workaround,
> +   as it depends on the alternative framework, which will only patch
> +   the kernel if an affected CPU is detected.
> +
> +   If unsure, say Y.
> +
>  endmenu
>  
>  source "common/Kconfig"
> diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
> index 748e02e..a3e8dda 100644
> --- a/xen/arch/arm/cpuerrata.c
> +++ b/xen/arch/arm/cpuerrata.c
> @@ -49,6 +49,15 @@ static const struct arm_cpu_capabilities arm_errata[] = {
> (1 << MIDR_VARIANT_SHIFT) | 2),
>  },
>  #endif
> +#ifdef CONFIG_ARM64_ERRATUM_834220
> +{
> +/* Cortex-A57 r0p0 - r1p2 */
> +.desc = "ARM erratum 834220",
> +.capability = ARM64_WORKAROUND_834220,
> +MIDR_RANGE(MIDR_CORTEX_A57, 0x00,
> +   (1 << MIDR_VARIANT_SHIFT) | 2),
> +},
> +#endif
>  {},
>  };
>  
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 0edc2cc..57e02e3 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -2389,12 +2389,13 @@ static inline bool hpfar_is_valid(bool s1ptw, uint8_t 
> fsc)
>   * HPFAR is valid if one of the following cases are true:
>   *  1. the stage 2 fault happen during a stage 1 page table walk
>   *  (the bit ESR_EL2.S1PTW is set)
> - *  2. the fault was due to a translation fault
> + *  2. the fault was due to a translation fault and the processor
> + *  does not carry erratum #8342220
>   *
>   * Note that technically HPFAR is valid for other cases, but they
>   * are currently not supported by Xen.
>   */
> -return s1ptw || (fsc == FSC_FLT_TRANS);
> +return s1ptw || (fsc == FSC_FLT_TRANS && !check_workaround_834220());
>  }
>  
>  static void do_trap_instr_abort_guest(struct cpu_user_regs *regs,
> diff --git a/xen/include/asm-arm/cpuerrata.h b/xen/include/asm-arm/cpuerrata.h
> index aaf3edd..d3d3080 100644
> --- a/xen/include/asm-arm/cpuerrata.h
> +++ b/xen/include/asm-arm/cpuerrata.h
> @@ -41,6 +41,7 @@ static inline bool_t check_workaround_##erratum(void)   
> \
>  #endif
>  
>  CHECK_WORKAROUND_HELPER(766422, ARM32_WORKAROUND_766422, CONFIG_ARM_32)
> +CHECK_WORKAROUND_HELPER(834220, ARM64_WORKAROUND_834220, CONFIG_ARM_64)
>  
>  #undef CHECK_WORKAROUND_HELPER
>  
> diff --git a/xen/include/asm-arm/cpufeature.h 
> b/xen/include/asm-arm/cpufeature.h
> index

[Xen-devel] OVMF very slow on AMD

[Anthony PERARD]

Hi,

I've been investigating why OVMF is very slow  in a Xen guest on an AMD
host. This, I think, is the current failure that osstest is having.

I've only look at a specific part of OVMF where the slowdown is very
obvious on AMD vs Intel, the decompression.

This is what I get on AMD, via the Xen serial console port:
  Invoking OVMF ...
  SecCoreStartupWithStack(0xFFFCC000, 0x818000)
then, nothing for almost 1 minute, then the rest of the boot process.
The same binary on Intel, the output does not stay "stuck" here.

I could pin-point which part of the boot process takes a long time, but
there is not anything obvious in there, just a loop that decompress the
ovmf binary, with plenty of iteration.
I tried `xentrace', but the trace does not show anything wrong, there is
just an interrupt from time to time. I've tried to had some tracepoint
inside this decompresion function in OVMF, but that did not reveal
anything either, maybe there where not at the right place.

Anyway, the function is: LzmaDec_DecodeReal() from the file
IntelFrameworkModulePkg/Library/LzmaCustomDecompressLib/Sdk/C/LzmaDec.c
you can get the assembly from this object:
Build/OvmfX64/DEBUG_GCC49/X64/IntelFrameworkModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib/OUTPUT/Sdk/C/LzmaDec.obj
This is with OVMF upstream (https://github.com/tianocore/edk2).
I can send the assembly if needed.

So, this loop takes about 1 minute on my AMD machine (AMD Opteron(tm)
Processor 4284), and less that 1 second on an Intel machine.
If I compile OVMF as a 32bit binary, the loop is faster, but still takes
about 30s on AMD. (that's true for both OvmfIa32 and OvmfIa32X64 which
is 32bit bootstrap, but can start 64bit OS.)
Another thing, I tried the same binary (64bit) with KVM, and OVMF seems
fast.


So, any idee of what I could investigate?

Thanks,

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH v4] xen/arm: Add a clock property

[Stefano Stabellini]

On Thu, 14 Jul 2016, Dirk Behme wrote:
> On 14.07.2016 12:38, Stefano Stabellini wrote:
> > On Thu, 14 Jul 2016, Dirk Behme wrote:
> > > On 13.07.2016 23:03, Michael Turquette wrote:
> > > > Quoting Dirk Behme (2016-07-13 11:56:30)
> > > > > On 13.07.2016 20:43, Stefano Stabellini wrote:
> > > > > > On Wed, 13 Jul 2016, Dirk Behme wrote:
> > > > > > > On 13.07.2016 00:26, Michael Turquette wrote:
> > > > > > > > Quoting Dirk Behme (2016-07-12 00:46:45)
> > > > > > > > > Clocks described by this property are reserved for use by Xen,
> > > > > > > > > and
> > > > > > > > > the OS
> > > > > > > > > must not alter their state any way, such as disabling or
> > > > > > > > > gating a
> > > > > > > > > clock,
> > > > > > > > > or modifying its rate. Ensuring this may impose constraints on
> > > > > > > > > parent
> > > > > > > > > clocks or other resources used by the clock tree.
> > > > > > > > 
> > > > > > > > Note that clk_prepare_enable will not prevent the rate from
> > > > > > > > changing
> > > > > > > > (clk_set_rate) or a parent from changing (clk_set_parent). The
> > > > > > > > only
> > > > > > > > way
> > > > > > > > to do this currently would be to set the following flags on the
> > > > > > > > effected
> > > > > > > > clocks:
> > > > > > > > 
> > > > > > > > CLK_SET_RATE_GATE
> > > > > > > > CLK_SET_PARENT_GATE
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > Regarding setting flags, I think we already talked about that. I
> > > > > > > think
> > > > > > > the
> > > > > > > conclusion was that in our case its not possible to manipulate the
> > > > > > > flags in
> > > > > > > the OS as this isn't intended to be done in cases like ours.
> > > > > > > Therefore
> > > > > > > no API
> > > > > > > is exported for this.
> > > > > > > 
> > > > > > > I.e. if we need to set these flags, we have to do that in Xen
> > > > > > > where we
> > > > > > > add the
> > > > > > > clocks to the hypervisor node in the device tree. And not in the
> > > > > > > kernel patch
> > > > > > > discussed here.
> > > > > > 
> > > > > > These are internal Linux flags, aren't they?
> > > > > 
> > > > > 
> > > > > I've been under the impression that you can set clock "flags" via the
> > > > > device tree. Seems I need to re-check that ;)
> > > > 
> > > > Right, you cannot set flags from the device tree. Also, setting these
> > > > flags is done by the clock provider driver, not a consumer. Xen is the
> > > > consumer.
> > > 
> > > 
> > > Ok, thanks, then I think we can forget about using flags for the issue we
> > > are
> > > discussing here.
> > > 
> > > Best regards
> > > 
> > > Dirk
> > > 
> > > P.S.: Would it be an option to merge the v4 patch we are discussing here,
> > > then? From the discussion until here, it sounds to me that it's the best
> > > option we have at the moment. Maybe improving it in the future, then.
> > 
> > It might be a step in the right direction, but it doesn't really prevent
> > clk_set_rate from changing properties of a clock owned by Xen.  This
> > patch is incomplete.
> 
> 
> Let me ask then: Do we have a practical example where it's not sufficient
> practically?
> 
> To my understanding, Xen people have been happy with the "clk_ignore_unused"
> workaround since ~2 years, now [1]. And I think the "clk_ignore_unused"
> workaround does mainly the same like the patch discussed here. It doesn't care
> regarding clk_set_rate from changing properties, too?

Let me premise that I appreciate what you are trying to achieve with
this patch and I don't want to feature-creep it.

However we are defining a new Device Tree binding, one which will have
to be supported for a long time by both Xen and Linux, so at the very
least we need to have the full picture. We need to understand if the
binding if sufficient or if we need something different to solve the
problem completely.

Once we understand that, I am happy to accept a partial implementation
in Linux, as long as it is a step in the right direction. Does it make
sense?



> While I agree that the patch theoretically incomplete, if nobody has a real
> world example I would think that from practical point of view it's sufficient
> in a first step.
> 
> If this is the case, I'd propose to fix the practical issue in a first step
> with a patch (this one) which is sufficient to fix the issues the Xen users
> have. And update the code for theoretical future issues in a second step.
> 
> Best regards
> 
> Dirk
> 
> [1] http://bugs.xenproject.org/xen/bug/45
> 
> 
> > We need to understand at least what it would take
> > to have a complete solution.
> > 
> > Michael, do you have any suggestions on how it would be possible to set
> > CLK_SET_RATE_GATE and CLK_SET_PARENT_GATE for those clocks in a proper
> > way?
> > 
> > Like you wrote, I would imagine it needs to be done by the clock
> > provider driver. Maybe to do that, it would be easier to have a new
> > device tree property on the clock node, rather than listing phandle and
> > clock-specifier pai