Re: [Xen-devel] Install of Xen 4.8 on Fedora 25 makes the box unbootable.. which is due to /var/run/xen being created, instead of /run/xen

[Juergen Gross]

On 16/02/17 08:52, Olaf Hering wrote:
> Am Wed, 15 Feb 2017 15:51:12 -0500
> schrieb Konrad Rzeszutek Wilk :
>> mkdir /run/xen
>> mkdir /run/xenstored
> 
> This must be done by the startup scripts because the "run" directories,
> where ever they are, are volatile.
> 
> I think confiugre should check if "/run" exists and assume this is a
> systemd based system and adjust the Makefile variables to be
> either /var/run or /run.

You can't assume ./configure is running on the same system as Xen is
being built for.

Just sent a patch adding "--with-rundir" parameter to configure.


Juergen

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

Re: [Xen-devel] Install of Xen 4.8 on Fedora 25 makes the box unbootable.. which is due to /var/run/xen being created, instead of /run/xen

[Olaf Hering]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am Wed, 15 Feb 2017 15:51:12 -0500
schrieb Konrad Rzeszutek Wilk :
> mkdir /run/xen
> mkdir /run/xenstored

This must be done by the startup scripts because the "run" directories,
where ever they are, are volatile.

I think confiugre should check if "/run" exists and assume this is a
systemd based system and adjust the Makefile variables to be
either /var/run or /run.

Of course keeping a symlink /var/run is too much of a burden...

Olaf
-BEGIN PGP SIGNATURE-

iF0EARECAB0WIQSkRyP6Rn//f03pRUBdQqD6ppg2fgUCWKVaLwAKCRBdQqD6ppg2
fsWaAKCj7uB6BBXevzJZJl3/6GXDi8muCQCfbB81TtS/jn13igbjl8ojNWcbjV4=
=SevM
-END PGP SIGNATURE-
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH] build: add --with-rundir option to configure

[Juergen Gross]

There have been reports that Fedora 25 uses /run instead of /var/run.

Add a --with-rundir option ito configure to be able to specify that
directory. Default is still /var/run.

A re-run of autogen.sh is required.

Signed-off-by: Juergen Gross 
---
Backport candidate (at least 4.8)
---
 configure   | 16 ++--
 docs/configure  | 16 ++--
 m4/paths.m4 | 10 --
 tools/configure | 16 ++--
 4 files changed, 50 insertions(+), 8 deletions(-)

diff --git a/configure b/configure
index d293af8..46fa04b 100755
--- a/configure
+++ b/configure
@@ -667,6 +667,7 @@ with_initddir
 with_sysconfig_leaf_dir
 with_libexec_leaf_dir
 with_xen_dumpdir
+with_rundir
 enable_githttp
 enable_xen
 enable_tools
@@ -1313,6 +1314,8 @@ Optional Packages:
   Name of subdirectory in libexecdir to use.
   --with-xen-dumpdir=DIR  Path to directory for domU crash dumps.
   [LOCALSTATEDIR/lib/xen/dump]
+  --with-rundir=DIR   Path to directory for runtime data.
+  [LOCALSTATEDIR/run]
 
 Report bugs to .
 Xen Hypervisor home page: .
@@ -1953,6 +1956,15 @@ else
 fi
 
 
+
+# Check whether --with-rundir was given.
+if test "${with_rundir+set}" = set; then :
+  withval=$with_rundir; rundir_path=$withval
+else
+  rundir_path=$localstatedir/run
+fi
+
+
 if test "$libexecdir" = '${exec_prefix}/libexec' ; then
 case "$host_os" in
  *netbsd*) ;;
@@ -1973,7 +1985,7 @@ LIBEXEC_INC=${LIBEXEC}/include
 XENFIRMWAREDIR=${LIBEXEC}/boot
 
 
-XEN_RUN_DIR=$localstatedir/run/xen
+XEN_RUN_DIR=$rundir_path/xen
 
 
 XEN_LOG_DIR=$localstatedir/log/xen
@@ -1982,7 +1994,7 @@ XEN_LOG_DIR=$localstatedir/log/xen
 XEN_LIB_STORED=$localstatedir/lib/xenstored
 
 
-XEN_RUN_STORED=$localstatedir/run/xenstored
+XEN_RUN_STORED=$rundir_path/xenstored
 
 
 XEN_LIB_DIR=$localstatedir/lib/xen
diff --git a/docs/configure b/docs/configure
index a497d1f..d05b9a8 100755
--- a/docs/configure
+++ b/docs/configure
@@ -658,6 +658,7 @@ with_initddir
 with_sysconfig_leaf_dir
 with_libexec_leaf_dir
 with_xen_dumpdir
+with_rundir
 '
   ac_precious_vars='build_alias
 host_alias
@@ -1288,6 +1289,8 @@ Optional Packages:
   Name of subdirectory in libexecdir to use.
   --with-xen-dumpdir=DIR  Path to directory for domU crash dumps.
   [LOCALSTATEDIR/lib/xen/dump]
+  --with-rundir=DIR   Path to directory for runtime data.
+  [LOCALSTATEDIR/run]
 
 Some influential environment variables:
   FIG2DEV Path to fig2dev tool
@@ -1859,6 +1862,15 @@ else
 fi
 
 
+
+# Check whether --with-rundir was given.
+if test "${with_rundir+set}" = set; then :
+  withval=$with_rundir; rundir_path=$withval
+else
+  rundir_path=$localstatedir/run
+fi
+
+
 if test "$libexecdir" = '${exec_prefix}/libexec' ; then
 case "$host_os" in
  *netbsd*) ;;
@@ -1879,7 +1891,7 @@ LIBEXEC_INC=${LIBEXEC}/include
 XENFIRMWAREDIR=${LIBEXEC}/boot
 
 
-XEN_RUN_DIR=$localstatedir/run/xen
+XEN_RUN_DIR=$rundir_path/xen
 
 
 XEN_LOG_DIR=$localstatedir/log/xen
@@ -1888,7 +1900,7 @@ XEN_LOG_DIR=$localstatedir/log/xen
 XEN_LIB_STORED=$localstatedir/lib/xenstored
 
 
-XEN_RUN_STORED=$localstatedir/run/xenstored
+XEN_RUN_STORED=$rundir_path/xenstored
 
 
 XEN_LIB_DIR=$localstatedir/lib/xen
diff --git a/m4/paths.m4 b/m4/paths.m4
index 722a8aa..93ce89a 100644
--- a/m4/paths.m4
+++ b/m4/paths.m4
@@ -76,6 +76,12 @@ AC_ARG_WITH([xen-dumpdir],
 [xen_dumpdir_path=$withval],
 [xen_dumpdir_path=$localstatedir/lib/xen/dump])
 
+AC_ARG_WITH([rundir],
+AS_HELP_STRING([--with-rundir=DIR],
+[Path to directory for runtime data. [LOCALSTATEDIR/run]]),
+[rundir_path=$withval],
+[rundir_path=$localstatedir/run])
+
 if test "$libexecdir" = '${exec_prefix}/libexec' ; then
 case "$host_os" in
  *netbsd*) ;;
@@ -98,7 +104,7 @@ AC_SUBST(LIBEXEC_INC)
 XENFIRMWAREDIR=${LIBEXEC}/boot
 AC_SUBST(XENFIRMWAREDIR)
 
-XEN_RUN_DIR=$localstatedir/run/xen
+XEN_RUN_DIR=$rundir_path/xen
 AC_SUBST(XEN_RUN_DIR)
 
 XEN_LOG_DIR=$localstatedir/log/xen
@@ -107,7 +113,7 @@ AC_SUBST(XEN_LOG_DIR)
 XEN_LIB_STORED=$localstatedir/lib/xenstored
 AC_SUBST(XEN_LIB_STORED)
 
-XEN_RUN_STORED=$localstatedir/run/xenstored
+XEN_RUN_STORED=$rundir_path/xenstored
 AC_SUBST(XEN_RUN_STORED)
 
 XEN_LIB_DIR=$localstatedir/lib/xen
diff --git a/tools/configure b/tools/configure
index ae96f6b..851e0f0 100755
--- a/tools/configure
+++ b/tools/configure
@@ -794,6 +794,7 @@ with_initddir
 with_sysconfig_leaf_dir
 with_libexec_leaf_dir
 with_xen_dumpdir
+with_rundir
 enable_rpath
 enable_githttp
 enable_monitors
@@ -1498,6 +1499,8 @@ Optional Packages:
   Name of subdirectory in libexecdir to use.
   --with-xen-dumpdir=DIR  Path to directory for domU crash dumps.
   [LOCALSTATEDIR/lib/xen/dump]
+  --with-rundir=DIR   Path to directory for runtime data.
+  [LOCAL

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

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 105804
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 105804
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 105804
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 105804
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 105804
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 105804
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 105804
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 105804

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 build-arm64-xsm   5 xen-buildfail   never pass
 build-arm64   5 xen-buildfail   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
 build-arm64-pvops 5 kernel-build fail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-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-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass

version targeted for testing:
 xen  93e1435290867703c50acad1f54b9208df473562
baseline version:
 xen  bdbc25b8722cc1e3921858530f8ac484892156d3

Last test of basis   105804  2017-02-15 02:01:23 Z1 days
Testing same since   105821  2017-02-15 15:11:39 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 
  Julien Grall 
  Oleksandr Tyshchenko 

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

Re: [Xen-devel] Install of Xen 4.8 on Fedora 25 makes the box unbootable.. which is due to /var/run/xen being created, instead of /run/xen

[Juergen Gross]

On 15/02/17 22:10, Boris Ostrovsky wrote:
> On 02/15/2017 03:51 PM, Konrad Rzeszutek Wilk wrote:
>> Hey,
>>
>> Credit goes to Boris (CC-ed) for figuring out how to fix this.
>>
>> I was doing:
>>
>> ./configure --prefix=/usr --enable-systemd
>> make -j8
>> cd dist;./install.sh;)
>> reboot
>>
>> and to my surprise it would hang on 
>> Starting Terminate Plymouth Boot Screen"...  
>>   
>>  
>>
>> with a bunch of 'FAILED'.
>>   
>>
>>
>> What I hadn't realized is that Fedora has removed the
>> /var/run and is now using /run. But the dist/install
>> has the /var/run directory (dist/install/var/run/) in it -
>> and that seems to make everything blow up as it erase
>> the original symlink:
>>
>> [konrad@x230 /]$ ls -al /var/run
>> lrwxrwxrwx. 1 root root 6 Oct  5 02:08 /var/run -> ../run
>>
>> with its own directory which has nothing to do with /run - and
>> which only has 'xen' and 'xenstored' in it (albeit at bootup things
>> do seem to be created there - but they are not in sync with things in 
>> /run).
>>
>>
>> The "Fix" is to boot with 'init=/bin/bash' on Linux command line and do:
>>
>> mount / -o remount,rw
>> rm -rf /var/run
>> mkdir /run/xen
>> mkdir /run/xenstored
>> ln -sf /run /var/run
>>
>> And then everything works again.
>>
>> A bit of light builds shows that RELEASE-4.7.0
>> does not have an dist/install/var/run but
>> RELEASE-4.8.0 and higher does.
>>
>> And I am not exactly sure which commit does this and
>> how to go around to auto-detect this? 
> 
> I *think* this started happening after
>   https://lists.xenproject.org/archives/html/xen-devel/2016-08/msg00372.html

I thought using:

./configure --prefix=/usr --enable-systemd XEN_RUN_DIR=/run/xen
XEN_RUN_STORED=/run/xenstored

would solve this issue, but obviously those settings don't make it into
config/Paths.mk

I suggest adding something like "--rundir=..." to the possible configure
parameters defaulting to /var/run and set XEN_RUN_DIR to $(rundir)/xen
and XEN_RUN_STORED to $(rundir)/xenstored.


Juergen

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

[Xen-devel] (resend) qemu crashes during VCPU hotplug

[Boris Ostrovsky]

(Now with correct address for Stefano)

Upstream qemu appears to be crashing during VCPU hotplug. I think this 
is something relatively new since I have been doing this a few week ago.


I reproduced this on two different setups. Haven't had a chance to look 
any further but e3cadac073 looks suspicious.


The crash happens in fw_cfg_modify_bytes_read() when we pass in NULL 
pointer as first argument. The stack is below:



(gdb) where
#0  0x561d762d64d4 in fw_cfg_modify_bytes_read (s=0x0, key=5, 
data=0x561d787031d0, len=2) at hw/nvram/fw_cfg.c:614
#1  0x561d762d6730 in fw_cfg_modify_i16 (s=0x0, key=5, value=2) at 
hw/nvram/fw_cfg.c:656
#2  0x561d761195b3 in pc_cpu_plug (hotplug_dev=0x561d770f9810, 
dev=0x561d7712a7e0, errp=0x7ffe8f75f2b0) at 
/root/xen/tools/qemu-xen-dir/hw/i386/pc.c:1823
#3  0x561d76119fc0 in pc_machine_device_plug_cb 
(hotplug_dev=0x561d770f9810, dev=0x561d7712a7e0, errp=0x7ffe8f75f2b0) at 
/root/xen/tools/qemu-xen-dir/hw/i386/pc.c:1993
#4  0x561d76239cba in hotplug_handler_plug 
(plug_handler=0x561d770f9810, plugged_dev=0x561d7712a7e0, 
errp=0x7ffe8f75f2b0) at hw/core/hotplug.c:34
#5  0x561d7623584d in device_set_realized (obj=0x561d7712a7e0, 
value=true, errp=0x7ffe8f75f468) at hw/core/qdev.c:928
#6  0x561d763e22a3 in property_set_bool (obj=0x561d7712a7e0, 
v=0x561d78702090, name=0x561d764fd9d0 "realized", opaque=0x561d785aea00, 
errp=0x7ffe8f75f468) at qom/object.c:1854
#7  0x561d763e07aa in object_property_set (obj=0x561d7712a7e0, 
v=0x561d78702090, name=0x561d764fd9d0 "realized", errp=0x7ffe8f75f468) 
at qom/object.c:1088
#8  0x561d763e3609 in object_property_set_qobject 
(obj=0x561d7712a7e0, value=0x561d773869c0, name=0x561d764fd9d0 
"realized", errp=0x7ffe8f75f468) at qom/qom-qobject.c:27
#9  0x561d763e0a40 in object_property_set_bool (obj=0x561d7712a7e0, 
value=true, name=0x561d764fd9d0 "realized", errp=0x7ffe8f75f468) at 
qom/object.c:1157
#10 0x561d76117304 in pc_new_cpu (typename=0x561d7707c880 
"qemu32-i386-cpu", apic_id=1, errp=0x7ffe8f75f4c0) at 
/root/xen/tools/qemu-xen-dir/hw/i386/pc.c:1099
#11 0x561d761174cc in pc_hot_add_cpu (id=1, errp=0x7ffe8f75f558) at 
/root/xen/tools/qemu-xen-dir/hw/i386/pc.c:1131
#12 0x561d761cb7b3 in qmp_cpu_add (id=1, errp=0x7ffe8f75f558) at 
qmp.c:126
#13 0x561d761bdc60 in qmp_marshal_cpu_add (args=0x561d7711a1b0, 
ret=0x7ffe8f75f5b0, errp=0x7ffe8f75f5a8) at qmp-marshal.c:1274
#14 0x561d764b2f13 in do_qmp_dispatch (request=0x561d77129360, 
errp=0x7ffe8f75f610) at qapi/qmp-dispatch.c:98
#15 0x561d764b3042 in qmp_dispatch (request=0x561d77129360) at 
qapi/qmp-dispatch.c:125
#16 0x561d76084d39 in handle_qmp_command (parser=0x561d771288b0, 
tokens=0x561d770f8cc0) at /root/xen/tools/qemu-xen-dir/monitor.c:3758
#17 0x561d764ba402 in json_message_process_token 
(lexer=0x561d771288b8, input=0x561d770f9040, type=JSON_RCURLY, x=1, 
y=11) at qobject/json-streamer.c:105
#18 0x561d764dd5dc in json_lexer_feed_char (lexer=0x561d771288b8, 
ch=125 '}', flush=false) at qobject/json-lexer.c:319
#19 0x561d764dd71c in json_lexer_feed (lexer=0x561d771288b8, 
buffer=0x7ffe8f75f880 "}\224Dx\035V", size=1) at qobject/json-lexer.c:369
#20 0x561d764ba4a2 in json_message_parser_feed 
(parser=0x561d771288b0, buffer=0x7ffe8f75f880 "}\224Dx\035V", size=1) at 
qobject/json-streamer.c:124
#21 0x561d76084e53 in monitor_qmp_read (opaque=0x561d77128830, 
buf=0x7ffe8f75f880 "}\224Dx\035V", size=1) at 
/root/xen/tools/qemu-xen-dir/monitor.c:3788
#22 0x561d761a3b2d in qemu_chr_be_write_impl (s=0x561d77107020, 
buf=0x7ffe8f75f880 "}\224Dx\035V", len=1) at qemu-char.c:419
#23 0x561d761a3b8f in qemu_chr_be_write (s=0x561d77107020, 
buf=0x7ffe8f75f880 "}\224Dx\035V", len=1) at qemu-char.c:431
#24 0x561d761a83d0 in tcp_chr_read (chan=0x561d785ae8a0, 
cond=G_IO_IN, opaque=0x561d77107020) at qemu-char.c:3145
#25 0x561d76475a36 in qio_channel_fd_source_dispatch 
(source=0x561d77cbe7c0, callback=0x561d761a8279 , 
user_data=0x561d77107020) at io/channel-watch.c:84
#26 0x7f77f3e407aa in g_main_context_dispatch () from 
/lib64/libglib-2.0.so.0

#27 0x561d763f03ee in glib_pollfds_poll () at main-loop.c:259
#28 0x561d763f04dc in os_host_main_loop_wait (timeout=15045517) at 
main-loop.c:306

#29 0x561d763f058c in main_loop_wait (nonblocking=0) at main-loop.c:556
#30 0x561d761b1cb5 in main_loop () at vl.c:1966
#31 0x561d761b93fb in main (argc=38, argv=0x7ffe8f760df8, 
envp=0x7ffe8f760f30) at vl.c:4684


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

[Xen-devel] qemu crashes during VCPU hotplug

[Boris Ostrovsky]

Upstream qemu appears to be crashing during VCPU hotplug. I think this 
is something relatively new since I have been doing this a few week ago.


I reproduced on two different setups. Haven't had a chance to look any 
further but e3cadac073 looks suspicious.


The crash happens in fw_cfg_modify_bytes_read() when we pass in NULL 
pointer as first argument. The stack is below:


(gdb) where
#0  0x561d762d64d4 in fw_cfg_modify_bytes_read (s=0x0, key=5, 
data=0x561d787031d0, len=2) at hw/nvram/fw_cfg.c:614
#1  0x561d762d6730 in fw_cfg_modify_i16 (s=0x0, key=5, value=2) at 
hw/nvram/fw_cfg.c:656
#2  0x561d761195b3 in pc_cpu_plug (hotplug_dev=0x561d770f9810, 
dev=0x561d7712a7e0, errp=0x7ffe8f75f2b0) at 
/root/xen/tools/qemu-xen-dir/hw/i386/pc.c:1823
#3  0x561d76119fc0 in pc_machine_device_plug_cb 
(hotplug_dev=0x561d770f9810, dev=0x561d7712a7e0, errp=0x7ffe8f75f2b0) at 
/root/xen/tools/qemu-xen-dir/hw/i386/pc.c:1993
#4  0x561d76239cba in hotplug_handler_plug 
(plug_handler=0x561d770f9810, plugged_dev=0x561d7712a7e0, 
errp=0x7ffe8f75f2b0) at hw/core/hotplug.c:34
#5  0x561d7623584d in device_set_realized (obj=0x561d7712a7e0, 
value=true, errp=0x7ffe8f75f468) at hw/core/qdev.c:928
#6  0x561d763e22a3 in property_set_bool (obj=0x561d7712a7e0, 
v=0x561d78702090, name=0x561d764fd9d0 "realized", opaque=0x561d785aea00, 
errp=0x7ffe8f75f468) at qom/object.c:1854
#7  0x561d763e07aa in object_property_set (obj=0x561d7712a7e0, 
v=0x561d78702090, name=0x561d764fd9d0 "realized", errp=0x7ffe8f75f468) 
at qom/object.c:1088
#8  0x561d763e3609 in object_property_set_qobject 
(obj=0x561d7712a7e0, value=0x561d773869c0, name=0x561d764fd9d0 
"realized", errp=0x7ffe8f75f468) at qom/qom-qobject.c:27
#9  0x561d763e0a40 in object_property_set_bool (obj=0x561d7712a7e0, 
value=true, name=0x561d764fd9d0 "realized", errp=0x7ffe8f75f468) at 
qom/object.c:1157
#10 0x561d76117304 in pc_new_cpu (typename=0x561d7707c880 
"qemu32-i386-cpu", apic_id=1, errp=0x7ffe8f75f4c0) at 
/root/xen/tools/qemu-xen-dir/hw/i386/pc.c:1099
#11 0x561d761174cc in pc_hot_add_cpu (id=1, errp=0x7ffe8f75f558) at 
/root/xen/tools/qemu-xen-dir/hw/i386/pc.c:1131
#12 0x561d761cb7b3 in qmp_cpu_add (id=1, errp=0x7ffe8f75f558) at 
qmp.c:126
#13 0x561d761bdc60 in qmp_marshal_cpu_add (args=0x561d7711a1b0, 
ret=0x7ffe8f75f5b0, errp=0x7ffe8f75f5a8) at qmp-marshal.c:1274
#14 0x561d764b2f13 in do_qmp_dispatch (request=0x561d77129360, 
errp=0x7ffe8f75f610) at qapi/qmp-dispatch.c:98
#15 0x561d764b3042 in qmp_dispatch (request=0x561d77129360) at 
qapi/qmp-dispatch.c:125
#16 0x561d76084d39 in handle_qmp_command (parser=0x561d771288b0, 
tokens=0x561d770f8cc0) at /root/xen/tools/qemu-xen-dir/monitor.c:3758
#17 0x561d764ba402 in json_message_process_token 
(lexer=0x561d771288b8, input=0x561d770f9040, type=JSON_RCURLY, x=1, 
y=11) at qobject/json-streamer.c:105
#18 0x561d764dd5dc in json_lexer_feed_char (lexer=0x561d771288b8, 
ch=125 '}', flush=false) at qobject/json-lexer.c:319
#19 0x561d764dd71c in json_lexer_feed (lexer=0x561d771288b8, 
buffer=0x7ffe8f75f880 "}\224Dx\035V", size=1) at qobject/json-lexer.c:369
#20 0x561d764ba4a2 in json_message_parser_feed 
(parser=0x561d771288b0, buffer=0x7ffe8f75f880 "}\224Dx\035V", size=1) at 
qobject/json-streamer.c:124
#21 0x561d76084e53 in monitor_qmp_read (opaque=0x561d77128830, 
buf=0x7ffe8f75f880 "}\224Dx\035V", size=1) at 
/root/xen/tools/qemu-xen-dir/monitor.c:3788
#22 0x561d761a3b2d in qemu_chr_be_write_impl (s=0x561d77107020, 
buf=0x7ffe8f75f880 "}\224Dx\035V", len=1) at qemu-char.c:419
#23 0x561d761a3b8f in qemu_chr_be_write (s=0x561d77107020, 
buf=0x7ffe8f75f880 "}\224Dx\035V", len=1) at qemu-char.c:431
#24 0x561d761a83d0 in tcp_chr_read (chan=0x561d785ae8a0, 
cond=G_IO_IN, opaque=0x561d77107020) at qemu-char.c:3145
#25 0x561d76475a36 in qio_channel_fd_source_dispatch 
(source=0x561d77cbe7c0, callback=0x561d761a8279 , 
user_data=0x561d77107020) at io/channel-watch.c:84
#26 0x7f77f3e407aa in g_main_context_dispatch () from 
/lib64/libglib-2.0.so.0

#27 0x561d763f03ee in glib_pollfds_poll () at main-loop.c:259
#28 0x561d763f04dc in os_host_main_loop_wait (timeout=15045517) at 
main-loop.c:306

#29 0x561d763f058c in main_loop_wait (nonblocking=0) at main-loop.c:556
#30 0x561d761b1cb5 in main_loop () at vl.c:1966
#31 0x561d761b93fb in main (argc=38, argv=0x7ffe8f760df8, 
envp=0x7ffe8f760f30) at vl.c:4684



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

[Xen-devel] [xen-unstable-smoke test] 105836: tolerable trouble: broken/fail/pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   5 xen-buildfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  1e88db4701d6e2d00c04795e6aacaea942b617e6
baseline version:
 xen  d65aa60073b452cfea909a9e023f1dac2cf3521c

Last test of basis   105830  2017-02-15 21:01:07 Z0 days
Testing same since   105836  2017-02-16 02:03:26 Z0 days1 attempts


People who touched revisions under test:
  Julien Grall 

jobs:
 build-amd64  pass
 build-arm64  fail
 build-armhf  pass
 build-amd64-libvirt  pass
 build-arm64-pvopsfail
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  broken  
 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=1e88db4701d6e2d00c04795e6aacaea942b617e6
+ . ./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 
1e88db4701d6e2d00c04795e6aacaea942b617e6
+ branch=xen-unstable-smoke
+ revision=1e88db4701d6e2d00c04795e6aacaea942b617e6
+ . ./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.8-testing
+ '[' x1e88db4701d6e2d00c04795e6aacaea942b617e6 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xtf  01b0192030c01dc8af02dca6b92d720cf3908b80
baseline version:
 xtf  c92015f8ab00026f85d187d0090fc02e8ab4cfaf

Last test of basis   105216  2017-02-01 16:45:36 Z   14 days
Testing same since   105823  2017-02-15 16:48:40 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 

jobs:
 build-amd64-xtf  pass
 build-amd64  pass
 build-amd64-pvopspass
 test-xtf-amd64-amd64-1   pass
 test-xtf-amd64-amd64-2   pass
 test-xtf-amd64-amd64-3   pass
 test-xtf-amd64-amd64-4   pass
 test-xtf-amd64-amd64-5   pass



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

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

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

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


Pushing revision :

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

[Xen-devel] [xen-4.8-testing test] 105818: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

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

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

version targeted for testing:
 xen  c24629612fea2d44c8f03f0a2583e44dbbfc5e05
baseline version:
 xen  10baa197d218c222f298ac5ba0d4ef5afd1401ff

Last test of basis   105662  2017-02-09 09:43:18 Z6 days
Testing same since   105818  2017-02-15 12:44:42 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 
  Julien Grall 
  Oleksandr Tyshchenko 

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

Re: [Xen-devel] [PATCH 8/8] xen/arm: acpi: Move the ACPI banks in bootinfo

[Stefano Stabellini]

On Fri, 3 Feb 2017, Julien Grall wrote:
> Currently the acpi banks are stored in a separate variable and have an
> header just for them.
> 
> This variable can be moved in the structure bootinfo removing an header
> and a global variable.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


> ---
>  xen/arch/arm/efi/efi-boot.h |  3 +--
>  xen/arch/arm/efi/efi-dom0.c | 12 +---
>  xen/arch/arm/efi/efi-dom0.h |  8 
>  xen/include/asm-arm/setup.h |  3 +++
>  4 files changed, 9 insertions(+), 17 deletions(-)
>  delete mode 100644 xen/arch/arm/efi/efi-dom0.h
> 
> diff --git a/xen/arch/arm/efi/efi-boot.h b/xen/arch/arm/efi/efi-boot.h
> index 757d9c6..2e3e169 100644
> --- a/xen/arch/arm/efi/efi-boot.h
> +++ b/xen/arch/arm/efi/efi-boot.h
> @@ -7,7 +7,6 @@
>  #include 
>  #include 
>  #include 
> -#include "efi-dom0.h"
>  
>  void noreturn efi_xen_start(void *fdt_ptr, uint32_t fdt_size);
>  void __flush_dcache_area(const void *vaddr, unsigned long size);
> @@ -164,7 +163,7 @@ static EFI_STATUS __init 
> efi_process_memory_map_bootinfo(EFI_MEMORY_DESCRIPTOR *
>  #ifdef CONFIG_ACPI
>  else if ( desc_ptr->Type == EfiACPIReclaimMemory )
>  {
> -if ( !meminfo_add_bank(&acpi_mem, desc_ptr) )
> +if ( !meminfo_add_bank(&bootinfo.acpi, desc_ptr) )
>  {
>  PrintStr(L"Error: All " __stringify(NR_MEM_BANKS)
>" acpi meminfo mem banks exhausted.\r\n");
> diff --git a/xen/arch/arm/efi/efi-dom0.c b/xen/arch/arm/efi/efi-dom0.c
> index f0ceaa6..1c35654 100644
> --- a/xen/arch/arm/efi/efi-dom0.c
> +++ b/xen/arch/arm/efi/efi-dom0.c
> @@ -22,7 +22,6 @@
>   */
>  
>  #include "efi.h"
> -#include "efi-dom0.h"
>  #include 
>  #include 
>  #include 
> @@ -32,7 +31,6 @@
>  #define XZ_EXTERN STATIC
>  #include "../../../common/xz/crc32.c"
>  
> -struct meminfo __initdata acpi_mem;
>  /* Constant to indicate "Xen" in unicode u16 format */
>  static const CHAR16 xen_efi_fw_vendor[] = {0x0058, 0x0065, 0x006E, 0x};
>  
> @@ -46,7 +44,7 @@ size_t __init estimate_efi_size(int mem_nr_banks)
>  int acpi_mem_nr_banks = 0;
>  
>  if ( !acpi_disabled )
> -acpi_mem_nr_banks = acpi_mem.nr_banks;
> +acpi_mem_nr_banks = bootinfo.acpi.nr_banks;
>  
>  size = ROUNDUP(est_size + ect_size + fw_vendor_size, 8);
>  /* plus 1 for new created tables */
> @@ -124,10 +122,10 @@ void __init acpi_create_efi_mmap_table(struct domain *d,
>  fill_efi_memory_descriptor(desc, EfiConventionalMemory,
> mem->bank[i].start, mem->bank[i].size);
>  
> -for ( i = 0; i < acpi_mem.nr_banks; i++, desc++ )
> +for ( i = 0; i < bootinfo.acpi.nr_banks; i++, desc++ )
>  fill_efi_memory_descriptor(desc, EfiACPIReclaimMemory,
> -   acpi_mem.bank[i].start,
> -   acpi_mem.bank[i].size);
> +   bootinfo.acpi.bank[i].start,
> +   bootinfo.acpi.bank[i].size);
>  
>  fill_efi_memory_descriptor(desc, EfiACPIReclaimMemory,
> d->arch.efi_acpi_gpa, d->arch.efi_acpi_len);
> @@ -135,7 +133,7 @@ void __init acpi_create_efi_mmap_table(struct domain *d,
>  tbl_add[TBL_MMAP].start = d->arch.efi_acpi_gpa
>+ acpi_get_table_offset(tbl_add, TBL_MMAP);
>  tbl_add[TBL_MMAP].size = sizeof(EFI_MEMORY_DESCRIPTOR)
> - * (mem->nr_banks + acpi_mem.nr_banks + 1);
> + * (mem->nr_banks + bootinfo.acpi.nr_banks + 1);
>  }
>  
>  /* Create /hypervisor/uefi node for efi properties. */
> diff --git a/xen/arch/arm/efi/efi-dom0.h b/xen/arch/arm/efi/efi-dom0.h
> deleted file mode 100644
> index 3cd4caa..000
> --- a/xen/arch/arm/efi/efi-dom0.h
> +++ /dev/null
> @@ -1,8 +0,0 @@
> -#ifndef __ARM_EFI_DOM0_H__
> -#define __ARM_EFI_DOM0_H__
> -
> -#include 
> -
> -extern struct meminfo acpi_mem;
> -
> -#endif
> diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
> index 3da7a49..7c76185 100644
> --- a/xen/include/asm-arm/setup.h
> +++ b/xen/include/asm-arm/setup.h
> @@ -43,6 +43,9 @@ struct bootmodules {
>  struct bootinfo {
>  struct meminfo mem;
>  struct bootmodules modules;
> +#ifdef CONFIG_ACPI
> +struct meminfo acpi;
> +#endif
>  };
>  
>  extern struct bootinfo bootinfo;
> -- 
> 1.9.1
> 

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

Re: [Xen-devel] [PATCH 0/8] xen/arm: Fix and clean-up for ACPI and EFI

[Stefano Stabellini]

On Fri, 3 Feb 2017, Julien Grall wrote:
> Hi all,
> 
> This patch series contains a bunch of fix and clean-up for ACPI and EFI on
> ARM64.
> 
> Note that the patch "xen/arm64: Don't zero BSS when booting using EFI" [1] is
> required in order to test this series.

Thanks Julien! I committed patch #1, #2 and #4.


> Cheers,
> 
> [1] https://lists.xenproject.org/archives/html/xen-devel/2017-02/msg00228.html
> 
> Julien Grall (8):
>   xen/arm: acpi: Handle correctly detection of GICv2 on GICv3
>   xen/arm: acpi: Rework acpi_boot_table_init error paths
>   xen/arm: acpi: Don't fallback on DT when user request ACPI
>   xen/arm: Print whether Xen is booting using ACPI or DT
>   xen/arm: efi: Avoid duplicating the addition of a new bank
>   xen/arm: efi: Avoid duplicating the addition of a new efi memory
> descriptor
>   xen/arm: efi: Rework acpi_create_efi_mmap_table to avoid
> memory_map[offset]
>   xen/arm: acpi: Move the ACPI banks in bootinfo
> 
>  xen/arch/arm/acpi/boot.c| 30 ++
>  xen/arch/arm/efi/efi-boot.h | 35 +-
>  xen/arch/arm/efi/efi-dom0.c | 61 
> +
>  xen/arch/arm/efi/efi-dom0.h |  8 --
>  xen/arch/arm/gic-v3.c   | 20 ++-
>  xen/arch/arm/setup.c|  5 
>  xen/include/asm-arm/setup.h |  3 +++
>  7 files changed, 93 insertions(+), 69 deletions(-)
>  delete mode 100644 xen/arch/arm/efi/efi-dom0.h
> 
> -- 
> 1.9.1
> 

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

Re: [Xen-devel] [PATCH 7/8] xen/arm: efi: Rework acpi_create_efi_mmap_table to avoid memory_map[offset]

[Stefano Stabellini]

On Fri, 3 Feb 2017, Julien Grall wrote:
> The code contains a lot of memory_map[offset]. This could be simplified
> by incrementing the descriptor pointer every time.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 

> ---
>  xen/arch/arm/efi/efi-dom0.c | 17 -
>  1 file changed, 8 insertions(+), 9 deletions(-)
> 
> diff --git a/xen/arch/arm/efi/efi-dom0.c b/xen/arch/arm/efi/efi-dom0.c
> index f307f26..f0ceaa6 100644
> --- a/xen/arch/arm/efi/efi-dom0.c
> +++ b/xen/arch/arm/efi/efi-dom0.c
> @@ -112,25 +112,24 @@ void __init acpi_create_efi_mmap_table(struct domain *d,
> const struct meminfo *mem,
> struct membank tbl_add[])
>  {
> -EFI_MEMORY_DESCRIPTOR *memory_map;
> -unsigned int i, offset;
> +EFI_MEMORY_DESCRIPTOR *desc;
> +unsigned int i;
>  u8 *base_ptr;
>  
>  base_ptr = d->arch.efi_acpi_table
> + acpi_get_table_offset(tbl_add, TBL_MMAP);
> -memory_map = (EFI_MEMORY_DESCRIPTOR *)base_ptr;
> +desc = (EFI_MEMORY_DESCRIPTOR *)base_ptr;
>  
> -offset = 0;
> -for( i = 0; i < mem->nr_banks; i++, offset++ )
> -fill_efi_memory_descriptor(&memory_map[offset], 
> EfiConventionalMemory,
> +for ( i = 0; i < mem->nr_banks; i++, desc++ )
> +fill_efi_memory_descriptor(desc, EfiConventionalMemory,
> mem->bank[i].start, mem->bank[i].size);
>  
> -for( i = 0; i < acpi_mem.nr_banks; i++, offset++ )
> -fill_efi_memory_descriptor(&memory_map[offset], EfiACPIReclaimMemory,
> +for ( i = 0; i < acpi_mem.nr_banks; i++, desc++ )
> +fill_efi_memory_descriptor(desc, EfiACPIReclaimMemory,
> acpi_mem.bank[i].start,
> acpi_mem.bank[i].size);
>  
> -fill_efi_memory_descriptor(&memory_map[offset], EfiACPIReclaimMemory,
> +fill_efi_memory_descriptor(desc, EfiACPIReclaimMemory,
> d->arch.efi_acpi_gpa, d->arch.efi_acpi_len);
>  
>  tbl_add[TBL_MMAP].start = d->arch.efi_acpi_gpa
> -- 
> 1.9.1
> 

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

Re: [Xen-devel] [PATCH 6/8] xen/arm: efi: Avoid duplicating the addition of a new efi memory descriptor

[Stefano Stabellini]

On Fri, 3 Feb 2017, Julien Grall wrote:
> The code to add a new memory descriptor is duplicated three times. Add a
> new helper that adds the descriptor.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 

> ---
>  xen/arch/arm/efi/efi-dom0.c | 40 
>  1 file changed, 20 insertions(+), 20 deletions(-)
> 
> diff --git a/xen/arch/arm/efi/efi-dom0.c b/xen/arch/arm/efi/efi-dom0.c
> index c40a7c5..f307f26 100644
> --- a/xen/arch/arm/efi/efi-dom0.c
> +++ b/xen/arch/arm/efi/efi-dom0.c
> @@ -96,6 +96,18 @@ void __init acpi_create_efi_system_table(struct domain *d,
>  tbl_add[TBL_EFIT].size = table_size;
>  }
>  
> +static void __init fill_efi_memory_descriptor(EFI_MEMORY_DESCRIPTOR *desc,
> +  UINT32 type,
> +  EFI_PHYSICAL_ADDRESS start,
> +  UINT64 size)
> +{
> +desc->Type = type;
> +desc->PhysicalStart = start;
> +BUG_ON(size & EFI_PAGE_MASK);
> +desc->NumberOfPages = EFI_SIZE_TO_PAGES(size);
> +desc->Attribute = EFI_MEMORY_WB;
> +}
> +
>  void __init acpi_create_efi_mmap_table(struct domain *d,
> const struct meminfo *mem,
> struct membank tbl_add[])
> @@ -110,28 +122,16 @@ void __init acpi_create_efi_mmap_table(struct domain *d,
>  
>  offset = 0;
>  for( i = 0; i < mem->nr_banks; i++, offset++ )
> -{
> -memory_map[offset].Type = EfiConventionalMemory;
> -memory_map[offset].PhysicalStart = mem->bank[i].start;
> -BUG_ON(mem->bank[i].size & EFI_PAGE_MASK);
> -memory_map[offset].NumberOfPages = 
> EFI_SIZE_TO_PAGES(mem->bank[i].size);
> -memory_map[offset].Attribute = EFI_MEMORY_WB;
> -}
> +fill_efi_memory_descriptor(&memory_map[offset], 
> EfiConventionalMemory,
> +   mem->bank[i].start, mem->bank[i].size);
>  
>  for( i = 0; i < acpi_mem.nr_banks; i++, offset++ )
> -{
> -memory_map[offset].Type = EfiACPIReclaimMemory;
> -memory_map[offset].PhysicalStart = acpi_mem.bank[i].start;
> -BUG_ON(acpi_mem.bank[i].size & EFI_PAGE_MASK);
> -memory_map[offset].NumberOfPages = 
> EFI_SIZE_TO_PAGES(acpi_mem.bank[i].size);
> -memory_map[offset].Attribute = EFI_MEMORY_WB;
> -}
> -
> -memory_map[offset].Type = EfiACPIReclaimMemory;
> -memory_map[offset].PhysicalStart = d->arch.efi_acpi_gpa;
> -BUG_ON(d->arch.efi_acpi_len & EFI_PAGE_MASK);
> -memory_map[offset].NumberOfPages = 
> EFI_SIZE_TO_PAGES(d->arch.efi_acpi_len);
> -memory_map[offset].Attribute = EFI_MEMORY_WB;
> +fill_efi_memory_descriptor(&memory_map[offset], EfiACPIReclaimMemory,
> +   acpi_mem.bank[i].start,
> +   acpi_mem.bank[i].size);
> +
> +fill_efi_memory_descriptor(&memory_map[offset], EfiACPIReclaimMemory,
> +   d->arch.efi_acpi_gpa, d->arch.efi_acpi_len);
>  
>  tbl_add[TBL_MMAP].start = d->arch.efi_acpi_gpa
>+ acpi_get_table_offset(tbl_add, TBL_MMAP);
> -- 
> 1.9.1
> 

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

Re: [Xen-devel] [PATCH 5/8] xen/arm: efi: Avoid duplicating the addition of a new bank

[Stefano Stabellini]

On Wed, 15 Feb 2017, Stefano Stabellini wrote:
> On Fri, 3 Feb 2017, Julien Grall wrote:
> > The code to add a new bank is duplicated twice. Add a new helper that
> > checks if the maximum of bank has not reached and adds the bank.
> > 
> > Signed-off-by: Julien Grall 
> 
> Reviewed-by: Stefano Stabellini 
> 
> 
> > ---
> >  xen/arch/arm/efi/efi-boot.h | 34 ++
> >  1 file changed, 18 insertions(+), 16 deletions(-)
> > 
> > diff --git a/xen/arch/arm/efi/efi-boot.h b/xen/arch/arm/efi/efi-boot.h
> > index 045d6ce..757d9c6 100644
> > --- a/xen/arch/arm/efi/efi-boot.h
> > +++ b/xen/arch/arm/efi/efi-boot.h
> > @@ -124,15 +124,27 @@ static void __init 
> > *lookup_fdt_config_table(EFI_SYSTEM_TABLE *sys_table)
> >  return fdt;
> >  }
> >  
> > +static bool meminfo_add_bank(struct meminfo *mem, EFI_MEMORY_DESCRIPTOR 
> > *desc)

actually this function should be __init, right?


> > +{
> > +struct membank *bank;
> > +
> > +if ( mem->nr_banks > NR_MEM_BANKS )
> > +return false;
> > +
> > +bank = &mem->bank[mem->nr_banks];
> > +bank->start = desc->PhysicalStart;
> > +bank->size = desc->NumberOfPages * EFI_PAGE_SIZE;
> > +
> > +mem->nr_banks++;
> > +
> > +return true;
> > +}
> > +
> >  static EFI_STATUS __init 
> > efi_process_memory_map_bootinfo(EFI_MEMORY_DESCRIPTOR *map,
> >  UINTN mmap_size,
> >  UINTN desc_size)
> >  {
> >  int Index;
> > -int i = 0;
> > -#ifdef CONFIG_ACPI
> > -int j = 0;
> > -#endif
> >  EFI_MEMORY_DESCRIPTOR *desc_ptr = map;
> >  
> >  for ( Index = 0; Index < (mmap_size / desc_size); Index++ )
> > @@ -142,37 +154,27 @@ static EFI_STATUS __init 
> > efi_process_memory_map_bootinfo(EFI_MEMORY_DESCRIPTOR *
> >(desc_ptr->Type == EfiBootServicesCode ||
> > desc_ptr->Type == EfiBootServicesData)) )
> >  {
> > -if ( i >= NR_MEM_BANKS )
> > +if ( !meminfo_add_bank(&bootinfo.mem, desc_ptr) )
> >  {
> >  PrintStr(L"Warning: All " __stringify(NR_MEM_BANKS)
> >" bootinfo mem banks exhausted.\r\n");
> >  break;
> >  }
> > -bootinfo.mem.bank[i].start = desc_ptr->PhysicalStart;
> > -bootinfo.mem.bank[i].size = desc_ptr->NumberOfPages * 
> > EFI_PAGE_SIZE;
> > -++i;
> >  }
> >  #ifdef CONFIG_ACPI
> >  else if ( desc_ptr->Type == EfiACPIReclaimMemory )
> >  {
> > -if ( j >= NR_MEM_BANKS )
> > +if ( !meminfo_add_bank(&acpi_mem, desc_ptr) )
> >  {
> >  PrintStr(L"Error: All " __stringify(NR_MEM_BANKS)
> >" acpi meminfo mem banks exhausted.\r\n");
> >  return EFI_LOAD_ERROR;
> >  }
> > -acpi_mem.bank[j].start = desc_ptr->PhysicalStart;
> > -acpi_mem.bank[j].size  = desc_ptr->NumberOfPages * 
> > EFI_PAGE_SIZE;
> > -++j;
> >  }
> >  #endif
> >  desc_ptr = NextMemoryDescriptor(desc_ptr, desc_size);
> >  }
> >  
> > -bootinfo.mem.nr_banks = i;
> > -#ifdef CONFIG_ACPI
> > -acpi_mem.nr_banks = j;
> > -#endif
> >  return EFI_SUCCESS;
> >  }
> >  
> > -- 
> > 1.9.1
> > 
> 

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

Re: [Xen-devel] [PATCH 5/8] xen/arm: efi: Avoid duplicating the addition of a new bank

[Stefano Stabellini]

On Fri, 3 Feb 2017, Julien Grall wrote:
> The code to add a new bank is duplicated twice. Add a new helper that
> checks if the maximum of bank has not reached and adds the bank.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


> ---
>  xen/arch/arm/efi/efi-boot.h | 34 ++
>  1 file changed, 18 insertions(+), 16 deletions(-)
> 
> diff --git a/xen/arch/arm/efi/efi-boot.h b/xen/arch/arm/efi/efi-boot.h
> index 045d6ce..757d9c6 100644
> --- a/xen/arch/arm/efi/efi-boot.h
> +++ b/xen/arch/arm/efi/efi-boot.h
> @@ -124,15 +124,27 @@ static void __init 
> *lookup_fdt_config_table(EFI_SYSTEM_TABLE *sys_table)
>  return fdt;
>  }
>  
> +static bool meminfo_add_bank(struct meminfo *mem, EFI_MEMORY_DESCRIPTOR 
> *desc)
> +{
> +struct membank *bank;
> +
> +if ( mem->nr_banks > NR_MEM_BANKS )
> +return false;
> +
> +bank = &mem->bank[mem->nr_banks];
> +bank->start = desc->PhysicalStart;
> +bank->size = desc->NumberOfPages * EFI_PAGE_SIZE;
> +
> +mem->nr_banks++;
> +
> +return true;
> +}
> +
>  static EFI_STATUS __init 
> efi_process_memory_map_bootinfo(EFI_MEMORY_DESCRIPTOR *map,
>  UINTN mmap_size,
>  UINTN desc_size)
>  {
>  int Index;
> -int i = 0;
> -#ifdef CONFIG_ACPI
> -int j = 0;
> -#endif
>  EFI_MEMORY_DESCRIPTOR *desc_ptr = map;
>  
>  for ( Index = 0; Index < (mmap_size / desc_size); Index++ )
> @@ -142,37 +154,27 @@ static EFI_STATUS __init 
> efi_process_memory_map_bootinfo(EFI_MEMORY_DESCRIPTOR *
>(desc_ptr->Type == EfiBootServicesCode ||
> desc_ptr->Type == EfiBootServicesData)) )
>  {
> -if ( i >= NR_MEM_BANKS )
> +if ( !meminfo_add_bank(&bootinfo.mem, desc_ptr) )
>  {
>  PrintStr(L"Warning: All " __stringify(NR_MEM_BANKS)
>" bootinfo mem banks exhausted.\r\n");
>  break;
>  }
> -bootinfo.mem.bank[i].start = desc_ptr->PhysicalStart;
> -bootinfo.mem.bank[i].size = desc_ptr->NumberOfPages * 
> EFI_PAGE_SIZE;
> -++i;
>  }
>  #ifdef CONFIG_ACPI
>  else if ( desc_ptr->Type == EfiACPIReclaimMemory )
>  {
> -if ( j >= NR_MEM_BANKS )
> +if ( !meminfo_add_bank(&acpi_mem, desc_ptr) )
>  {
>  PrintStr(L"Error: All " __stringify(NR_MEM_BANKS)
>" acpi meminfo mem banks exhausted.\r\n");
>  return EFI_LOAD_ERROR;
>  }
> -acpi_mem.bank[j].start = desc_ptr->PhysicalStart;
> -acpi_mem.bank[j].size  = desc_ptr->NumberOfPages * EFI_PAGE_SIZE;
> -++j;
>  }
>  #endif
>  desc_ptr = NextMemoryDescriptor(desc_ptr, desc_size);
>  }
>  
> -bootinfo.mem.nr_banks = i;
> -#ifdef CONFIG_ACPI
> -acpi_mem.nr_banks = j;
> -#endif
>  return EFI_SUCCESS;
>  }
>  
> -- 
> 1.9.1
> 

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

Re: [Xen-devel] [PATCH RFC V2 7/7] COLO-Proxy: Use socket to get checkpoint event.

[Zhang Chen]

On 02/16/2017 12:24 AM, Konrad Rzeszutek Wilk wrote:

On Wed, Feb 15, 2017 at 05:54:33PM +0800, Zhang Chen wrote:

We use kernel colo proxy's way to get the checkpoint event
from qemu colo-compare.
Qemu colo-compare need add a API to support this(I will add this in qemu).

Signed-off-by: Zhang Chen 
---
  tools/libxl/libxl_colo.h |  2 +
  tools/libxl/libxl_colo_proxy.c   | 84 +---
  tools/libxl/libxl_colo_restore.c | 11 --
  tools/libxl/libxl_colo_save.c| 22 +++
  tools/libxl/libxl_nic.c  |  4 ++
  tools/libxl/libxl_types.idl  |  4 +-
  tools/libxl/xl_cmdimpl.c |  4 ++
  7 files changed, 113 insertions(+), 18 deletions(-)

diff --git a/tools/libxl/libxl_colo.h b/tools/libxl/libxl_colo.h
index 4746d8c..6c01b55 100644
--- a/tools/libxl/libxl_colo.h
+++ b/tools/libxl/libxl_colo.h
@@ -69,6 +69,8 @@ struct libxl__colo_proxy_state {
   *  False means use kernel colo proxy.
   */
  bool is_userspace_proxy;
+const char *checkpoint_host;
+const char *checkpoint_port;
  };
  
  struct libxl__colo_save_state {

diff --git a/tools/libxl/libxl_colo_proxy.c b/tools/libxl/libxl_colo_proxy.c
index dd902fc..9d21cf1 100644
--- a/tools/libxl/libxl_colo_proxy.c
+++ b/tools/libxl/libxl_colo_proxy.c
@@ -18,6 +18,9 @@
  #include "libxl_internal.h"
  
  #include 

+#include 
+#include 
+#include 
  
  /* Consistent with the new COLO netlink channel in kernel side */

  #define NETLINK_COLO 28
@@ -76,6 +79,26 @@ static int colo_proxy_send(libxl__colo_proxy_state *cps, 
uint8_t *buff,
  return ret;
  }
  
+static int colo_userspace_proxy_recv(libxl__colo_proxy_state *cps,

+ char *buff,
+ unsigned int timeout_us)
+{
+struct timeval tv;
+int ret;
+
+STATE_AO_GC(cps->ao);
+
+if (timeout_us) {
+tv.tv_sec = timeout_us / 100;
+tv.tv_usec = timeout_us % 100;
+setsockopt(cps->sock_fd, SOL_SOCKET, SO_RCVTIMEO, &tv, sizeof(tv));
+}
+
+ret = recv(cps->sock_fd, buff, sizeof(buff),0);
+
+return ret;
+}
+
  /* error: return -1, otherwise return 0 */
  static int64_t colo_proxy_recv(libxl__colo_proxy_state *cps, uint8_t **buff,
 unsigned int timeout_us)
@@ -153,8 +176,45 @@ int colo_proxy_setup(libxl__colo_proxy_state *cps)
  STATE_AO_GC(cps->ao);
  
  /* If enable userspace proxy mode, we don't need setup kernel proxy */

-if (cps->is_userspace_proxy)
+if (cps->is_userspace_proxy) {
+struct sockaddr_in addr;
+int port;
+char recvbuff[1024];
+
+memset(&addr, 0, sizeof(addr));
+port = atoi(cps->checkpoint_port);
+addr.sin_family = AF_INET;
+addr.sin_port = htons(port);
+addr.sin_addr.s_addr = inet_addr(cps->checkpoint_host);
+
+skfd = socket(AF_INET, SOCK_STREAM, 0);
+if (skfd < 0) {
+LOGD(ERROR, ao->domid, "can not create a TCP socket: %s",
+ strerror(errno));
+goto out;
+}
+
+cps->sock_fd = skfd;
+
+if (connect(skfd, (struct sockaddr *)&addr, sizeof(addr)) < 0) {
+LOGD(ERROR, ao->domid, "connect error");
+goto out;
+}
+
+char sendbuf[] = "COLO_USERSPACE_PROXY_INIT";

Um, could you move it right around 'char recvbuff' ?


OK, I will move it in next version.


+ret = send(skfd, sendbuf, strlen(sendbuf),0);
+if (ret < 0)
+goto out;
+
+ret = colo_userspace_proxy_recv(cps, recvbuff, 50);

That 50 looks like a good candidate for a #define?


I will add a macro "#define COLO_DEFAULT_WAIT_TIME 50".

Thanks
Zhang Chen




+if (size < 0) {


s/size/ret


+LOGD(ERROR, ao->domid, "Can't recv msg from qemu colo-compare: %s",
+ strerror(errno));
+goto out;
+}
+
  return 0;
+}
  
  skfd = socket(PF_NETLINK, SOCK_RAW, NETLINK_COLO);

  if (skfd < 0) {
@@ -247,8 +307,11 @@ void colo_proxy_preresume(libxl__colo_proxy_state *cps)
   * If enable userspace proxy mode,
   * we don't need preresume kernel proxy
   */
-if (cps->is_userspace_proxy)
+if (cps->is_userspace_proxy) {
+char sendbuf[] = "COLO_CHECKPOINT";
+send(cps->sock_fd, sendbuf, strlen(sendbuf),0);
  return;
+}
  
  colo_proxy_send(cps, NULL, 0, COLO_CHECKPOINT);

  /* TODO: need to handle if the call fails... */
@@ -277,16 +340,25 @@ int colo_proxy_checkpoint(libxl__colo_proxy_state *cps,
  struct nlmsghdr *h;
  struct colo_msg *m;
  int ret = -1;
+char recvbuff[1024];
  
  STATE_AO_GC(cps->ao);
  
  /*

- * enable userspace proxy mode, tmp sleep.
- * then we will add qemu API support this func.
+ * enable userspace proxy mode.
+ * Then we will add qemu API support for this func.
   */
  if (cps->is_userspace

Re: [Xen-devel] [PATCH 4/8] xen/arm: Print whether Xen is booting using ACPI or DT

[Stefano Stabellini]

On Fri, 3 Feb 2017, Julien Grall wrote:
> Make it easier to figure out whether Xen is booting using ACPI or DT by
> printing a message on the console.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


> ---
>  xen/arch/arm/setup.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 049e449..41aa1dd 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -753,6 +753,11 @@ void __init start_xen(unsigned long boot_phys_offset,
>  /* Parse the ACPI tables for possible boot-time configuration */
>  acpi_boot_table_init();
>  
> +if ( acpi_disabled )
> +printk("Booting using Device Tree\n");
> +else
> +printk("Booting using ACPI\n");
> +
>  end_boot_allocator();
>  
>  vm_init();
> -- 
> 1.9.1
> 

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

Re: [Xen-devel] [PATCH 3/8] xen/arm: acpi: Don't fallback on DT when user request ACPI

[Stefano Stabellini]

On Fri, 3 Feb 2017, Julien Grall wrote:
> On ARM, when the user put 'acpi=force' Xen will use ACPI over DT.
> Currently, if Xen fails to initialize ACPI it will fallback on DT.
> 
> This behavior makes difficult for a user to notice Xen didn't used ACPI
> has requested on platform where the firmware is providing both ACPI and DT.
> 
> Rather than fallback on DT during a failure, panic when 'acpi=force'.
> 
> Signed-off-by: Julien Grall 
> 
> ---
> I am wondering if we should do the same with acpi=on. So a user
> would notice directly if something went wrong with ACPI.
> Otherwise you would boot up to the prompt and barely notice that DT
> was used.

I would keep the current behavior as is and add new parameter that means
"acpi and only acpi". Today acpi=force means "acpi is preferred to
device tree". It doesn't mean that if acpi fail, Xen should panic.

Maybe acpi=strict or acpi=mandatory?


> ---
>  xen/arch/arm/acpi/boot.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/xen/arch/arm/acpi/boot.c b/xen/arch/arm/acpi/boot.c
> index 889208a..65ef632 100644
> --- a/xen/arch/arm/acpi/boot.c
> +++ b/xen/arch/arm/acpi/boot.c
> @@ -272,6 +272,11 @@ int __init acpi_boot_table_init(void)
>  return 0;
>  
>  disable:
> +
> +/* Panic if the user has requested ACPI but Xen is able to initialize. */
> +if ( param_acpi_force )
> +panic("Unable to use ACPI");
> +
>  disable_acpi();
>  
>  return error;
> -- 
> 1.9.1
> 

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

Re: [Xen-devel] [PATCH 2/8] xen/arm: acpi: Rework acpi_boot_table_init error paths

[Stefano Stabellini]

On Fri, 3 Feb 2017, Julien Grall wrote:
> There are multiple path disable ACPI on error. Consolidate in a single
> place, this will help in a follow-up patch to add more code on the error
> path.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


> ---
>  xen/arch/arm/acpi/boot.c | 25 ++---
>  1 file changed, 14 insertions(+), 11 deletions(-)
> 
> diff --git a/xen/arch/arm/acpi/boot.c b/xen/arch/arm/acpi/boot.c
> index c3242a0..889208a 100644
> --- a/xen/arch/arm/acpi/boot.c
> +++ b/xen/arch/arm/acpi/boot.c
> @@ -234,7 +234,7 @@ static int __init dt_scan_depth1_nodes(const void *fdt, 
> int node,
>   */
>  int __init acpi_boot_table_init(void)
>  {
> -int error;
> +int error = 0;
>  
>  /*
>   * Enable ACPI instead of device tree unless
> @@ -245,10 +245,7 @@ int __init acpi_boot_table_init(void)
>  if ( param_acpi_off || ( !param_acpi_force
>   && 
> device_tree_for_each_node(device_tree_flattened,
> dt_scan_depth1_nodes, 
> NULL)))
> -{
> -disable_acpi();
> -return 0;
> -}
> +goto disable;
>  
>  /*
>   * ACPI is disabled at this point. Enable it in order to parse
> @@ -260,16 +257,22 @@ int __init acpi_boot_table_init(void)
>  error = acpi_table_init();
>  if ( error )
>  {
> -disable_acpi();
> -return error;
> +printk("%s: Unable to initialize table parser (%d)\n",
> +   __FUNCTION__, error);
> +goto disable;
>  }
>  
> -if ( acpi_table_parse(ACPI_SIG_FADT, acpi_parse_fadt) )
> +error = acpi_table_parse(ACPI_SIG_FADT, acpi_parse_fadt);
> +if ( error )
>  {
> -/* disable ACPI if no FADT is found */
> -disable_acpi();
> -printk("Can't find FADT\n");
> +printk("%s: FADT not found (%d)\n", __FUNCTION__, error);
> +goto disable;
>  }
>  
>  return 0;
> +
> +disable:
> +disable_acpi();
> +
> +return error;
>  }
> -- 
> 1.9.1
> 

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

[Xen-devel] OVMF blows up at unless I use pci_platform=0

[Konrad Rzeszutek Wilk]

Hey,

I just built today Xen based on  93e1435290867703c50acad1f54b9208df473562
Author: Oleksandr Tyshchenko 
Date:   Wed Feb 15 12:20:01 2017 +

IOMMU: always call teardown callback

And tried this guest which used to work in the past:

# more root-image-uefi.xm 
kernel = "hvmloader"
bios="ovmf"
builder='hvm'
memory=1024
serial='pty'
#serial='file:/root/uefi-log.txt"
vcpus = 2
name="bootstrap-x86_64-pvhvm-uefi"
disk = [ 'file:/home/konrad/root_image-uefi.iso,hdc:cdrom,r']
boot="dn"
vif = [ 'mac=00:0F:4B:00:00:68, bridge=switch' ]
vnc=1
vnclisten="0.0.0.0"
usb=1
usbdevice="tablet"
xen_platform_pci=1
nested=1

#xl create -c root-image-uefi.xm
I get:

 X64 Exception Type - 0E(#PF - Page-Fault)  CPU Apic ID -  
RIP  - 3F2658DB, CS  - 0038, RFLAGS - 00010206
ExceptionData - 0002
RAX  - 0001, RCX - 3F2658BB, RDX - 0004
RBX  - , RSP - 3F43B510, RBP - 3E574D18
RSI  - 0003, RDI - 0001
R8   - , R9  - , R10 - 3EA39198
R11  - 0002, R12 - 3E575218, R13 - 
R14  - 3E575220, R15 - 3F269301
DS   - 0030, ES  - 0030, FS  - 0030
GS   - 0030, SS  - 0030
CR0  - C033, CR2 - BF2658BB, CR3 - 3F3DA000
CR4  - 0668, CR8 - 
DR0  - , DR1 - , DR2 - 
DR3  - , DR6 - 0FF0, DR7 - 0400
GDTR - 3F3C8A98 0047, LDTR - 
IDTR - 3EAFD018 0FFF,   TR - 
FXSAVE_STATE - 3F43B170
 Find PE image 
/home/konrad/xen/tools/firmware/ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC5/X64/OvmfPkg/XenBusDxe/XenBusDxe/DEBUG/XenBusDxe.dll
 (ImageBase=3F262000, EntryPoint=3F263FE8) 


Now interestingly enough, if I change 'xen_platform_pci' to be '0'
it works peachy ...  except later on I hit something else.

(If I try running Xen under Xen, if I just boot Linux it works OK):

Xen 4.9-unstable (c/s Wed Feb 15 12:20:01 2017 + git:93e1435-dirty) EFI 
loader
Using configuration file 'xen.cfg'
vmlinuz: 0x3c766000-0x3cc9d790
initramfs.cpio.gz: 0x3519e000-0x3b66d47f
 Xen 4.9-unstable
(XEN) Xen version 4.9-unstable (konrad@) (gcc (GCC) 6.3.1 20161221 (Red Hat 
6.3.1-1)) debug=y  Wed Feb 15 11:23:32 EST 2017
(XEN) Latest ChangeSet: Wed Feb 15 12:20:01 2017 + git:93e1435-dirty
(XEN) Bootloader: EFI
(XEN) Command line: console=vga,com1 com1=115200,8n1 iommu=verbose
(XEN) Video information:
(XEN)  VGA is graphics mode 800x600, 32 bpp
(XEN) Disc information:
(XEN)  Found 0 MBR signatures
(XEN)  Found 0 EDD information structures
(XEN) EFI RAM map:
(XEN)   - 000a (usable)
(XEN)  0010 - 3e1c6000 (usable)
(XEN)  3e1c6000 - 3e1c7000 (ACPI data)
(XEN)  3e1c7000 - 3e2a7000 (usable)
(XEN)  3e2a7000 - 3e2c7000 (reserved)
(XEN)  3e2c7000 - 3e2d (ACPI data)
(XEN)  3e2d - 3e2f5000 (reserved)
(XEN)  3e2f5000 - 3f375000 (usable)
(XEN)  3f375000 - 3f3cd000 (reserved)
(XEN)  3f3cd000 - 3f3d5000 (ACPI data)
(XEN)  3f3d5000 - 3f3d9000 (ACPI NVS)
(XEN)  3f3d9000 - 3f68 (usable)
(XEN)  3f68 - 3f6a (reserved)
(XEN)  3f6a - 3f6b5000 (usable)
(XEN)  fc00 - fd00 (reserved)
(XEN) System RAM: 1013MB (1037832kB)
(XEN) ACPI: RSDP 3F3D4014, 0024 (r2Xen)
(XEN) ACPI: XSDT 3F3D30E8, 005C (r1Xen  HVM0   113)
(XEN) ACPI: FACP 3F3D2000, 00F4 (r4Xen  HVM0 HVML0)
(XEN) ACPI: DSDT 3E2C7000, 8FAC (r2Xen  HVM0 INTL 20160831)
(XEN) ACPI: FACS 3F3D8000, 0040
(XEN) ACPI: APIC 3F3D1000, 0068 (r2Xen  HVM0 HVML0)
(XEN) ACPI: HPET 3F3D, 0038 (r1Xen  HVM0 HVML0)
(XEN) ACPI: WAET 3F3CF000, 0028 (r1Xen  HVM0 HVML0)
(XEN) ACPI: SSDT 3F3CE000, 0031 (r2Xen  HVM0 INTL 20160831)
(XEN) ACPI: SSDT 3F3CD000, 0031 (r2Xen  HVM0 INTL 20160831)
(XEN) ACPI: BGRT 3E1C6000, 0038 (r1 INTEL  EDK22   113)
(XEN) No NUMA configuration found
(XEN) Faking a node at -3f6b5000
(XEN) Domain heap initialised
(XEN) vesafb: framebuffer at 0xf000, mapped to 0x82c000201000, using 
1920k, total 1920k
(XEN) vesafb: mode is 800x600x32, linelength=3200, font 8x8
(XEN) vesafb: Truecolor: size=8:8:8:8, shift=24:16:8:0
(XEN) CPU Vendor: Intel, Family 6 (0x6), Model 42 (0x2a), Stepping 7 (raw 
000206a7)
(XEN) SMBIOS 2.8 present.
(XEN) DMI 2.8 present.
(XEN) Using APIC driver default
(

Re: [Xen-devel] [PATCH RFC V2 0/7] COLO-Proxy: Make Xen COLO use userspace colo-proxy

[Zhang Chen]

On 02/16/2017 12:18 AM, Konrad Rzeszutek Wilk wrote:

On Wed, Feb 15, 2017 at 05:54:26PM +0800, Zhang Chen wrote:

Because of some reason, We no longer support COLO kernel proxy.
So we send this patch set to make Xen use userspace colo-proxy in qemu.

How come it is RFC? It looks quite baked?


We just want to get more comments, maybe we should remove the 'RFC' tag 
in next version.


Thanks
Zhang Chen






--
Thanks
Zhang Chen




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

Re: [Xen-devel] [PATCH 1/8] xen/arm: acpi: Handle correctly detection of GICv2 on GICv3

[Stefano Stabellini]

On Fri, 3 Feb 2017, Julien Grall wrote:
> When the GICv3 is not GICv2 compatible, the associated field in the MADT
> will be zeroed. However, the rest of the code expects the variable to
> be set to INVALID_PADDR.
> 
> This will result to false detection of GICv2 and give I/O access to page
> 0 for the hardware domain.
> 
> Thankfully, it will fail because the size of GICV has not been set.
> 
> Fix the detection by converting 0 to INVALID_PADDR for the GICC and
> GICV base. At the same time only set the size of each region when the
> base address is not 0.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 

> ---
>  xen/arch/arm/gic-v3.c | 20 +++-
>  1 file changed, 19 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
> index 955591b..bb1861e 100644
> --- a/xen/arch/arm/gic-v3.c
> +++ b/xen/arch/arm/gic-v3.c
> @@ -1356,7 +1356,6 @@ gic_acpi_parse_madt_cpu(struct acpi_subtable_header 
> *header,
>  if ( !cpu_base_assigned )
>  {
>  cbase = processor->base_address;
> -csize = SZ_8K;
>  vbase = processor->gicv_base_address;
>  gicv3_info.maintenance_irq = processor->vgic_interrupt;
>  
> @@ -1505,6 +1504,25 @@ static void __init gicv3_acpi_init(void)
>  panic("GICv3: No valid GICC entries exists");
>  
>  gicv3.rdist_stride = 0;
> +
> +/*
> + * In ACPI, 0 is considered as the invalid address. However the rest
> + * of the initialization rely on the invalid address to be
> + * INVALID_ADDR.
> + *
> + * Also set the size of the GICC and GICV when there base address
> + * is not invalid as those values are not present in ACPI.
> + */
> +if ( !cbase )
> +cbase = INVALID_PADDR;
> +else
> +csize = SZ_8K;
> +
> +if ( !vbase )
> +vbase = INVALID_PADDR;
> +else
> +vsize = GUEST_GICC_SIZE;
> +
>  }
>  #else
>  static void __init gicv3_acpi_init(void) { }
> -- 
> 1.9.1
> 

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

Re: [Xen-devel] [PATCH] xen/arm: Remove build option CONFIG_LOAD_ADDRESS

[Stefano Stabellini]

On Fri, 3 Feb 2017, Julien Grall wrote:
> The build option CONFIG_LOAD_ADDRESS is defined but never plumbed
> through.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


> ---
>  config/arm32.mk| 2 --
>  config/arm64.mk| 2 --
>  xen/arch/arm/Makefile  | 2 +-
>  xen/arch/arm/xen.lds.S | 4 ++--
>  4 files changed, 3 insertions(+), 7 deletions(-)
> 
> diff --git a/config/arm32.mk b/config/arm32.mk
> index 001e214..f95228e 100644
> --- a/config/arm32.mk
> +++ b/config/arm32.mk
> @@ -12,6 +12,4 @@ CFLAGS += -marm
>  # Use only if calling $(LD) directly.
>  LDFLAGS_DIRECT += -EL
>  
> -CONFIG_LOAD_ADDRESS ?= 0x8000
> -
>  IOEMU_CPU_ARCH ?= arm
> diff --git a/config/arm64.mk b/config/arm64.mk
> index 5a8e534..aa45772 100644
> --- a/config/arm64.mk
> +++ b/config/arm64.mk
> @@ -9,8 +9,6 @@ CFLAGS += #-marm -march= -mcpu= etc
>  # Use only if calling $(LD) directly.
>  LDFLAGS_DIRECT += -EL
>  
> -CONFIG_LOAD_ADDRESS ?= 0x8000
> -
>  IOEMU_CPU_ARCH ?= aarch64
>  
>  EFI_DIR ?= /usr/lib64/efi
> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
> index 91cb3f3..0ce94a8 100644
> --- a/xen/arch/arm/Makefile
> +++ b/xen/arch/arm/Makefile
> @@ -114,7 +114,7 @@ asm-offsets.s: $(TARGET_SUBARCH)/asm-offsets.c
>   $(CC) $(filter-out -flto,$(CFLAGS)) -S -o $@ $<
>  
>  xen.lds: xen.lds.S
> - $(CC) -P -E -Ui386 $(AFLAGS) -DXEN_PHYS_START=$(CONFIG_LOAD_ADDRESS) -o 
> $@ $<
> + $(CC) -P -E -Ui386 $(AFLAGS) -o $@ $<
>   sed -e 's/xen\.lds\.o:/xen\.lds:/g' <.xen.lds.d >.xen.lds.d.new
>   mv -f .xen.lds.d.new .xen.lds.d
>  
> diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
> index ddef595..94b7049 100644
> --- a/xen/arch/arm/xen.lds.S
> +++ b/xen/arch/arm/xen.lds.S
> @@ -21,7 +21,7 @@ OUTPUT_ARCH(FORMAT)
>  
>  PHDRS
>  {
> -  text PT_LOAD /* XXX should be AT ( XEN_PHYS_START ) */ ;
> +  text PT_LOAD ;
>  #if defined(BUILD_ID)
>note PT_NOTE ;
>  #endif
> @@ -30,7 +30,7 @@ SECTIONS
>  {
>. = XEN_VIRT_START;
>_start = .;
> -  .text : /* XXX should be AT ( XEN_PHYS_START ) */ {
> +  .text : {
>  _stext = .;/* Text section */
> *(.text)
> *(.text.cold)
> -- 
> 1.9.1
> 

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

Re: [Xen-devel] [PATCH] xen/arm: Remove the makefile target xen.axf

[Stefano Stabellini]

On Fri, 3 Feb 2017, Julien Grall wrote:
> Since commit 4557c22 "xen: arm: rewrite start of day page table and cpu
> bring up", Xen requires to be launched in NS HYP/EL2.
> 
> xen.axf is generated in order to directly boot Xen on ARM models (e.g
> Foundation). However they usually start in secure mode, which mean Xen
> cannot boot.
> 
> The way forward to boot Xen on models is using either EFI or
> bootwrapper [1].
> 
> [1] 
> https://git.kernel.org/cgit/linux/kernel/git/mark/boot-wrapper-aarch64.git/
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


> ---
>  xen/arch/arm/Makefile | 9 +
>  1 file changed, 1 insertion(+), 8 deletions(-)
> 
> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
> index 7afb8a3..91cb3f3 100644
> --- a/xen/arch/arm/Makefile
> +++ b/xen/arch/arm/Makefile
> @@ -70,18 +70,12 @@ else
>  all_symbols =
>  endif
>  
> -$(TARGET): $(TARGET)-syms $(TARGET).axf
> +$(TARGET): $(TARGET)-syms
>   $(OBJCOPY) -O binary -S $< $@
>  ifeq ($(CONFIG_ARM_64),y)
>   ln -sf $(notdir $@)  ../../$(notdir $@).efi
>  endif
>  
> -$(TARGET).axf: $(TARGET)-syms
> - # XXX: VE model loads by VMA so instead of
> - # making a proper ELF we link with LMA == VMA and adjust crudely
> - $(OBJCOPY) --change-addresses +0x8000 $< $@
> - $(STRIP) $@
> -
>  ifeq ($(CONFIG_LTO),y)
>  # Gather all LTO objects together
>  prelink_lto.o: $(ALL_OBJS)
> @@ -130,5 +124,4 @@ dtb.o: $(CONFIG_DTB_FILE)
>  clean::
>   rm -f asm-offsets.s xen.lds
>   rm -f $(BASEDIR)/.xen-syms.[0-9]*
> - rm -f $(TARGET).axf
>   rm -f $(TARGET).efi
> -- 
> 1.9.1
> 

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

[Xen-devel] [xen-4.4-testing test] 105815: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-winxpsp3  6 xen-boot   fail REGR. vs. 103812
 test-armhf-armhf-libvirt-raw  5 xen-install  fail REGR. vs. 103812
 test-amd64-i386-xend-qemut-winxpsp3  9 windows-install   fail REGR. vs. 103812

Regressions which are regarded as allowable (not blocking):
 test-xtf-amd64-amd64-2   16 xtf/test-pv32pae-selftestfail  like 103812
 test-xtf-amd64-amd64-4   16 xtf/test-pv32pae-selftestfail  like 103812
 test-xtf-amd64-amd64-3   20 xtf/test-hvm32-invlpg~shadow fail  like 103812
 test-xtf-amd64-amd64-3 32 xtf/test-hvm32pae-invlpg~shadow fail like 103812
 test-xtf-amd64-amd64-3   43 xtf/test-hvm64-invlpg~shadow fail  like 103812
 test-xtf-amd64-amd64-2   53 leak-check/check fail  like 103812
 test-xtf-amd64-amd64-4   53 leak-check/check fail  like 103812
 test-xtf-amd64-amd64-1   53 leak-check/check fail  like 103812
 test-xtf-amd64-amd64-5   53 leak-check/check fail  like 103812
 test-xtf-amd64-amd64-3   53 leak-check/check fail  like 103812
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 103812
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 103812

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-2   10 xtf-fep  fail   never pass
 test-xtf-amd64-amd64-4   10 xtf-fep  fail   never pass
 test-xtf-amd64-amd64-2   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-4   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-2 30 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-4 30 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-1   10 xtf-fep  fail   never pass
 test-xtf-amd64-amd64-2 36 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-5   10 xtf-fep  fail   never pass
 test-xtf-amd64-amd64-2   40 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-4 36 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-1   16 xtf/test-pv32pae-selftestfail   never pass
 test-xtf-amd64-amd64-1   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-4   40 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-1 30 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-1 36 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-1   40 xtf/test-hvm64-cpuid-faulting fail  never pass
 build-amd64-rumprun   7 xen-buildfail   never pass
 build-i386-rumprun7 xen-buildfail   never pass
 test-xtf-amd64-amd64-3   10 xtf-fep  fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-xtf-amd64-amd64-2   52 xtf/test-hvm64-xsa-195   fail   never pass
 test-xtf-amd64-amd64-4   52 xtf/test-hvm64-xsa-195   fail   never pass
 test-xtf-amd64-amd64-1   52 xtf/test-hvm64-xsa-195   fail   never pass
 test-xtf-amd64-amd64-5   52 xtf/test-hvm64-xsa-195   fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail never pass
 test-xtf-amd64-amd64-3   52 xtf/test-hvm64-xsa-195   fail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt 11 guest-start  fail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-sup

[Xen-devel] [PATCH] xen/arm: increase default dom0_mem to 512M

[Stefano Stabellini]

The default dom0_mem is 128M which is not sufficient to boot a Ubuntu
based Dom0. Increase it to 512M.

Signed-off-by: Stefano Stabellini 

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index c97a1f5..f4612a2 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -31,7 +31,7 @@ integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
 
 int dom0_11_mapping = 1;
 
-#define DOM0_MEM_DEFAULT 0x800 /* 128 MiB */
+#define DOM0_MEM_DEFAULT 0x2000 /* 512 MiB */
 static u64 __initdata dom0_mem = DOM0_MEM_DEFAULT;
 
 static void __init parse_dom0_mem(const char *s)

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

[Xen-devel] [xen-unstable-smoke test] 105830: tolerable trouble: broken/fail/pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   5 xen-buildfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  d65aa60073b452cfea909a9e023f1dac2cf3521c
baseline version:
 xen  adc017b80b18af63de7da077ed3382acef1222ec

Last test of basis   105825  2017-02-15 18:01:42 Z0 days
Testing same since   105830  2017-02-15 21:01:07 Z0 days1 attempts


People who touched revisions under test:
  Olaf Hering 
  Stefano Stabellini 

jobs:
 build-amd64  pass
 build-arm64  fail
 build-armhf  pass
 build-amd64-libvirt  pass
 build-arm64-pvopsfail
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  broken  
 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=d65aa60073b452cfea909a9e023f1dac2cf3521c
+ . ./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 
d65aa60073b452cfea909a9e023f1dac2cf3521c
+ branch=xen-unstable-smoke
+ revision=d65aa60073b452cfea909a9e023f1dac2cf3521c
+ . ./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.8-testing
+ '[' xd65aa60073b452cfea909a9e023f1dac2cf3521c = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : g

[Xen-devel] [PATCH] ACPICA: ACPI 6.0: Add support for IORT table.

[Sameer Goel]

From: Lv Zheng 

ACPICA commit 5de82757aef5d6163e37064033aacbce193abbca

This patch adds support for IORT (IO Remapping Table) in iasl.

Note that some field names are modified to shrink their length or the
decompiled IORT ASL will contain fields with ugly ":" alignment.

The IORT contains field definitions around "Memory Access Properties". This
patch also adds support to encode/decode it using inline table.

This patch doesn't add inline table support for the SMMU interrupt fields
due to a limitation in current ACPICA data table support. Lv Zheng.

Link: https://github.com/acpica/acpica/commit/5de82757
Signed-off-by: Lv Zheng 
Signed-off-by: Bob Moore 
Signed-off-by: Rafael J. Wysocki 
[Linux commit 874f6a723e56d0da9e481629b17482bcd3801ecf]
[only port the IORT changes]
Signed-off-by: Sameer Goel 
---
 xen/include/acpi/actbl2.h | 148 +-
 1 file changed, 146 insertions(+), 2 deletions(-)

diff --git a/xen/include/acpi/actbl2.h b/xen/include/acpi/actbl2.h
index d2327d2..e13c823 100644
--- a/xen/include/acpi/actbl2.h
+++ b/xen/include/acpi/actbl2.h
@@ -5,7 +5,7 @@
  */
 
 /*
- * Copyright (C) 2000 - 2011, Intel Corp.
+ * Copyright (C) 2000 - 2016, Intel Corp.
  * All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
@@ -67,7 +67,8 @@
 #define ACPI_SIG_DBGP   "DBGP" /* Debug Port table */
 #define ACPI_SIG_DMAR   "DMAR" /* DMA Remapping table */
 #define ACPI_SIG_HPET   "HPET" /* High Precision Event Timer table */
-#define ACPI_SIG_IBFT   "IBFT" /* i_sCSI Boot Firmware Table */
+#define ACPI_SIG_IBFT   "IBFT" /* iSCSI Boot Firmware Table */
+#define ACPI_SIG_IORT   "IORT" /* IO Remapping Table */
 #define ACPI_SIG_IVRS   "IVRS" /* I/O Virtualization Reporting 
Structure */
 #define ACPI_SIG_MCFG   "MCFG" /* PCI Memory Mapped Configuration 
table */
 #define ACPI_SIG_MCHI   "MCHI" /* Management Controller Host Interface 
table */
@@ -556,6 +557,149 @@ struct acpi_ibft_target {
 
 
/***
  *
+ * IORT - IO Remapping Table
+ *
+ * Conforms to "IO Remapping Table System Software on ARM Platforms",
+ * Document number: ARM DEN 0049B, October 2015
+ *
+ 
**/
+
+struct acpi_table_iort {
+   struct acpi_table_header header;
+   u32 node_count;
+   u32 node_offset;
+   u32 reserved;
+};
+
+/*
+ * IORT subtables
+ */
+struct acpi_iort_node {
+   u8 type;
+   u16 length;
+   u8 revision;
+   u32 reserved;
+   u32 mapping_count;
+   u32 mapping_offset;
+   char node_data[1];
+};
+
+/* Values for subtable Type above */
+
+enum acpi_iort_node_type {
+   ACPI_IORT_NODE_ITS_GROUP = 0x00,
+   ACPI_IORT_NODE_NAMED_COMPONENT = 0x01,
+   ACPI_IORT_NODE_PCI_ROOT_COMPLEX = 0x02,
+   ACPI_IORT_NODE_SMMU = 0x03,
+   ACPI_IORT_NODE_SMMU_V3 = 0x04
+};
+
+struct acpi_iort_id_mapping {
+   u32 input_base; /* Lowest value in input range */
+   u32 id_count;   /* Number of IDs */
+   u32 output_base;/* Lowest value in output range */
+   u32 output_reference;   /* A reference to the output node */
+   u32 flags;
+};
+
+/* Masks for Flags field above for IORT subtable */
+
+#define ACPI_IORT_ID_SINGLE_MAPPING (1)
+
+struct acpi_iort_memory_access {
+   u32 cache_coherency;
+   u8 hints;
+   u16 reserved;
+   u8 memory_flags;
+};
+
+/* Values for cache_coherency field above */
+
+#define ACPI_IORT_NODE_COHERENT 0x0001 /* The device node is 
fully coherent */
+#define ACPI_IORT_NODE_NOT_COHERENT 0x /* The device node is 
not coherent */
+
+/* Masks for Hints field above */
+
+#define ACPI_IORT_HT_TRANSIENT  (1)
+#define ACPI_IORT_HT_WRITE  (1<<1)
+#define ACPI_IORT_HT_READ   (1<<2)
+#define ACPI_IORT_HT_OVERRIDE   (1<<3)
+
+/* Masks for memory_flags field above */
+
+#define ACPI_IORT_MF_COHERENCY  (1)
+#define ACPI_IORT_MF_ATTRIBUTES (1<<1)
+
+/*
+ * IORT node specific subtables
+ */
+struct acpi_iort_its_group {
+   u32 its_count;
+   u32 identifiers[1]; /* GIC ITS identifier arrary */
+};
+
+struct acpi_iort_named_component {
+   u32 node_flags;
+   u64 memory_properties;  /* Memory access properties */
+   u8 memory_address_limit;/* Memory address size limit */
+   char device_name[1];/* Path of namespace object */
+};
+
+struct acpi_iort_root_complex {
+   u64 memory_properties;  /* Memory access properties */
+   u32 ats_attribute;
+   u32 pci_segment_number;
+};
+
+/* Values for ats_attribute field above */
+
+#define ACPI_IORT_ATS_SUPPORTED 0x0001 /* The root complex 
supports ATS 

Re: [Xen-devel] [RFC QEMU PATCH 1/8] nvdimm: do not initialize label_data if label_size is zero

[Konrad Rzeszutek Wilk]

On Mon, Oct 10, 2016 at 08:34:16AM +0800, Haozhong Zhang wrote:
> When memory-backend-xen is used, the label_data pointer can not be got
> via memory_region_get_ram_ptr(). We will use other functions to get

Could you explain why it cannot be retrieved via that way?

> label_data once we introduce NVDIMM label support to Xen.

Is this an particular patch in this series that does that?
You may want to enumerate which one it is.

> 
> Signed-off-by: Haozhong Zhang 
> ---
> Cc: Xiao Guangrong 
> Cc: "Michael S. Tsirkin" 
> Cc: Igor Mammedov 
> ---
>  hw/mem/nvdimm.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/mem/nvdimm.c b/hw/mem/nvdimm.c
> index 7895805..d25993b 100644
> --- a/hw/mem/nvdimm.c
> +++ b/hw/mem/nvdimm.c
> @@ -87,7 +87,9 @@ static void nvdimm_realize(PCDIMMDevice *dimm, Error **errp)
>  align = memory_region_get_alignment(mr);
>  
>  pmem_size = size - nvdimm->label_size;
> -nvdimm->label_data = memory_region_get_ram_ptr(mr) + pmem_size;
> +if (nvdimm->label_size) {
> +nvdimm->label_data = memory_region_get_ram_ptr(mr) + pmem_size;
> +}
>  pmem_size = QEMU_ALIGN_DOWN(pmem_size, align);
>  
>  if (size <= nvdimm->label_size || !pmem_size) {
> -- 
> 2.10.1
> 

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

[Xen-devel] [xen-unstable baseline-only test] 68563: tolerable trouble: blocked/broken/fail/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail   like 68551
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail   like 68551
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail   like 68551
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 68551
 test-amd64-amd64-qemuu-nested-intel 17 capture-logs/l1(17) fail like 68551
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 68551
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 windows-installfail like 68551
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  9 windows-installfail like 68551

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   2 hosts-allocate   broken never pass
 build-arm64-pvops 2 hosts-allocate   broken never pass
 build-arm64-xsm   2 hosts-allocate   broken never pass
 build-arm64   3 capture-logs broken never pass
 build-arm64-xsm   3 capture-logs broken never pass
 build-arm64-pvops 3 capture-logs broken never pass
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-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-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass

version targeted for testing:
 xen  bdbc25b8722cc1e3921858530f8ac484892156d3
baseline version:
 xen  6f6d3b10ec8168e2a78cf385d89803397f116397

Last test of basis68551  2017-02-11 12:16:43 Z4 days
Testing same since68563  2017-02-15 11:14:44 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Boris Ostrovsky 
  Chao Gao 
  Ian Jackson 
 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate/x10 
fail REGR. vs. 105661

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds  9 debian-install   fail REGR. vs. 105661
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 105661
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 105661
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 105661
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 105661
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 105661
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 105661

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   5 xen-buildfail   never pass
 build-arm64-xsm   5 xen-buildfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-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-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-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
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  758378233b0b5d79a29735d95dc72410ef2f19aa
baseline version:
 xen  d31a0a29f5d7563b7361f7096316fd9e611d8673

Last test of basis   105661  2017-02-09 09:43:17 Z6 days
Testing same since   105819  2017-02-15 12:44:07 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 
  Julien Grall 
  Oleksandr Tyshchenko 

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

Re: [Xen-devel] [PATCH v15 05/10] x86: add multiboot2 protocol support for EFI platforms

[Daniel Kiper]

On Wed, Feb 15, 2017 at 03:22:02AM -0700, Jan Beulich wrote:
> >>> On 14.02.17 at 19:38,  wrote:
> > --- a/xen/arch/x86/boot/head.S
> > +++ b/xen/arch/x86/boot/head.S
> > @@ -394,10 +394,18 @@ __start:
> >
> >  /* EFI IA-32 platforms are not supported. */
> >  cmpl$MULTIBOOT2_TAG_TYPE_EFI32,MB2_tag_type(%ecx)
> > +/*
> > + * Here we should zap vga_text_buffer. However, we can disable
> > + * VGA updates in simpler and more reliable way later.
> > + */
> >  je  .Lmb2_efi_ia_32
> >
> >  /* Bootloader shutdown EFI x64 boot services. */
> >  cmpl$MULTIBOOT2_TAG_TYPE_EFI64,MB2_tag_type(%ecx)
> > +/*
> > + * Here we should zap vga_text_buffer. However, we can disable
> > + * VGA updates in simpler and more reliable way later.
> > + */
> >  je  .Lmb2_no_bs
>
> I'm afraid I don't view these comments as helpful in understanding
> the whole situation. That's partly because I don't follow both the
> "simpler" and "more reliable" parts (using just the information here,

OK, I will clarify it.

> i.e. leaving aside what you've given as explanation earlier, albeit I
> don't think that was fully clarifying things either), and partly
> because I continue to think that the explanation should go where
> the labels are (which is what I had meant to suggest with my
> comment placement in reply to v14). Nor does the adjustment

OK.

> above help (me) understand the correctness of the dual use of
> .Lmb2_no_bs.

What do you mean by "dual use of .Lmb2_no_bs."? I would like to be sure.

By the way, what about second half of the patch series? Does it make sense or
a little or is it total crap? Could you say something? You have not commented
it for a few releases, so, there is a chance that it is OK. However, opposite
is also possible. So, if you wish to fix something please say it now than later.
Then I will have more time to do the work.

Daniel

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

[Xen-devel] [PATCH v4 0/2] x86/kvm: Reduce vcpu_is_preempted() overhead

[Waiman Long]

 v3->v4:
  - Fix x86-32 build error.

 v2->v3:
  - Provide an optimized __raw_callee_save___kvm_vcpu_is_preempted()
in assembly as suggested by PeterZ.
  - Add a new patch to change vcpu_is_preempted() argument type to long
to ease the writing of the assembly code.

 v1->v2:
  - Rerun the fio test on a different system on both bare-metal and a
KVM guest. Both sockets were utilized in this test.
  - The commit log was updated with new performance numbers, but the
patch wasn't changed.
  - Drop patch 2.

As it was found that the overhead of callee-save vcpu_is_preempted()
can have some impact on system performance on a VM guest, especially
of x86-64 guest, this patch set intends to reduce this performance
overhead by replacing the C __kvm_vcpu_is_preempted() function by
an optimized version of __raw_callee_save___kvm_vcpu_is_preempted()
written in assembly.

Waiman Long (2):
  x86/paravirt: Change vcp_is_preempted() arg type to long
  x86/kvm: Provide optimized version of vcpu_is_preempted() for x86-64

 arch/x86/include/asm/paravirt.h  |  2 +-
 arch/x86/include/asm/qspinlock.h |  2 +-
 arch/x86/kernel/kvm.c| 32 +++-
 arch/x86/kernel/paravirt-spinlocks.c |  2 +-
 4 files changed, 34 insertions(+), 4 deletions(-)

-- 
1.8.3.1


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

[Xen-devel] [PATCH v4 1/2] x86/paravirt: Change vcp_is_preempted() arg type to long

[Waiman Long]

The cpu argument in the function prototype of vcpu_is_preempted()
is changed from int to long. That makes it easier to provide a better
optimized assembly version of that function.

For Xen, vcpu_is_preempted(long) calls xen_vcpu_stolen(int), the
downcast from long to int is not a problem as vCPU number won't exceed
32 bits.

Signed-off-by: Waiman Long 
---
 arch/x86/include/asm/paravirt.h  | 2 +-
 arch/x86/include/asm/qspinlock.h | 2 +-
 arch/x86/kernel/kvm.c| 2 +-
 arch/x86/kernel/paravirt-spinlocks.c | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 1eea6ca..f75fbfe 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -673,7 +673,7 @@ static __always_inline void pv_kick(int cpu)
PVOP_VCALL1(pv_lock_ops.kick, cpu);
 }
 
-static __always_inline bool pv_vcpu_is_preempted(int cpu)
+static __always_inline bool pv_vcpu_is_preempted(long cpu)
 {
return PVOP_CALLEE1(bool, pv_lock_ops.vcpu_is_preempted, cpu);
 }
diff --git a/arch/x86/include/asm/qspinlock.h b/arch/x86/include/asm/qspinlock.h
index c343ab5..48a706f 100644
--- a/arch/x86/include/asm/qspinlock.h
+++ b/arch/x86/include/asm/qspinlock.h
@@ -34,7 +34,7 @@ static inline void queued_spin_unlock(struct qspinlock *lock)
 }
 
 #define vcpu_is_preempted vcpu_is_preempted
-static inline bool vcpu_is_preempted(int cpu)
+static inline bool vcpu_is_preempted(long cpu)
 {
return pv_vcpu_is_preempted(cpu);
 }
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 099fcba..85ed343 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -589,7 +589,7 @@ static void kvm_wait(u8 *ptr, u8 val)
local_irq_restore(flags);
 }
 
-__visible bool __kvm_vcpu_is_preempted(int cpu)
+__visible bool __kvm_vcpu_is_preempted(long cpu)
 {
struct kvm_steal_time *src = &per_cpu(steal_time, cpu);
 
diff --git a/arch/x86/kernel/paravirt-spinlocks.c 
b/arch/x86/kernel/paravirt-spinlocks.c
index 6259327..8f2d1c9 100644
--- a/arch/x86/kernel/paravirt-spinlocks.c
+++ b/arch/x86/kernel/paravirt-spinlocks.c
@@ -20,7 +20,7 @@ bool pv_is_native_spin_unlock(void)
__raw_callee_save___native_queued_spin_unlock;
 }
 
-__visible bool __native_vcpu_is_preempted(int cpu)
+__visible bool __native_vcpu_is_preempted(long cpu)
 {
return false;
 }
-- 
1.8.3.1


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

[Xen-devel] [PATCH v4 2/2] x86/kvm: Provide optimized version of vcpu_is_preempted() for x86-64

[Waiman Long]

It was found when running fio sequential write test with a XFS ramdisk
on a KVM guest running on a 2-socket x86-64 system, the %CPU times
as reported by perf were as follows:

 69.75%  0.59%  fio  [k] down_write
 69.15%  0.01%  fio  [k] call_rwsem_down_write_failed
 67.12%  1.12%  fio  [k] rwsem_down_write_failed
 63.48% 52.77%  fio  [k] osq_lock
  9.46%  7.88%  fio  [k] __raw_callee_save___kvm_vcpu_is_preempt
  3.93%  3.93%  fio  [k] __kvm_vcpu_is_preempted

Making vcpu_is_preempted() a callee-save function has a relatively
high cost on x86-64 primarily due to at least one more cacheline of
data access from the saving and restoring of registers (8 of them)
to and from stack as well as one more level of function call.

To reduce this performance overhead, an optimized assembly version
of the the __raw_callee_save___kvm_vcpu_is_preempt() function is
provided for x86-64.

With this patch applied on a KVM guest on a 2-socekt 16-core 32-thread
system with 16 parallel jobs (8 on each socket), the aggregrate
bandwidth of the fio test on an XFS ramdisk were as follows:

   I/O Type  w/o patchwith patch
     ---
   random read   8141.2 MB/s  8497.1 MB/s
   seq read  8229.4 MB/s  8304.2 MB/s
   random write  1675.5 MB/s  1701.5 MB/s
   seq write 1681.3 MB/s  1699.9 MB/s

There are some increases in the aggregated bandwidth because of
the patch.

The perf data now became:

 70.78%  0.58%  fio  [k] down_write
 70.20%  0.01%  fio  [k] call_rwsem_down_write_failed
 69.70%  1.17%  fio  [k] rwsem_down_write_failed
 59.91% 55.42%  fio  [k] osq_lock
 10.14% 10.14%  fio  [k] __kvm_vcpu_is_preempted

The assembly code was verified by using a test kernel module to
compare the output of C __kvm_vcpu_is_preempted() and that of assembly
__raw_callee_save___kvm_vcpu_is_preempt() to verify that they matched.

Suggested-by: Peter Zijlstra 
Signed-off-by: Waiman Long 
---
 arch/x86/kernel/kvm.c | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 85ed343..e423435 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -589,6 +589,7 @@ static void kvm_wait(u8 *ptr, u8 val)
local_irq_restore(flags);
 }
 
+#ifdef CONFIG_X86_32
 __visible bool __kvm_vcpu_is_preempted(long cpu)
 {
struct kvm_steal_time *src = &per_cpu(steal_time, cpu);
@@ -597,11 +598,40 @@ __visible bool __kvm_vcpu_is_preempted(long cpu)
 }
 PV_CALLEE_SAVE_REGS_THUNK(__kvm_vcpu_is_preempted);
 
+#else
+
+extern bool __raw_callee_save___kvm_vcpu_is_preempted(long);
+
+/*
+ * Hand-optimize version for x86-64 to avoid 8 64-bit register saving and
+ * restoring to/from the stack. It is assumed that the preempted value
+ * is at an offset of 16 from the beginning of the kvm_steal_time structure
+ * which is verified by the BUILD_BUG_ON() macro below.
+ */
+#define PREEMPTED_OFFSET   16
+asm(
+".pushsection .text;"
+".global __raw_callee_save___kvm_vcpu_is_preempted;"
+".type __raw_callee_save___kvm_vcpu_is_preempted, @function;"
+"__raw_callee_save___kvm_vcpu_is_preempted:"
+"movq  __per_cpu_offset(,%rdi,8), %rax;"
+"cmpb  $0, " __stringify(PREEMPTED_OFFSET) "+steal_time(%rax);"
+"setne %al;"
+"ret;"
+".popsection");
+
+#endif
+
 /*
  * Setup pv_lock_ops to exploit KVM_FEATURE_PV_UNHALT if present.
  */
 void __init kvm_spinlock_init(void)
 {
+#ifdef CONFIG_X86_64
+   BUILD_BUG_ON((offsetof(struct kvm_steal_time, preempted)
+   != PREEMPTED_OFFSET) || (sizeof(steal_time.preempted) != 1));
+#endif
+
if (!kvm_para_available())
return;
/* Does host kernel support KVM_FEATURE_PV_UNHALT? */
-- 
1.8.3.1


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

Re: [Xen-devel] Xen 4.9 Development Update

[Sergej Proskurin]

Hi all,

Unfortunately, I have been quite busy over the last few months and did
not manage to finish the patch series, yet. I will continue working in
the next few weeks, however, it is rather unlikely to make the patch
series ready for 4.9.

Cheers
~Sergej

On 02/08/2017 07:59 PM, Tamas K Lengyel wrote:
> 
> *  Altp2m for ARM
>   -  Sergej Proskurin
> 
> 
> This was a GSoC project last summer that unfortunately didn't make the
> merge window. I'll probably pick it up sometime in the future and get it
> rebased but it is unlikely to happen for 4.9.
> 
> Tamas
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel
> 


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

Re: [Xen-devel] [PATCH v3] displif: add ABI for para-virtual display

[Konrad Rzeszutek Wilk]

.snip..
> > > > > I will define 2 sections:
> > > > >*-- Connector Request Transport Parameters
> > > > > ---
> > > > >*
> > > > >* ctrl-event-channel
> > > > >* ctrl-ring-ref
> > > > >*
> > > > >*--- Connector Event Transport Parameters
> > > > > 
> > > > >*
> > > > >* event-channel
> > > > >* event-ring-ref
> > > > > 
> > > > > > Or is the other ring buffer the one that is created via 
> > > > > > 'gref_directory' ?
> > > > > no
> > > > > At the bottom:
> > > > >* In order to deliver asynchronous events from back to front a 
> > > > > shared page
> > > > > is
> > > > >* allocated by front and its gref propagated to back via XenStore 
> > > > > entries
> > > > >* (event-XXX).
> > > > AAnd you may want to say this is guarded by REQ_ALLOC feature right?
> > > Not sure I understood you. Event path is totally independent
> > > from any feature, e.g. REQ_ALLOC.
> > > It just provides means to send async events
> > > from back to front, "page flip done" in my case.
> >  Why do you need a seperate ring to send
> > responses back? Why not use the same ring on which requests
> > were sent
> Ok, it seems we are not on the same page for rings/channels usage.
> Let me describe how those are used:
> 
> 1. Command/control event channel and its corresponding ring are used
> to pass requests from front to back (XENDISPL_OP_XXX) and get responses
> from the back. These are synchronous, use macros from ring.h:
> ctrl-event-channel + ctrl-ring-ref
> I call them "ctrl-" because this way front controls back, or sends commands
> if you will. Maybe "cmd-" would fit better here?
> 
> 2. Event channel - asynchronous path for the backend to signal activity
> to the frontend, currently used for "page flip done" event which is sent
> at some point of time after back has actually completed the page flip
> requested
> (so, before that the corresponding request was sent and response received,
> but
> operation didn't complete yet, instead it was scheduled)
> No macros exist for this use-case in ring.h (kbdif+fbif implement
> this on their own, so do I)
> These are:  event-channel + event-ring-ref
> Probably here is the point from where confusion comes, naming.
> We can have something like "be-to-fe-event-channel" or anything else
> more cute and descriptive.
> 
> Hope this explains the need for 2 paths

Aha!

So this is like the network where there is an 'rx' and 'tx'!

Now I get it.

In that case why not just prefix it with 'in' and 'out'? Such as:

'out-ring-ref' and 'out-event-channel' and 'in-ring-ref' along
with 'in-event-channel'.

Or perhaps better - borrow the same idea that Stefano came up for
9pfs and PV calls - where his ring does both.

Then you just need 'ring-ref', 'event-channel', 'max-page-ring-order'
(which must be 1 or larger).

And you split the ring-ref in two - one for 'in' events and the other
part for 'out' events?

..giant snip..

> > > > > Thus, I was thinking of XenbusStateReconfiguringstate as appropriate 
> > > > > in this
> > > > > case
> > > > Right, but somebody has to move to this state. Who would do it?
> > > when backend dies its state changes to "closed".
> > > At this moment front tries to remove virtualized device
> > > and if it is possible/done, then it goes into "initialized"
> > > state. If not - "reconfiguring".
> > > So, you would ask how does the front go from "reconfiguring"
> > > into "initialized" state? This is OS/front specific, but:
> > > 1. the underlying framework, e.g. DRM/KMS, ALSA, provide
> > > a callback(s) to signal that the last client to the
> > > virtualized device has gone and the driver can be removed
> > > (equivalent to module's usage counter 0)
> > > 2. one can schedule a delayed work (timer/tasklet/workqueue)
> > > to periodically check if this is the right time to re-try
> > > the removal and remove
> > > 
> > > In both cases, after the virtualized device has been removed we move
> > > into "initialized" state again and are ready for new connections
> > > with backend (if it arose from the dead :)
> > > > Would the
> > > > frontend have some form of timer to make sure that the backend is still
> > > > alive? And if it had died then move to Reconfiguring?
> > > There are at least 2 ways to understand if back is dead:
> > > 1. XenBus state change (back is closed)
> > .. If the backend does a nice shutdown..
> hm, on Linux I can kill -9 backend and XenBus driver seems
> to be able to turn back's state into "closed"
> isn't this expected behavior?

That is the expected behavior. I was thinking more of a backend
being a guest - and the guest completly going away and nobody
clearing its XenStore keys.

In which case your second option of doing a timeout will work.
But you may need an 'PING' type request to figure this out?


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

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

[Stefano Stabellini]

On Wed, 15 Feb 2017, Julien Grall wrote:
> Hi Stefano,
> 
> On 14/02/17 21:00, Stefano Stabellini wrote:
> > On Mon, 30 Jan 2017, Andre Przywara wrote:
> > > +/*
> > > + * Handle incoming LPIs, which are a bit special, because they are
> > > potentially
> > > + * numerous and also only get injected into guests. Treat them specially
> > > here,
> > > + * by just looking up their target vCPU and virtual LPI number and hand
> > > it
> > > + * over to the injection function.
> > > + */
> > > +void do_LPI(unsigned int lpi)
> > > +{
> > > +struct domain *d;
> > > +union host_lpi *hlpip, hlpi;
> > > +struct vcpu *vcpu;
> > > +
> > > +WRITE_SYSREG32(lpi, ICC_EOIR1_EL1);
> > > +
> > > +hlpip = gic_get_host_lpi(lpi);
> > > +if ( !hlpip )
> > > +return;
> > > +
> > > +hlpi.data = read_u64_atomic(&hlpip->data);
> > > +
> > > +/* We may have mapped more host LPIs than the guest actually asked
> > > for. */
> > > +if ( !hlpi.virt_lpi )
> > > +return;
> > > +
> > > +d = get_domain_by_id(hlpi.dom_id);
> > > +if ( !d )
> > > +return;
> > > +
> > > +if ( hlpi.vcpu_id >= d->max_vcpus )
> > > +{
> > > +put_domain(d);
> > > +return;
> > > +}
> > > +
> > > +vcpu = d->vcpu[hlpi.vcpu_id];
> > > +
> > > +put_domain(d);
> > > +
> > > +vgic_vcpu_inject_irq(vcpu, hlpi.virt_lpi);
> > 
> > put_domain should be here
> 
> Why? I don't even understand why we would need to take a reference on the
> domain for LPIs. Would not it be enough to use rcu_lock_domain_by_id here?

I think that rcu_lock_domain_by_id would also work, but similarly we
would need to call rcu_unlock here.

To be honest, I don't know exactly in which cases get_domain should be
used instead of rcu_lock_domain_by_id.

CC'ing the x86 guys that might know the answer.

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

Re: [Xen-devel] Xen ARM - Exposing a PL011 to the guest

[Stefano Stabellini]

On Wed, 15 Feb 2017, Bhupinder Thakur wrote:
> On 15 February 2017 at 13:45, Bhupinder Thakur
>  wrote:
> > Hi Stefano,
> >
> > On 14 February 2017 at 03:14, Stefano Stabellini  
> > wrote:
> >> On Mon, 13 Feb 2017, Bhupinder Thakur wrote:
> >>> Hi Stefano,
> >>>
> >>> On 9 February 2017 at 05:40, Stefano Stabellini  
> >>> wrote:
> >>> > On Wed, 8 Feb 2017, Bhupinder Thakur wrote:
> >>> >> Hi Julien,
> >>> >>
> >>> >> On 3 February 2017 at 19:38, Julien Grall  wrote:
> >>> >> > So if I understand correctly, you don't receive anymore output. 
> >>> >> > Correct?
> >>> >> > Have you tried to see whether the pl011 driver is receiving 
> >>> >> > interrupt or
> >>> >> > even Linux calling it.
> >>> >>
> >>> >> The pl011 driver is not receiving the interrupts (I put a
> >>> >> HYPERVISOR_console_io() call inside the interrupt handler and I do not
> >>> >> see the print on the xen console) . When the console is in this state,
> >>> >> if I keep typing the characters on the console then Xen keeps raising
> >>> >> the interrupts (for each character typed) but all those interrupts are
> >>> >> marked as inflight. So it seems that interrupt is not getting cleared
> >>> >> in GIC. Which GIC function can I look at to further debug what is the
> >>> >> issue?
> >>> >>
> >>> >> Earlier, when I used to manually write characters to /dev/ttyAMA0 then
> >>> >> I used to receive the interrupts all fine.
> >>> >
> >>> > DomU doesn't get emulated PL011 interrupts from Xen? Make sure you don't
> >>> > mark the interrupt as a real hardware interrupt by mistake
> >>> > (GICH_V2_LR_HW). At the same time, check that the virtual PL011
> >>> > interrupt has been added correctly to the LRs
> >>> > (xen/arch/arm/gic-v2.c:gicv2_update_lr).
> >>>
> >>> I verified that the PL011 interrupt is getting marked pending by Xen
> >>> but guest does not receive it. I am not sure if the local interrupt
> >>> delivery is disabled on the guest because of which it may not be
> >>> receiving the interrupts. Is there a way to verify that interrupts are
> >>> indeed disabled at that point. Since the interrupt delivery works fine
> >>> when I manually read/write characters to /dev/ttyAMA0, I think there
> >>> is no issue from the Xen side in terms of raising an interrupt.
> >>>
> >>> One observation is that pl011_request_port () calls request_mem_region
> >>> () for the MMIO space allocated to pl011. The function returns -EBUSY
> >>> indicating that the memory region is already in use. But when I do cat
> >>> /proc/iomem, I do not see any overlaps. I am using 0x2200 as the
> >>> start of the pl011 MMIO space. I see the same error while booting the
> >>> dom0 kernel also.
> >>>
> >>> I have attached the guest boot logs when console=ttyAMA0. I have added
> >>> debug prints marked with [DEBUG]. I added debug prints in amba-pl011.c
> >>> and serial_core.c. The output from the console seems to suddenly stop
> >>> once the pl011 port is started. I have not added getty for ttyAMA0 in
> >>> the /etc/inittab file. I believe auto-serial-console should be able to
> >>> attach a getty session to ttyAMA0 automatically (i did try with adding
> >>> a getty command in the inittab file but that did not solve the issue).
> >>>
> >>> Towards the end of the log, we can see that every time a character is
> >>> typed, Xen raises an interrupt and the characters keep getting
> >>> collected in the IN RING buffer (in_prod keeps incrementing). Later
> >>> interrupts remain in inflight as the earlier interrupt is not cleared.
> >>
> >> Let me get this straight: who is printing all those messages we see on
> >> the guest console (xl console guest) up until "Freeing unused kernel
> >> memory"?  Is it the early pl011 driver? Or is it the Xen PV console
> >> driver?
> >>
> >> Are you using a DEBUG build of Xen? Only DEBUG builds allow DomUs to
> >> issue HYPERVISOR_console_io hypercalls. You might want to check that
> >> do_console_io in Xen is letting DomU calls through.
> >>
> >> Otherwise pl011_int might actually be called but the printk might not
> >> show up on the Xen console.
> >>
> >> The interrupt is enabled from Xen point of view, otherwise it would not
> >> be added to the LR. However Linux might still refuse to call the
> >> interrupt handler for some reason. You might want to add a printk in the
> >> Linux generic interrupt handler, probably
> >> kernel/irq/chip.c:handle_fasteoi_irq in your case.
> >
> > The pl011 console is working now. I did not fix any thing specific
> > except I cleaned up the debug code which I had added. I am not sure if
> > some of my debug code was causing the issue.
> >
> > After cleaning up the debug code and building the code afresh, I
> > started receiving the interrupts and input/output on the console is
> > working fine. Now I am able to execute commands on the console.
> >
> I believe since I was using printk in the pl011 console driver code
> for debugging, that might be causing some infinite loop. Once I
> replaced all printks with H

Re: [Xen-devel] [PATCH v3 1/4] x86/mm: Adapt MODULES_END based on Fixmap section size

[Borislav Petkov]

On Wed, Feb 15, 2017 at 04:49:21PM +0100, Borislav Petkov wrote:
> On Wed, Feb 15, 2017 at 07:40:51AM -0800, Thomas Garnier wrote:
> > Why do you think they rely on it being static? The VSYSCALL address is
> > not changed for example.
> 
> I don't know, that's why I'm asking first. Userspace is known to pick
> different aspects of the kernel and deciding to use them for whatever.
> And once it relies on that, there's no changing it.

Ok, so we should be fine here because those addresses are internal to
the kernel, I'm being told, so anything using them will break and gets
to keep the pieces even.

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 

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

Re: [Xen-devel] Install of Xen 4.8 on Fedora 25 makes the box unbootable.. which is due to /var/run/xen being created, instead of /run/xen

[Boris Ostrovsky]

On 02/15/2017 03:51 PM, Konrad Rzeszutek Wilk wrote:
> Hey,
>
> Credit goes to Boris (CC-ed) for figuring out how to fix this.
>
> I was doing:
>
> ./configure --prefix=/usr --enable-systemd
> make -j8
> cd dist;./install.sh;)
> reboot
>
> and to my surprise it would hang on 
> Starting Terminate Plymouth Boot Screen"...   
>  
>   
>   
> with a bunch of 'FAILED'. 
>  
>
>
> What I hadn't realized is that Fedora has removed the
> /var/run and is now using /run. But the dist/install
> has the /var/run directory (dist/install/var/run/) in it -
> and that seems to make everything blow up as it erase
> the original symlink:
>
> [konrad@x230 /]$ ls -al /var/run
> lrwxrwxrwx. 1 root root 6 Oct  5 02:08 /var/run -> ../run
>
> with its own directory which has nothing to do with /run - and
> which only has 'xen' and 'xenstored' in it (albeit at bootup things
> do seem to be created there - but they are not in sync with things in 
> /run).
>
>
> The "Fix" is to boot with 'init=/bin/bash' on Linux command line and do:
>
> mount / -o remount,rw
> rm -rf /var/run
> mkdir /run/xen
> mkdir /run/xenstored
> ln -sf /run /var/run
>
> And then everything works again.
>
> A bit of light builds shows that RELEASE-4.7.0
> does not have an dist/install/var/run but
> RELEASE-4.8.0 and higher does.
>
> And I am not exactly sure which commit does this and
> how to go around to auto-detect this? 

I *think* this started happening after
  https://lists.xenproject.org/archives/html/xen-devel/2016-08/msg00372.html

-boris


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

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

[Stefano Stabellini]

On Wed, 15 Feb 2017, Lars Kurth wrote:
> Hi all,
> 
> I am kind of stuck on this one and wanted to pick up the discussion again. 
> Apologies that it took so long.
> 
> To to summarise, we all are agreed on most sections of the proposal,
> with the exception of decision making across projects. One option is to
> just apply what we agreed on and leave the area which is not agreed as is.
> However, that is still quite a bit of work, and won't solve the underlying
> problem.
> 
> Ian's comments below summarise the situation quite clearly.
> 
> > On 2 Dec 2016, at 19:06, Stefano Stabellini  wrote:
> > 
> > On Fri, 2 Dec 2016, Lars Kurth wrote:
> >> On 01/12/2016 22:36, "Stefano Stabellini"  wrote:
> >> 
> >>> On Thu, 1 Dec 2016, Ian Jackson wrote:
>  Lars Kurth writes ("Re: [PATCH v5 3/3] Significant changes to decision
>  making; some new roles and minor changes"):
> > Maybe Ian has some views on what is better from a theoretical
>  viewpoint:
> > Voting mechanisms are a bit of a hobby of his
>  
>  The underlying problem here is that the reality is that the Xen
>  Project's by-far most important subproject is the hypervisor; that it
>  seems that the governance probably ought to reflect that; but that it
>  is difficult to do this without special casing it or providing an
>  objective metric of the hypervisor subproject's size.
>  
>  I don't think it is possible to square this circle.  Our options are:
>  
>  1. Explicitly recognise the hypervisor subproject as special.
>    (This could be done by creating a new `superproject' maturity
>    category, or simply by naming it explicitly.)
> 
> I think that option is somewhat problematic.
> 
>  2. Do some kind of bodge which tries to reduce the impact of the
>    potential unknown management practices of other subprojects
>    (particularly, that they might appoint lots of leaders).
>  
>  3. Restructure the hypervisor sub-project.
>  
>  The current proposal is (2) and has the virtue of not incentivising a
>  subproject to appoint lots of leaders simply to get more votes
>  overall.  But it is still rather weak because it has to treat the
>  hypervisor subproject as only one amongst many, so hypervisor leaders
>  are under-powered and fringe leaders over-powered.
> 
> Agreed.
> 
> As an additional note, I would like to highlight that it also has the
> advantage of being consistent with the already agreed per-sub-project
> leadership model. 
> 
> And that the proposed model - although not perfect - is better than what
> we had before.
> 
>  Another way to deal with this would be to split the hypervisor
>  subproject (3, above).  For example, we could create subprojects for
>  some subset of minios, osstest, xtf, various out-of-tree tools,...
>  (many of which would have only one leadership team member).
> 
> I am assuming that would mean:
> - leave the proposal as it is
> - in addition create a new sub-project, say "Hypervisor Infrastructure"
>   or "Hypervisor Support Infrastructure" (we can debate the name later)
> 
> That would re-balance the original proposal and give hypervisor 
> maintainers / committers more weight (which mostly also are in the 
> hypervisor project leadership team) and thus address Stefano's concerns.
> 
>  That would mean that the hypervisor-focused maintainers would get
>  additional votes via their other "hats".  (They would still get a vote
>  in the hypervisor subproject, if they have a hypervisor leadership
>  position too.)
>  
>  This is perhaps less unnatural.  It still leaves fringe leaders
>  somewhat over-powered: this time, leaders of more-hypervisor-related
>  (or some such) fringe things, rather than leaders of
>  less-hypervisor-related fringe things.
> 
> If we look at the current repos, which could fit into there, aka
> mini-os, osstest, raisin, livepatch-build-tools & xtf we would end up with the
> following leadership team.
> 
> Ian Jackson (osstest)
> Andrew Cooper (xtf)
> George Dunlap, Stefano Stabellini (raisin) 
> Ross Lagerwell, Konrad Wilk (livepatch-build-tools) 
> Wei Lui (mini-os)
> 
> So it makes this very similar to the hypervisor project leadership team,
> with the exception of Jan. There might be areas such as xtf, which Jan
> could be potentially interested in. And if ARM support comes along for xtf, 
> that would also give us a route in this direction. We could also include
> others such as Doug Goldstein, who have been stepping up on some build
> and quality related initiatives. 
> 
> We would have to formalise who is part of the leadership team, and who 
> does what. But that would be a good idea anyway in my view.
>  
> >>> Istinctively, I don't like the idea of splitting up the hypervisor
> >>> project in multiple projects.
> >> 
> >> We could split out the following git repos: mini-os, osstest, raisin,
> >> livepatch-build-tools, xtf
>

[Xen-devel] Install of Xen 4.8 on Fedora 25 makes the box unbootable.. which is due to /var/run/xen being created, instead of /run/xen

[Konrad Rzeszutek Wilk]

Hey,

Credit goes to Boris (CC-ed) for figuring out how to fix this.

I was doing:

./configure --prefix=/usr --enable-systemd
make -j8
cd dist;./install.sh;)
reboot

and to my surprise it would hang on 
Starting Terminate Plymouth Boot Screen"... 
   


with a bunch of 'FAILED'.   
   


What I hadn't realized is that Fedora has removed the
/var/run and is now using /run. But the dist/install
has the /var/run directory (dist/install/var/run/) in it -
and that seems to make everything blow up as it erase
the original symlink:

[konrad@x230 /]$ ls -al /var/run
lrwxrwxrwx. 1 root root 6 Oct  5 02:08 /var/run -> ../run

with its own directory which has nothing to do with /run - and
which only has 'xen' and 'xenstored' in it (albeit at bootup things
do seem to be created there - but they are not in sync with things in 
/run).


The "Fix" is to boot with 'init=/bin/bash' on Linux command line and do:

mount / -o remount,rw
rm -rf /var/run
mkdir /run/xen
mkdir /run/xenstored
ln -sf /run /var/run

And then everything works again.

A bit of light builds shows that RELEASE-4.7.0
does not have an dist/install/var/run but
RELEASE-4.8.0 and higher does.

And I am not exactly sure which commit does this and
how to go around to auto-detect this? 

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

[Xen-devel] [xen-unstable-smoke test] 105825: tolerable trouble: broken/fail/pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   5 xen-buildfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 build-arm64-pvops 5 kernel-build fail   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  adc017b80b18af63de7da077ed3382acef1222ec
baseline version:
 xen  93e1435290867703c50acad1f54b9208df473562

Last test of basis   105820  2017-02-15 13:01:10 Z0 days
Failing since105822  2017-02-15 16:02:25 Z0 days2 attempts
Testing same since   105825  2017-02-15 18:01:42 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Dario Faggioli 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Konrad Rzeszutek Wilk 
  Meng Xu 
  Oleksandr Andrushchenko 
  Stefano Stabellini 
  Tamas K Lengyel 
  Wei Liu 

jobs:
 build-amd64  pass
 build-arm64  fail
 build-armhf  pass
 build-amd64-libvirt  pass
 build-arm64-pvopsfail
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  broken  
 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=adc017b80b18af63de7da077ed3382acef1222ec
+ . ./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 
adc017b80b18af63de7da077ed3382acef1222ec
+ branch=xen-unstable-smoke
+ revision=adc017b80b18af63de7da077ed3382acef1222ec
+ . ./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.8-testing
+ '[' xadc017b80b18af63de7da077ed3382acef1222ec = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/h

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl   6 xen-boot fail REGR. vs. 105685
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail 
REGR. vs. 105685

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 105685
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 105685
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 105685
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 105685
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 105685
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 105685
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 105685

Tests which did not succeed, but are not blocking:
 test-xtf-amd64-amd64-4   62 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-2   62 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-1   62 xtf/test-pv32pae-xsa-194 fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-3   62 xtf/test-pv32pae-xsa-194 fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-5   62 xtf/test-pv32pae-xsa-194 fail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-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-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-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-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass

version targeted for testing:
 xen  8e04cb25d9634995fe9b37d05c63cdb4ce8c205e
baseline version:
 xen  576f319a804bce8c9a7fb70a042f873f5eaf0151

Last test of basis   105685  2017-02-10 06:38:10 Z5 days
Testing same since   105816  2017-02-15 12:43:23 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 
  Julien Grall 
  Oleksandr Tyshchenko 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64-xtf  pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvops  

Re: [Xen-devel] [PATCH v3 2/2] x86/kvm: Provide optimized version of vcpu_is_preempted() for x86-64

[kbuild test robot]

Hi Waiman,

[auto build test ERROR on kvm/linux-next]
[also build test ERROR on v4.10-rc8 next-20170215]
[cannot apply to tip/x86/core]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Waiman-Long/x86-kvm-Reduce-vcpu_is_preempted-overhead/20170216-033517
base:   https://git.kernel.org/pub/scm/virt/kvm/kvm.git linux-next
config: i386-randconfig-h1-02160052 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All error/warnings (new ones prefixed by >>):

   In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/uapi/linux/capability.h:16,
from include/linux/capability.h:15,
from include/linux/sched.h:15,
from include/linux/context_tracking.h:4,
from arch/x86/kernel/kvm.c:23:
   arch/x86/kernel/kvm.c: In function 'kvm_spinlock_init':
>> arch/x86/kernel/kvm.c:631:6: error: 'PREEMPTED_OFFSET' undeclared (first use 
>> in this function)
  != PREEMPTED_OFFSET) || (sizeof(steal_time.preempted) != 1));
 ^
   include/linux/compiler.h:498:19: note: in definition of macro 
'__compiletime_assert'
  bool __cond = !(condition);\
  ^
   include/linux/compiler.h:518:2: note: in expansion of macro 
'_compiletime_assert'
 _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
 ^~~
   include/linux/bug.h:54:37: note: in expansion of macro 'compiletime_assert'
#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
^~
   include/linux/bug.h:78:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
 BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
 ^~~~
>> arch/x86/kernel/kvm.c:630:2: note: in expansion of macro 'BUILD_BUG_ON'
 BUILD_BUG_ON((offsetof(struct kvm_steal_time, preempted)
 ^~~~
   arch/x86/kernel/kvm.c:631:6: note: each undeclared identifier is reported 
only once for each function it appears in
  != PREEMPTED_OFFSET) || (sizeof(steal_time.preempted) != 1));
 ^
   include/linux/compiler.h:498:19: note: in definition of macro 
'__compiletime_assert'
  bool __cond = !(condition);\
  ^
   include/linux/compiler.h:518:2: note: in expansion of macro 
'_compiletime_assert'
 _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
 ^~~
   include/linux/bug.h:54:37: note: in expansion of macro 'compiletime_assert'
#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
^~
   include/linux/bug.h:78:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
 BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
 ^~~~
>> arch/x86/kernel/kvm.c:630:2: note: in expansion of macro 'BUILD_BUG_ON'
 BUILD_BUG_ON((offsetof(struct kvm_steal_time, preempted)
 ^~~~

vim +/PREEMPTED_OFFSET +631 arch/x86/kernel/kvm.c

   624  
   625  /*
   626   * Setup pv_lock_ops to exploit KVM_FEATURE_PV_UNHALT if present.
   627   */
   628  void __init kvm_spinlock_init(void)
   629  {
 > 630  BUILD_BUG_ON((offsetof(struct kvm_steal_time, preempted)
 > 631  != PREEMPTED_OFFSET) || (sizeof(steal_time.preempted) 
 > != 1));
   632  
   633  if (!kvm_para_available())
   634  return;

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 15/28] ARM: vGICv3: introduce basic ITS emulation bits

[Shanker Donthineni]

Hi Andre


On 01/30/2017 12:31 PM, Andre Przywara wrote:

Create a new file to hold the emulation code for the ITS widget.
For now we emulate the memory mapped ITS registers and provide a stub
to introduce the ITS command handling framework (but without actually
emulating any commands at this time).

Signed-off-by: Andre Przywara 
---
  xen/arch/arm/Makefile |   1 +
  xen/arch/arm/vgic-v3-its.c| 485
++
  xen/arch/arm/vgic-v3.c|   9 -
  xen/include/asm-arm/gic_v3_defs.h |  19 ++
  4 files changed, 505 insertions(+), 9 deletions(-)
  create mode 100644 xen/arch/arm/vgic-v3-its.c

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 4ccf2eb..a1cbc27 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -46,6 +46,7 @@ obj-y += traps.o
  obj-y += vgic.o
  obj-y += vgic-v2.o
  obj-$(CONFIG_HAS_GICV3) += vgic-v3.o
+obj-$(CONFIG_HAS_ITS) += vgic-v3-its.o
  obj-y += vm_event.o
  obj-y += vtimer.o
  obj-y += vpsci.o
diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
new file mode 100644
index 000..fc28376
--- /dev/null
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -0,0 +1,485 @@
+/*
+ * xen/arch/arm/vgic-v3-its.c
+ *
+ * ARM Interrupt Translation Service (ITS) emulation
+ *
+ * Andre Przywara 
+ * Copyright (c) 2016 ARM Ltd.
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Data structure to describe a virtual ITS */
+struct virt_its {
+struct domain *d;
+spinlock_t vcmd_lock;   /* protects the virtual command buffer */
+uint64_t cbaser;
+uint64_t *cmdbuf;
+int cwriter;
+int creadr;
+spinlock_t its_lock;/* protects the collection and device
tables */
+uint64_t baser0, baser1;
+uint16_t *coll_table;
+int max_collections;
+uint64_t *dev_table;
+int max_devices;
+bool enabled;
+};
+
+/*
+ * An Interrupt Translation Table Entry: this is indexed by a
+ * DeviceID/EventID pair and is located in guest memory.
+ */
+struct vits_itte
+{
+uint32_t vlpi;
+uint16_t collection;
+};
+
+/**
+ * Functions that handle ITS commands *
+ **/
+
+static uint64_t its_cmd_mask_field(uint64_t *its_cmd,
+   int word, int shift, int size)
+{
+return (le64_to_cpu(its_cmd[word]) >> shift) & (BIT(size) - 1);
+}
+
+#define its_cmd_get_command(cmd)its_cmd_mask_field(cmd, 0,  0,  8)
+#define its_cmd_get_deviceid(cmd)   its_cmd_mask_field(cmd, 0, 32, 32)
+#define its_cmd_get_size(cmd)   its_cmd_mask_field(cmd, 1,  0,  5)
+#define its_cmd_get_id(cmd) its_cmd_mask_field(cmd, 1,  0, 32)
+#define its_cmd_get_physical_id(cmd)its_cmd_mask_field(cmd, 1, 32, 32)
+#define its_cmd_get_collection(cmd) its_cmd_mask_field(cmd, 2,  0, 16)
+#define its_cmd_get_target_addr(cmd)its_cmd_mask_field(cmd, 2, 16, 32)
+#define its_cmd_get_validbit(cmd)   its_cmd_mask_field(cmd, 2, 63,  1)
+
+#define ITS_CMD_BUFFER_SIZE(baser)  baser) & 0xff) + 1) << 12)
+
+static int vgic_its_handle_cmds(struct domain *d, struct virt_its *its,
+uint32_t writer)
+{
+uint64_t *cmdptr;
+
+if ( !its->cmdbuf )
+return -1;
+
+if ( writer >= ITS_CMD_BUFFER_SIZE(its->cbaser) )
+return -1;
+
+spin_lock(&its->vcmd_lock);
+
+while ( its->creadr != writer )
+{
+cmdptr = its->cmdbuf + (its->creadr / sizeof(*its->cmdbuf));
+switch (its_cmd_get_command(cmdptr))
+{
+case GITS_CMD_SYNC:
+/* We handle ITS commands synchronously, so we ignore SYNC. */
+   break;
+default:
+gdprintk(XENLOG_G_WARNING, "ITS: unhandled ITS command %ld\n",
+   its_cmd_get_command(cmdptr));
+break;
+}
+
+its->creadr += ITS_CMD_SIZE;
+if ( its->creadr == ITS_CMD_BUFFER_SIZE(its->cbaser) )
+its->creadr = 0;
+}
+its->cwriter = writer;
+
+spin_unlock(&its->vcmd_lock);
+
+return 0;
+}
+
+/*
+ * ITS registers read access *
+ */
+
+/*
+ * The physical address is encoded slightly differently depending on
+ * the used page size: the highest four bits are stored in the lowest
+ * four bits of the fiel

[Xen-devel] [PATCH] arm/hypercall: Use the common hcall_preempted boolean

[Andrew Cooper]

With hcall_preempted having just been made common, ARM can use use it to
simplify its hypercall handling.

This simplifies the continuation logic and removes the risk of accidentally
skipping multiple instructions.

Signed-off-by: Andrew Cooper 
---
CC: Stefano Stabellini 
CC: Julien Grall 

NB: Only compile tested, not functionally tested.  However, it is basically an
identical transformation as done to x86 PV guests in the previous patch, which
I have tested thoroughly.
---
 xen/arch/arm/domain.c | 10 ++
 xen/arch/arm/traps.c  | 16 
 2 files changed, 10 insertions(+), 16 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 7e43691..fb1d8a5 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -349,17 +349,12 @@ void sync_vcpu_execstate(struct vcpu *v)
 
 void hypercall_cancel_continuation(void)
 {
-struct cpu_user_regs *regs = guest_cpu_user_regs();
 struct mc_state *mcs = ¤t->mc_state;
 
 if ( mcs->flags & MCSF_in_multicall )
-{
 __clear_bit(_MCSF_call_preempted, &mcs->flags);
-}
 else
-{
-regs->pc += 4; /* undo re-execute 'hvc #XEN_HYPERCALL_TAG' */
-}
+current->hcall_preempted = false;
 }
 
 unsigned long hypercall_create_continuation(
@@ -391,8 +386,7 @@ unsigned long hypercall_create_continuation(
 {
 regs = guest_cpu_user_regs();
 
-/* Ensure the hypercall trap instruction is re-executed. */
-regs->pc -= 4;  /* re-execute 'hvc #XEN_HYPERCALL_TAG' */
+current->hcall_preempted = true;
 
 #ifdef CONFIG_ARM_64
 if ( !is_32bit_domain(current->domain) )
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 92b1d80..7c99dc2 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1454,9 +1454,6 @@ static void do_trap_hypercall(struct cpu_user_regs *regs, 
register_t *nr,
   unsigned long iss)
 {
 arm_hypercall_fn_t call = NULL;
-#ifndef NDEBUG
-register_t orig_pc = regs->pc;
-#endif
 
 BUILD_BUG_ON(NR_hypercalls < ARRAY_SIZE(arm_hypercall_table) );
 
@@ -1470,6 +1467,8 @@ static void do_trap_hypercall(struct cpu_user_regs *regs, 
register_t *nr,
 return;
 }
 
+current->hcall_preempted = false;
+
 perfc_incra(hypercalls, *nr);
 call = arm_hypercall_table[*nr].fn;
 if ( call == NULL )
@@ -1481,12 +1480,9 @@ static void do_trap_hypercall(struct cpu_user_regs 
*regs, register_t *nr,
 HYPERCALL_RESULT_REG(regs) = call(HYPERCALL_ARGS(regs));
 
 #ifndef NDEBUG
-/*
- * Clobber argument registers only if pc is unchanged, otherwise
- * this is a hypercall continuation.
- */
-if ( orig_pc == regs->pc )
+if ( !current->hcall_preempted )
 {
+/* Deliberately corrupt parameter regs used by this hypercall. */
 switch ( arm_hypercall_table[*nr].nr_args ) {
 case 5: HYPERCALL_ARG5(regs) = 0xDEADBEEF;
 case 4: HYPERCALL_ARG4(regs) = 0xDEADBEEF;
@@ -1499,6 +1495,10 @@ static void do_trap_hypercall(struct cpu_user_regs 
*regs, register_t *nr,
 *nr = 0xDEADBEEF;
 }
 #endif
+
+/* Ensure the hypercall trap instruction is re-executed. */
+if ( current->hcall_preempted )
+regs->pc -= 4;  /* re-execute 'hvc #XEN_HYPERCALL_TAG' */
 }
 
 static bool check_multicall_32bit_clean(struct multicall_entry *multi)
-- 
2.1.4


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

[Xen-devel] [PATCH] x86/hypercall: Make the HVM hcall_preempted boolean common

[Andrew Cooper]

HVM guests currently make use of arch.hvm_vcpu.hcall_preempted to track
hypercall preemption in struct vcpu.  Move this boolean to being common at the
top level of struct vcpu, which will allow it to be reused elsewhere.

Alter the PV preemption logic to use this boolean.  This simplifies the code
by removing guest-type-specific knowledge, and removes the risk of accidently
skipping backwards or forwards multiple times and corrupting %rip.

In pv_hypercall() the old_rip bodge can be removed, and parameter clobbering
can happen based on a more obvious condition.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
---
 xen/arch/x86/domain.c  | 16 ++--
 xen/arch/x86/hvm/hypercall.c   |  8 
 xen/arch/x86/hypercall.c   | 17 -
 xen/include/asm-x86/hvm/vcpu.h |  1 -
 xen/include/xen/sched.h|  2 ++
 5 files changed, 20 insertions(+), 24 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 71c0e3c..b199c70 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -2198,20 +2198,12 @@ void sync_vcpu_execstate(struct vcpu *v)
 
 void hypercall_cancel_continuation(void)
 {
-struct cpu_user_regs *regs = guest_cpu_user_regs();
 struct mc_state *mcs = ¤t->mc_state;
 
 if ( mcs->flags & MCSF_in_multicall )
-{
 __clear_bit(_MCSF_call_preempted, &mcs->flags);
-}
 else
-{
-if ( is_pv_vcpu(current) )
-regs->rip += 2; /* skip re-execute 'syscall' / 'int $xx' */
-else
-current->arch.hvm_vcpu.hcall_preempted = 0;
-}
+current->hcall_preempted = false;
 }
 
 unsigned long hypercall_create_continuation(
@@ -2239,11 +2231,7 @@ unsigned long hypercall_create_continuation(
 
 regs->rax = op;
 
-/* Ensure the hypercall trap instruction is re-executed. */
-if ( is_pv_vcpu(curr) )
-regs->rip -= 2;  /* re-execute 'syscall' / 'int $xx' */
-else
-curr->arch.hvm_vcpu.hcall_preempted = 1;
+curr->hcall_preempted = true;
 
 if ( is_pv_vcpu(curr) ?
  !is_pv_32bit_vcpu(curr) :
diff --git a/xen/arch/x86/hvm/hypercall.c b/xen/arch/x86/hvm/hypercall.c
index 5dbd54a..fe7802b 100644
--- a/xen/arch/x86/hvm/hypercall.c
+++ b/xen/arch/x86/hvm/hypercall.c
@@ -176,7 +176,7 @@ int hvm_hypercall(struct cpu_user_regs *regs)
 return HVM_HCALL_completed;
 }
 
-curr->arch.hvm_vcpu.hcall_preempted = 0;
+curr->hcall_preempted = false;
 
 if ( mode == 8 )
 {
@@ -210,7 +210,7 @@ int hvm_hypercall(struct cpu_user_regs *regs)
 curr->arch.hvm_vcpu.hcall_64bit = 0;
 
 #ifndef NDEBUG
-if ( !curr->arch.hvm_vcpu.hcall_preempted )
+if ( !curr->hcall_preempted )
 {
 /* Deliberately corrupt parameter regs used by this hypercall. */
 switch ( hypercall_args_table[eax].native )
@@ -254,7 +254,7 @@ int hvm_hypercall(struct cpu_user_regs *regs)
 ebp);
 
 #ifndef NDEBUG
-if ( !curr->arch.hvm_vcpu.hcall_preempted )
+if ( !curr->hcall_preempted )
 {
 /* Deliberately corrupt parameter regs used by this hypercall. */
 switch ( hypercall_args_table[eax].compat )
@@ -272,7 +272,7 @@ int hvm_hypercall(struct cpu_user_regs *regs)
 
 HVM_DBG_LOG(DBG_LEVEL_HCALL, "hcall%lu -> %lx", eax, regs->rax);
 
-if ( curr->arch.hvm_vcpu.hcall_preempted )
+if ( curr->hcall_preempted )
 return HVM_HCALL_preempted;
 
 if ( unlikely(currd->arch.hvm_domain.qemu_mapcache_invalidate) &&
diff --git a/xen/arch/x86/hypercall.c b/xen/arch/x86/hypercall.c
index 8dd19de..945afa0 100644
--- a/xen/arch/x86/hypercall.c
+++ b/xen/arch/x86/hypercall.c
@@ -141,9 +141,6 @@ static const hypercall_table_t pv_hypercall_table[] = {
 void pv_hypercall(struct cpu_user_regs *regs)
 {
 struct vcpu *curr = current;
-#ifndef NDEBUG
-unsigned long old_rip = regs->rip;
-#endif
 unsigned long eax;
 
 ASSERT(guest_kernel_mode(curr, regs));
@@ -160,6 +157,8 @@ void pv_hypercall(struct cpu_user_regs *regs)
 return;
 }
 
+curr->hcall_preempted = false;
+
 if ( !is_pv_32bit_vcpu(curr) )
 {
 unsigned long rdi = regs->rdi;
@@ -191,7 +190,7 @@ void pv_hypercall(struct cpu_user_regs *regs)
 regs->rax = pv_hypercall_table[eax].native(rdi, rsi, rdx, r10, r8, r9);
 
 #ifndef NDEBUG
-if ( regs->rip == old_rip )
+if ( !curr->hcall_preempted )
 {
 /* Deliberately corrupt parameter regs used by this hypercall. */
 switch ( hypercall_args_table[eax].native )
@@ -238,7 +237,7 @@ void pv_hypercall(struct cpu_user_regs *regs)
 regs->_eax = pv_hypercall_table[eax].compat(ebx, ecx, edx, esi, edi, 
ebp);
 
 #ifndef NDEBUG
-if ( regs->rip == old_rip )
+if ( !curr->hcall_preempted )
 {
 /* Deliberately corrupt parameter regs used by this hypercall. */

Re: [Xen-devel] STAO spec in xen.git

[Stefano Stabellini]

On Wed, 15 Feb 2017, Olaf Hering wrote:
> Am Tue, 14 Feb 2017 20:27:15 +
> schrieb Wei Liu :
> 
> > Better to just push to a branch for us to fetch.
> 
> That would be git://github.com/olafhering/xen.git#libreoffice
> 
> https://github.com/olafhering/xen/commits/libreoffice
> 

Thanks, pulled

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

[Xen-devel] [PATCH] x86/hypercall: Split out PV hypercall infrastructure

[Andrew Cooper]

Repurpose arch/x86/hypercall.c to be common x86 hypercall infrastructure, and
move the PV specific routines to arch/x86/pv/hypercall.c

This is purely code motion.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
---
 xen/arch/x86/Makefile |   1 +
 xen/arch/x86/hypercall.c  | 226 +-
 xen/arch/x86/pv/Makefile  |   1 +
 xen/arch/x86/{ => pv}/hypercall.c |  59 +-
 4 files changed, 8 insertions(+), 279 deletions(-)
 create mode 100644 xen/arch/x86/pv/Makefile
 copy xen/arch/x86/{ => pv}/hypercall.c (84%)

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 007dced..10f519e 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -4,6 +4,7 @@ subdir-y += genapic
 subdir-y += hvm
 subdir-y += mm
 subdir-$(CONFIG_XENOPROF) += oprofile
+subdir-y += pv
 subdir-y += x86_64
 
 alternative-y := alternative.init.o
diff --git a/xen/arch/x86/hypercall.c b/xen/arch/x86/hypercall.c
index c0718f8..f807332 100644
--- a/xen/arch/x86/hypercall.c
+++ b/xen/arch/x86/hypercall.c
@@ -1,6 +1,8 @@
 /**
  * arch/x86/hypercall.c
  *
+ * Common x86 hypercall infrastructure.
+ *
  * 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
@@ -17,9 +19,7 @@
  * Copyright (c) 2015,2016 Citrix Systems Ltd.
  */
 
-#include 
 #include 
-#include 
 
 #define ARGS(x, n)  \
 [ __HYPERVISOR_ ## x ] = { n, n }
@@ -74,228 +74,6 @@ const hypercall_args_t hypercall_args_table[NR_hypercalls] =
 #undef COMP
 #undef ARGS
 
-#define HYPERCALL(x)\
-[ __HYPERVISOR_ ## x ] = { (hypercall_fn_t *) do_ ## x, \
-   (hypercall_fn_t *) do_ ## x }
-#define COMPAT_CALL(x)  \
-[ __HYPERVISOR_ ## x ] = { (hypercall_fn_t *) do_ ## x, \
-   (hypercall_fn_t *) compat_ ## x }
-
-#define do_arch_1 paging_domctl_continuation
-
-static const hypercall_table_t pv_hypercall_table[] = {
-COMPAT_CALL(set_trap_table),
-HYPERCALL(mmu_update),
-COMPAT_CALL(set_gdt),
-HYPERCALL(stack_switch),
-COMPAT_CALL(set_callbacks),
-HYPERCALL(fpu_taskswitch),
-HYPERCALL(sched_op_compat),
-COMPAT_CALL(platform_op),
-HYPERCALL(set_debugreg),
-HYPERCALL(get_debugreg),
-COMPAT_CALL(update_descriptor),
-COMPAT_CALL(memory_op),
-COMPAT_CALL(multicall),
-COMPAT_CALL(update_va_mapping),
-COMPAT_CALL(set_timer_op),
-HYPERCALL(event_channel_op_compat),
-COMPAT_CALL(xen_version),
-HYPERCALL(console_io),
-COMPAT_CALL(physdev_op_compat),
-COMPAT_CALL(grant_table_op),
-COMPAT_CALL(vm_assist),
-COMPAT_CALL(update_va_mapping_otherdomain),
-COMPAT_CALL(iret),
-COMPAT_CALL(vcpu_op),
-HYPERCALL(set_segment_base),
-COMPAT_CALL(mmuext_op),
-COMPAT_CALL(xsm_op),
-COMPAT_CALL(nmi_op),
-COMPAT_CALL(sched_op),
-COMPAT_CALL(callback_op),
-#ifdef CONFIG_XENOPROF
-COMPAT_CALL(xenoprof_op),
-#endif
-HYPERCALL(event_channel_op),
-COMPAT_CALL(physdev_op),
-HYPERCALL(hvm_op),
-HYPERCALL(sysctl),
-HYPERCALL(domctl),
-#ifdef CONFIG_KEXEC
-COMPAT_CALL(kexec_op),
-#endif
-#ifdef CONFIG_TMEM
-HYPERCALL(tmem_op),
-#endif
-HYPERCALL(xenpmu_op),
-COMPAT_CALL(dm_op),
-HYPERCALL(mca),
-HYPERCALL(arch_1),
-};
-
-#undef do_arch_1
-#undef COMPAT_CALL
-#undef HYPERCALL
-
-void pv_hypercall(struct cpu_user_regs *regs)
-{
-struct vcpu *curr = current;
-unsigned long eax;
-
-ASSERT(guest_kernel_mode(curr, regs));
-
-eax = is_pv_32bit_vcpu(curr) ? regs->_eax : regs->rax;
-
-BUILD_BUG_ON(ARRAY_SIZE(pv_hypercall_table) >
- ARRAY_SIZE(hypercall_args_table));
-
-if ( (eax >= ARRAY_SIZE(pv_hypercall_table)) ||
- !pv_hypercall_table[eax].native )
-{
-regs->rax = -ENOSYS;
-return;
-}
-
-curr->hcall_preempted = false;
-
-if ( !is_pv_32bit_vcpu(curr) )
-{
-unsigned long rdi = regs->rdi;
-unsigned long rsi = regs->rsi;
-unsigned long rdx = regs->rdx;
-unsigned long r10 = regs->r10;
-unsigned long r8 = regs->r8;
-unsigned long r9 = regs->r9;
-
-#ifndef NDEBUG
-/* Deliberately corrupt parameter regs not used by this hypercall. */
-switch ( hypercall_args_table[eax].native )
-{
-case 0: rdi = 0xdeadbeefdeadf00dUL;
-case 1: rsi = 0xdeadbeefdeadf00dUL;
-case 2: rdx = 0xdeadbeefdeadf00dUL;
-case 3: r10 = 0xdeadbeefdeadf00dUL;
-case 4: r8 = 0xdeadbeefdeadf00dUL;
-case 5: r9 = 0xdeadbeefdeadf00dUL;
-}
-#endif
-if ( unlikely(tb_init_done) )
-  

[Xen-devel] [PATCH] [RFC] x86/kconfig: Introduce CONFIG_PV and CONFIG_HVM

[Andrew Cooper]

Making PV and HVM guests individually compilable is useful as a reduction in
hypervisor size, and as an aid to enforcing clean API boundaries.

Introduce CONFIG_PV and CONFIG_HVM, although there is a lot of work to do
until either can actually be disabled.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
---
 xen/arch/x86/Kconfig   | 68 --
 xen/arch/x86/Makefile  |  4 +--
 xen/tools/kconfig/allrandom.config |  4 +++
 3 files changed, 56 insertions(+), 20 deletions(-)

diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 96ca2bf..87b03f3 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -32,6 +32,56 @@ menu "Architecture Features"
 
 source "arch/Kconfig"
 
+config PV
+   def_bool y
+   prompt "PV guest support" if EXPERT = "y"
+   depends on X86
+   ---help---
+ Support for Xen Paravirtual guests.
+
+ Xen PV guests use Ring Deprivileging as a method of virtualisation.
+ This requires no specific hardware support, but does require an OS
+ capable of running PV under Xen.
+
+ If unsure, say Y.
+
+ TODO: This is a work in process, and Xen doesn't currently compile
+ if this option is disabled.
+
+config HVM
+   def_bool y
+   prompt "HVM guest support" if EXPERT = "y"
+   depends on X86
+   ---help---
+ Support for Xen Hardware Virtual Machine guests.
+
+ Xen HVM guests use hardware virtualisation extentions (Intel VT-x,
+ AMD SVM) to run OSes.  This requires a CPU with appropriate
+ extentions, but can in principle run any OS, even if unmodified.
+
+ If unsure, say Y.
+
+ TODO: This is a work in process, and Xen doesn't currently compile
+ if this option is disabled.
+
+config HVM_FEP
+   bool "HVM Forced Emulation Prefix support" if EXPERT = "y"
+   default DEBUG
+   depends on HVM
+   ---help---
+ Compiles in a feature that allows HVM guest to arbitrarily
+ exercise the instruction emulator.
+
+ This feature can only be enabled during boot time with
+ appropriate hypervisor command line option. Please read
+ hypervisor command line documentation before trying to use
+ this feature.
+
+ This is strictly for testing purposes, and not appropriate
+ for use in production.
+
+ If unsure, say N.
+
 config SHADOW_PAGING
 bool "Shadow Paging"
 default y
@@ -61,24 +111,6 @@ config BIGMEM
 
  If unsure, say N.
 
-config HVM_FEP
-   bool "HVM Forced Emulation Prefix support" if EXPERT = "y"
-   default DEBUG
-   ---help---
-
- Compiles in a feature that allows HVM guest to arbitrarily
- exercise the instruction emulator.
-
- This feature can only be enabled during boot time with
- appropriate hypervisor command line option. Please read
- hypervisor command line documentation before trying to use
- this feature.
-
- This is strictly for testing purposes, and not appropriate
- for use in production.
-
- If unsure, say N.
-
 config TBOOT
def_bool y
prompt "Xen tboot support" if EXPERT = "y"
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 10f519e..d7c8970 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -1,10 +1,10 @@
 subdir-y += acpi
 subdir-y += cpu
 subdir-y += genapic
-subdir-y += hvm
+subdir-$(CONFIG_HVM) += hvm
 subdir-y += mm
 subdir-$(CONFIG_XENOPROF) += oprofile
-subdir-y += pv
+subdir-$(CONFIG_PV) += pv
 subdir-y += x86_64
 
 alternative-y := alternative.init.o
diff --git a/xen/tools/kconfig/allrandom.config 
b/xen/tools/kconfig/allrandom.config
index c7753ac..329ef59 100644
--- a/xen/tools/kconfig/allrandom.config
+++ b/xen/tools/kconfig/allrandom.config
@@ -1,3 +1,7 @@
 # Explicit option choices not subject to regular RANDCONFIG
 
 CONFIG_GCOV_FORMAT_AUTODETECT=y
+
+# Being able to compile-out guest subsystems is a work-in-progress.
+CONFIG_PV=y
+CONFIG_HVM=y
-- 
2.1.4


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

[Xen-devel] [PATCH] x86/hypercall: Make the HVM hcall_64bit boolean common

[Andrew Cooper]

HVM guests currently make use of arch.hvm_vcpu.hcall_64bit to track the ABI of
the hypercall in use.

The rest of Xen deals in terms of the comat ABI or not, so rename the boolean
and make it common, guared by CONFIG_COMPAT to avoid bloat if a compat ABI is
not wanted/needed.

Set hcall_compat uniformly for PV guests as well as HVM guests.  This removes
the remaining piece of guest-type-specific knowledge from
hypercall_create_continuation(), allowing it to operate only in terms of the
hypercall ABI in use.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
---
 xen/arch/x86/domain.c  |  4 +---
 xen/arch/x86/hvm/hvm.c |  9 +++--
 xen/arch/x86/hvm/hypercall.c   | 11 +--
 xen/arch/x86/hypercall.c   |  2 ++
 xen/include/asm-x86/hvm/vcpu.h |  2 --
 xen/include/xen/sched.h|  4 
 6 files changed, 15 insertions(+), 17 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 08c5813..3209eb3 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -2226,9 +2226,7 @@ unsigned long hypercall_create_continuation(
 
 regs->rax = op;
 
-if ( is_pv_vcpu(curr) ?
- !is_pv_32bit_vcpu(curr) :
- curr->arch.hvm_vcpu.hcall_64bit )
+if ( !curr->hcall_compat )
 {
 for ( i = 0; *p != '\0'; i++ )
 {
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 266f708..4d29e3c 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3254,8 +3254,7 @@ unsigned long copy_to_user_hvm(void *to, const void 
*from, unsigned int len)
 {
 int rc;
 
-if ( !current->arch.hvm_vcpu.hcall_64bit &&
- is_compat_arg_xlat_range(to, len) )
+if ( current->hcall_compat && is_compat_arg_xlat_range(to, len) )
 {
 memcpy(to, from, len);
 return 0;
@@ -3269,8 +3268,7 @@ unsigned long clear_user_hvm(void *to, unsigned int len)
 {
 int rc;
 
-if ( !current->arch.hvm_vcpu.hcall_64bit &&
- is_compat_arg_xlat_range(to, len) )
+if ( current->hcall_compat && is_compat_arg_xlat_range(to, len) )
 {
 memset(to, 0x00, len);
 return 0;
@@ -3284,8 +3282,7 @@ unsigned long copy_from_user_hvm(void *to, const void 
*from, unsigned len)
 {
 int rc;
 
-if ( !current->arch.hvm_vcpu.hcall_64bit &&
- is_compat_arg_xlat_range(from, len) )
+if ( current->hcall_compat && is_compat_arg_xlat_range(from, len) )
 {
 memcpy(to, from, len);
 return 0;
diff --git a/xen/arch/x86/hvm/hypercall.c b/xen/arch/x86/hvm/hypercall.c
index fe7802b..0f7c310 100644
--- a/xen/arch/x86/hvm/hypercall.c
+++ b/xen/arch/x86/hvm/hypercall.c
@@ -35,7 +35,7 @@ static long hvm_memory_op(int cmd, 
XEN_GUEST_HANDLE_PARAM(void) arg)
 return -ENOSYS;
 }
 
-if ( curr->arch.hvm_vcpu.hcall_64bit )
+if ( !curr->hcall_compat )
 rc = do_memory_op(cmd, arg);
 else
 rc = compat_memory_op(cmd, arg);
@@ -65,7 +65,7 @@ static long hvm_grant_table_op(
 return -ENOSYS;
 }
 
-if ( current->arch.hvm_vcpu.hcall_64bit )
+if ( !current->hcall_compat )
 return do_grant_table_op(cmd, uop, count);
 else
 return compat_grant_table_op(cmd, uop, count);
@@ -89,7 +89,7 @@ static long hvm_physdev_op(int cmd, 
XEN_GUEST_HANDLE_PARAM(void) arg)
 break;
 }
 
-if ( curr->arch.hvm_vcpu.hcall_64bit )
+if ( !curr->hcall_compat )
 return do_physdev_op(cmd, arg);
 else
 return compat_physdev_op(cmd, arg);
@@ -203,12 +203,9 @@ int hvm_hypercall(struct cpu_user_regs *regs)
 }
 #endif
 
-curr->arch.hvm_vcpu.hcall_64bit = 1;
 regs->rax = hvm_hypercall_table[eax].native(rdi, rsi, rdx, r10, r8,
 r9);
 
-curr->arch.hvm_vcpu.hcall_64bit = 0;
-
 #ifndef NDEBUG
 if ( !curr->hcall_preempted )
 {
@@ -250,8 +247,10 @@ int hvm_hypercall(struct cpu_user_regs *regs)
 }
 #endif
 
+curr->hcall_compat = true;
 regs->rax = hvm_hypercall_table[eax].compat(ebx, ecx, edx, esi, edi,
 ebp);
+curr->hcall_compat = false;
 
 #ifndef NDEBUG
 if ( !curr->hcall_preempted )
diff --git a/xen/arch/x86/hypercall.c b/xen/arch/x86/hypercall.c
index 945afa0..c0718f8 100644
--- a/xen/arch/x86/hypercall.c
+++ b/xen/arch/x86/hypercall.c
@@ -234,7 +234,9 @@ void pv_hypercall(struct cpu_user_regs *regs)
 __trace_hypercall(TRC_PV_HYPERCALL_V2, eax, args);
 }
 
+curr->hcall_compat = true;
 regs->_eax = pv_hypercall_table[eax].compat(ebx, ecx, edx, esi, edi, 
ebp);
+curr->hcall_compat = false;
 
 #ifndef NDEBUG
 if ( !curr->hcall_preempted )
diff --git a/xen/include/asm-x86/hvm/vcpu.h b/xen/include/asm-x86/hvm/vcpu.h
index 6d5553d..6c54773 100644
--- a/xen/include/asm-x86/hvm/vcpu.h
+++ b/xen/include/asm-x86/hvm/vcpu.h
@@ -166,8 +166,6 @@ struct

[Xen-devel] [PATCH] Common hypercall handing improvements

[Andrew Cooper]

This original purpose of this work was towards the RFC patch at the end of the
series, but there turned out to be a lot of cleanup opportunity in common and
ARM code as well.

Andrew Cooper (7):
  x86/hypercall: Make the HVM hcall_preempted boolean common
  arm/hypercall: Use the common hcall_preempted boolean
  xen/multicall: Use the common hcall_preempted boolean
  x86/hypercall: Make the HVM hcall_64bit boolean common
  x86/hypercall: Split out PV hypercall infrastructure
  x86/hypercall: Move hypercall continuation logic
  [RFC] x86/kconfig: Introduce CONFIG_PV and CONFIG_HVM

 xen/arch/arm/domain.c  |  19 +--
 xen/arch/arm/traps.c   |  16 +-
 xen/arch/x86/Kconfig   |  68 ++--
 xen/arch/x86/Makefile  |   3 +-
 xen/arch/x86/domain.c  | 198 --
 xen/arch/x86/hvm/hvm.c |   9 +-
 xen/arch/x86/hvm/hypercall.c   |  19 +--
 xen/arch/x86/hypercall.c   | 326 +
 xen/arch/x86/pv/Makefile   |   1 +
 xen/arch/x86/{ => pv}/hypercall.c  |  78 ++---
 xen/common/multicall.c |   4 +-
 xen/include/asm-x86/hvm/vcpu.h |   3 -
 xen/include/xen/multicall.h|   2 -
 xen/include/xen/sched.h|   6 +
 xen/tools/kconfig/allrandom.config |   4 +
 15 files changed, 252 insertions(+), 504 deletions(-)
 create mode 100644 xen/arch/x86/pv/Makefile
 copy xen/arch/x86/{ => pv}/hypercall.c (82%)

-- 
2.1.4


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

[Xen-devel] [PATCH] xen/multicall: Use the common hcall_preempted boolean

[Andrew Cooper]

The now-common hcall_preempted boolean is perfectly usable for multicalls.
Remove the multicall-specific preemption mechanism.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Stefano Stabellini 
CC: Julien Grall 
---
 xen/arch/arm/domain.c   | 13 +++--
 xen/arch/x86/domain.c   | 19 ++-
 xen/common/multicall.c  |  4 +++-
 xen/include/xen/multicall.h |  2 --
 4 files changed, 12 insertions(+), 26 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index fb1d8a5..39b6eb8 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -349,12 +349,7 @@ void sync_vcpu_execstate(struct vcpu *v)
 
 void hypercall_cancel_continuation(void)
 {
-struct mc_state *mcs = ¤t->mc_state;
-
-if ( mcs->flags & MCSF_in_multicall )
-__clear_bit(_MCSF_call_preempted, &mcs->flags);
-else
-current->hcall_preempted = false;
+current->hcall_preempted = false;
 }
 
 unsigned long hypercall_create_continuation(
@@ -370,12 +365,12 @@ unsigned long hypercall_create_continuation(
 /* All hypercalls take at least one argument */
 BUG_ON( !p || *p == '\0' );
 
+current->hcall_preempted = true;
+
 va_start(args, format);
 
 if ( mcs->flags & MCSF_in_multicall )
 {
-__set_bit(_MCSF_call_preempted, &mcs->flags);
-
 for ( i = 0; *p != '\0'; i++ )
 mcs->call.args[i] = next_arg(p, args);
 
@@ -386,8 +381,6 @@ unsigned long hypercall_create_continuation(
 {
 regs = guest_cpu_user_regs();
 
-current->hcall_preempted = true;
-
 #ifdef CONFIG_ARM_64
 if ( !is_32bit_domain(current->domain) )
 {
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index b199c70..08c5813 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -2198,41 +2198,34 @@ void sync_vcpu_execstate(struct vcpu *v)
 
 void hypercall_cancel_continuation(void)
 {
-struct mc_state *mcs = ¤t->mc_state;
-
-if ( mcs->flags & MCSF_in_multicall )
-__clear_bit(_MCSF_call_preempted, &mcs->flags);
-else
-current->hcall_preempted = false;
+current->hcall_preempted = false;
 }
 
 unsigned long hypercall_create_continuation(
 unsigned int op, const char *format, ...)
 {
-struct mc_state *mcs = ¤t->mc_state;
+struct vcpu *curr = current;
+struct mc_state *mcs = &curr->mc_state;
 const char *p = format;
 unsigned long arg;
 unsigned int i;
 va_list args;
 
+curr->hcall_preempted = true;
+
 va_start(args, format);
 
 if ( mcs->flags & MCSF_in_multicall )
 {
-__set_bit(_MCSF_call_preempted, &mcs->flags);
-
 for ( i = 0; *p != '\0'; i++ )
 mcs->call.args[i] = next_arg(p, args);
 }
 else
 {
 struct cpu_user_regs *regs = guest_cpu_user_regs();
-struct vcpu *curr = current;
 
 regs->rax = op;
 
-curr->hcall_preempted = true;
-
 if ( is_pv_vcpu(curr) ?
  !is_pv_32bit_vcpu(curr) :
  curr->arch.hvm_vcpu.hcall_64bit )
@@ -2293,7 +2286,7 @@ int hypercall_xlat_continuation(unsigned int *id, 
unsigned int nr,
 
 if ( mcs->flags & MCSF_in_multicall )
 {
-if ( !(mcs->flags & MCSF_call_preempted) )
+if ( !current->hcall_preempted )
 {
 va_end(args);
 return 0;
diff --git a/xen/common/multicall.c b/xen/common/multicall.c
index 524c9bf..02f57cb 100644
--- a/xen/common/multicall.c
+++ b/xen/common/multicall.c
@@ -79,7 +79,7 @@ do_multicall(
 
 if ( unlikely(__copy_field_to_guest(call_list, &mcs->call, result)) )
 rc = -EFAULT;
-else if ( mcs->flags & MCSF_call_preempted )
+else if ( current->hcall_preempted )
 {
 /* Translate sub-call continuation to guest layout */
 xlat_multicall_entry(mcs);
@@ -87,6 +87,8 @@ do_multicall(
 /* Copy the sub-call continuation. */
 if ( likely(!__copy_to_guest(call_list, &mcs->call, 1)) )
 goto preempted;
+else
+hypercall_cancel_continuation();
 rc = -EFAULT;
 }
 else
diff --git a/xen/include/xen/multicall.h b/xen/include/xen/multicall.h
index fff15eb..e8d7905 100644
--- a/xen/include/xen/multicall.h
+++ b/xen/include/xen/multicall.h
@@ -11,9 +11,7 @@
 #endif
 
 #define _MCSF_in_multicall   0
-#define _MCSF_call_preempted 1
 #define MCSF_in_multicall(1<<_MCSF_in_multicall)
-#define MCSF_call_preempted  (1<<_MCSF_call_preempted)
 struct mc_state {
 unsigned long flags;
 union {
-- 
2.1.4


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

[Xen-devel] [PATCH] x86/hypercall: Move hypercall continuation logic

[Andrew Cooper]

The newly-repurposed arch/x86/hypercall.c is a more appropriate place for the
hypercall continuation logic to live.

This is purely code motion.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
---
 xen/arch/x86/domain.c| 177 ---
 xen/arch/x86/hypercall.c | 177 +++
 2 files changed, 177 insertions(+), 177 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 3209eb3..8d7cae3 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -2184,183 +2184,6 @@ void sync_vcpu_execstate(struct vcpu *v)
 flush_tlb_mask(v->vcpu_dirty_cpumask);
 }
 
-#define next_arg(fmt, args) ({  \
-unsigned long __arg;\
-switch ( *(fmt)++ ) \
-{   \
-case 'i': __arg = (unsigned long)va_arg(args, unsigned int);  break;\
-case 'l': __arg = (unsigned long)va_arg(args, unsigned long); break;\
-case 'h': __arg = (unsigned long)va_arg(args, void *);break;\
-default:  __arg = 0; BUG(); \
-}   \
-__arg;  \
-})
-
-void hypercall_cancel_continuation(void)
-{
-current->hcall_preempted = false;
-}
-
-unsigned long hypercall_create_continuation(
-unsigned int op, const char *format, ...)
-{
-struct vcpu *curr = current;
-struct mc_state *mcs = &curr->mc_state;
-const char *p = format;
-unsigned long arg;
-unsigned int i;
-va_list args;
-
-curr->hcall_preempted = true;
-
-va_start(args, format);
-
-if ( mcs->flags & MCSF_in_multicall )
-{
-for ( i = 0; *p != '\0'; i++ )
-mcs->call.args[i] = next_arg(p, args);
-}
-else
-{
-struct cpu_user_regs *regs = guest_cpu_user_regs();
-
-regs->rax = op;
-
-if ( !curr->hcall_compat )
-{
-for ( i = 0; *p != '\0'; i++ )
-{
-arg = next_arg(p, args);
-switch ( i )
-{
-case 0: regs->rdi = arg; break;
-case 1: regs->rsi = arg; break;
-case 2: regs->rdx = arg; break;
-case 3: regs->r10 = arg; break;
-case 4: regs->r8  = arg; break;
-case 5: regs->r9  = arg; break;
-}
-}
-}
-else
-{
-for ( i = 0; *p != '\0'; i++ )
-{
-arg = next_arg(p, args);
-switch ( i )
-{
-case 0: regs->rbx = arg; break;
-case 1: regs->rcx = arg; break;
-case 2: regs->rdx = arg; break;
-case 3: regs->rsi = arg; break;
-case 4: regs->rdi = arg; break;
-case 5: regs->rbp = arg; break;
-}
-}
-}
-}
-
-va_end(args);
-
-return op;
-}
-
-int hypercall_xlat_continuation(unsigned int *id, unsigned int nr,
-unsigned int mask, ...)
-{
-int rc = 0;
-struct mc_state *mcs = ¤t->mc_state;
-struct cpu_user_regs *regs;
-unsigned int i, cval = 0;
-unsigned long nval = 0;
-va_list args;
-
-ASSERT(nr <= ARRAY_SIZE(mcs->call.args));
-ASSERT(!(mask >> nr));
-ASSERT(!id || *id < nr);
-ASSERT(!id || !(mask & (1U << *id)));
-
-va_start(args, mask);
-
-if ( mcs->flags & MCSF_in_multicall )
-{
-if ( !current->hcall_preempted )
-{
-va_end(args);
-return 0;
-}
-
-for ( i = 0; i < nr; ++i, mask >>= 1 )
-{
-if ( mask & 1 )
-{
-nval = va_arg(args, unsigned long);
-cval = va_arg(args, unsigned int);
-if ( cval == nval )
-mask &= ~1U;
-else
-BUG_ON(nval == (unsigned int)nval);
-}
-else if ( id && *id == i )
-{
-*id = mcs->call.args[i];
-id = NULL;
-}
-if ( (mask & 1) && mcs->call.args[i] == nval )
-{
-mcs->call.args[i] = cval;
-++rc;
-}
-else
-BUG_ON(mcs->call.args[i] != (unsigned int)mcs->call.args[i]);
-}
-}
-else
-{
-regs = guest_cpu_user_regs();
-for ( i = 0; i < nr; ++i, mask >>= 1 )
-{
-unsigned long *reg;
-
-switch ( i )
-{
-case 0: reg = ®s->rbx; break;
-case 1: reg = ®s->rcx; break;
-case 2: reg = ®s->rdx; b

Re: [Xen-devel] Unable to boot Xen 4.8 with iommu=0

[Tamas K Lengyel]

On Wed, Feb 15, 2017 at 12:30 PM, Tamas K Lengyel
 wrote:
> On Wed, Feb 15, 2017 at 3:03 AM, Jan Beulich  wrote:
> On 15.02.17 at 00:21,  wrote:
>>> On 14/02/2017 22:47, Tamas K Lengyel wrote:
 (XEN) Switched to APIC driver x2apic_cluster.
 (XEN) XSM Framework v1.0.0 initialized
 (XEN) Flask: 128 avtab hash slots, 394 rules.
 (XEN) Flask: 128 avtab hash slots, 394 rules.
 (XEN) Flask:  5 users, 3 roles, 43 types, 2 bools
 (XEN) Flask:  12 classes, 394 rules
 (XEN) Flask:  Starting in enforcing mode.
 (XEN) xstate: size: 0x340 and states: 0x7
 (XEN) Intel machine check reporting enabled
 (XEN) Using scheduler: SMP Credit Scheduler (credit)
 (XEN) Platform timer is 14.318MHz HPET
 (XEN) Detected 3392.326 MHz processor.
 (XEN) Initing memory sharing.
 (XEN) alt table 82d0802d3f38 -> 82d0802d5564
 (XEN) PCI: MCFG configuration 0: base e000 segment  buses 00 - 3f
 (XEN) PCI: Not using MCFG for segment  bus 00-3f
 (XEN)
 (XEN) 
 (XEN) Panic on CPU 0:
 (XEN) Couldn't enable IOMMU and iommu=required/force
 (XEN) 
 (XEN)
 (XEN) Reboot in five seconds...
 (XEN) Resetting with ACPI MEMORY or I/O RESET_REG.

 As seen in the command line iommu is not set to required or forced.
 Yet Xen thinks it is set to required/force. Has anyone else run into
 this issue?
>>>
>>> This area is a rats nest :(
>>>
>>> The problem is that the APIC setup has chosen to use the x2apic_cluster
>>> driver, which in the Xen code depends on x2APIC, which depends on
>>> interrupt remapping, which depends on an IOMMU.
>>>
>>> (I could have sworn we fixed this before), but the bug is that the APIC
>>> setup shouldn't choose any of the x2apic modes if there isn't an
>>> interrupt remapping capable IOMMU.
>>
>> And from going over the code I can't see how this would happen,
>> so Tamas, it would be nice if you could add some verbosity to the
>> functions involved. In particular x2apic_bsp_setup() must be
>> getting success (zero) from iommu_enable_x2apic_IR(), yet that
>> function calls iommu_supports_eim(), which ought to produce
>> false through its very first exit path in your case.
>>
>> Or wait - do you have the same issue if you use
>> "iommu=no,no-intremap"? In which case the problem would be
>> that "iommu=no" should clear more than just "iommu_enable", or
>> code checking iommu_intremap early (before iommu_setup()
>> manages to clear it in the case here) would need to made look at
>> both variables. Oddly enough acpi_parse_dmar() only bails if
>> both variables are clear, which suggests to me that
>> iommu_enable is intended to have two different meanings in
>> different contexts (master flag vs. controlling just DMA
>> remapping). Kevin, Feng - any thoughts here?
>
> iommu=no,no-intremap boots fine with "(XEN) Using APIC driver default"

And just to clarify, x2apic is disabled in this case "(XEN) Not
enabling x2APIC: depends on iommu_supports_eim."

Tamas

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

Re: [Xen-devel] Unable to boot Xen 4.8 with iommu=0

[Tamas K Lengyel]

On Wed, Feb 15, 2017 at 3:03 AM, Jan Beulich  wrote:
 On 15.02.17 at 00:21,  wrote:
>> On 14/02/2017 22:47, Tamas K Lengyel wrote:
>>> (XEN) Switched to APIC driver x2apic_cluster.
>>> (XEN) XSM Framework v1.0.0 initialized
>>> (XEN) Flask: 128 avtab hash slots, 394 rules.
>>> (XEN) Flask: 128 avtab hash slots, 394 rules.
>>> (XEN) Flask:  5 users, 3 roles, 43 types, 2 bools
>>> (XEN) Flask:  12 classes, 394 rules
>>> (XEN) Flask:  Starting in enforcing mode.
>>> (XEN) xstate: size: 0x340 and states: 0x7
>>> (XEN) Intel machine check reporting enabled
>>> (XEN) Using scheduler: SMP Credit Scheduler (credit)
>>> (XEN) Platform timer is 14.318MHz HPET
>>> (XEN) Detected 3392.326 MHz processor.
>>> (XEN) Initing memory sharing.
>>> (XEN) alt table 82d0802d3f38 -> 82d0802d5564
>>> (XEN) PCI: MCFG configuration 0: base e000 segment  buses 00 - 3f
>>> (XEN) PCI: Not using MCFG for segment  bus 00-3f
>>> (XEN)
>>> (XEN) 
>>> (XEN) Panic on CPU 0:
>>> (XEN) Couldn't enable IOMMU and iommu=required/force
>>> (XEN) 
>>> (XEN)
>>> (XEN) Reboot in five seconds...
>>> (XEN) Resetting with ACPI MEMORY or I/O RESET_REG.
>>>
>>> As seen in the command line iommu is not set to required or forced.
>>> Yet Xen thinks it is set to required/force. Has anyone else run into
>>> this issue?
>>
>> This area is a rats nest :(
>>
>> The problem is that the APIC setup has chosen to use the x2apic_cluster
>> driver, which in the Xen code depends on x2APIC, which depends on
>> interrupt remapping, which depends on an IOMMU.
>>
>> (I could have sworn we fixed this before), but the bug is that the APIC
>> setup shouldn't choose any of the x2apic modes if there isn't an
>> interrupt remapping capable IOMMU.
>
> And from going over the code I can't see how this would happen,
> so Tamas, it would be nice if you could add some verbosity to the
> functions involved. In particular x2apic_bsp_setup() must be
> getting success (zero) from iommu_enable_x2apic_IR(), yet that
> function calls iommu_supports_eim(), which ought to produce
> false through its very first exit path in your case.
>
> Or wait - do you have the same issue if you use
> "iommu=no,no-intremap"? In which case the problem would be
> that "iommu=no" should clear more than just "iommu_enable", or
> code checking iommu_intremap early (before iommu_setup()
> manages to clear it in the case here) would need to made look at
> both variables. Oddly enough acpi_parse_dmar() only bails if
> both variables are clear, which suggests to me that
> iommu_enable is intended to have two different meanings in
> different contexts (master flag vs. controlling just DMA
> remapping). Kevin, Feng - any thoughts here?

iommu=no,no-intremap boots fine with "(XEN) Using APIC driver default"

Tamas

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

[Xen-devel] [xen-4.5-testing test] 105817: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs. 
104590

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail  like 104573
 test-amd64-amd64-xl-rtds  6 xen-boot fail  like 104590
 test-xtf-amd64-amd64-2   53 leak-check/check fail  like 104590
 test-xtf-amd64-amd64-3   53 leak-check/check fail  like 104590
 test-xtf-amd64-amd64-4   53 leak-check/check fail  like 104590
 test-xtf-amd64-amd64-5   53 leak-check/check fail  like 104590
 test-xtf-amd64-amd64-1   53 leak-check/check fail  like 104590
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 15 guest-localmigrate/x10 fail like 
104590
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 104590
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 104590
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 104590

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-2   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-2 30 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-2 36 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-2   40 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-4   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-4 30 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-5   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-1   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-4 36 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-4   40 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-5 30 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-1 30 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-5 36 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-1 36 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-5   40 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-1   40 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-2   52 xtf/test-hvm64-xsa-195   fail   never pass
 test-xtf-amd64-amd64-3   52 xtf/test-hvm64-xsa-195   fail   never pass
 test-xtf-amd64-amd64-4   52 xtf/test-hvm64-xsa-195   fail   never pass
 test-xtf-amd64-amd64-5   52 xtf/test-hvm64-xsa-195   fail   never pass
 test-xtf-amd64-amd64-1   52 xtf/test-hvm64-xsa-195   fail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  10 guest-start  fail   never pass
 test-armhf-armhf-libvirt-raw 10 guest-start  fail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  43d06efb724d32a70b1cc9973d7cdcbbb5d96105
baseline version:
 xen  2b17bf45470bf742d78a22116e3b7ec1a3213c45

Last test of basis   104590  2017-01-22 12:15:24 Z   24 days
Testing same since   105817  2017-02-15 12:43:12 Z0 days1 attempts

--

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

[Julien Grall]

Hi Andre,

On 30/01/17 18:31, Andre Przywara wrote:

Allow a guest to provide the address and size for the memory regions
it has reserved for the GICv3 pending and property tables.
We sanitise the various fields of the respective redistributor
registers and map those pages into Xen's address space to have easy
access.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic-v3.c   | 220 +++
 xen/arch/arm/vgic.c  |   4 +
 xen/include/asm-arm/domain.h |   8 +-
 xen/include/asm-arm/vgic.h   |  24 -
 4 files changed, 233 insertions(+), 23 deletions(-)

diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index b0653c2..c6db2d7 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -20,12 +20,14 @@

 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -229,12 +231,15 @@ static int __vgic_v3_rdistr_rd_mmio_read(struct vcpu *v, 
mmio_info_t *info,
 goto read_reserved;

 case VREG64(GICR_PROPBASER):
-/* LPI's not implemented */
-goto read_as_zero_64;
+if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
+*r = vgic_reg64_extract(v->domain->arch.vgic.rdist_propbase, info);
+return 1;

 case VREG64(GICR_PENDBASER):
-/* LPI's not implemented */
-goto read_as_zero_64;
+if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
+*r = vgic_reg64_extract(v->arch.vgic.rdist_pendbase, info);
+*r &= ~GICR_PENDBASER_PTZ;   /* WO, reads as 0 */
+return 1;

 case 0x0080:
 goto read_reserved;
@@ -302,11 +307,6 @@ bad_width:
 domain_crash_synchronous();
 return 0;

-read_as_zero_64:
-if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
-*r = 0;
-return 1;
-
 read_as_zero_32:
 if ( dabt.size != DABT_WORD ) goto bad_width;
 *r = 0;
@@ -331,11 +331,179 @@ read_unknown:
 return 1;
 }

+static uint64_t vgic_sanitise_field(uint64_t reg, uint64_t field_mask,
+int field_shift,
+uint64_t (*sanitise_fn)(uint64_t))
+{
+uint64_t field = (reg & field_mask) >> field_shift;
+
+field = sanitise_fn(field) << field_shift;
+
+return (reg & ~field_mask) | field;
+}
+
+/* We want to avoid outer shareable. */
+static uint64_t vgic_sanitise_shareability(uint64_t field)
+{
+switch (field) {


Coding style:

switch ( field )
{


+case GIC_BASER_OuterShareable:
+return GIC_BASER_InnerShareable;
+default:
+return field;
+}
+}
+
+/* Avoid any inner non-cacheable mapping. */
+static uint64_t vgic_sanitise_inner_cacheability(uint64_t field)
+{
+switch (field) {


Ditto


+case GIC_BASER_CACHE_nCnB:
+case GIC_BASER_CACHE_nC:
+return GIC_BASER_CACHE_RaWb;
+default:
+return field;
+}
+}
+
+/* Non-cacheable or same-as-inner are OK. */
+static uint64_t vgic_sanitise_outer_cacheability(uint64_t field)
+{
+switch (field) {


Ditto


+case GIC_BASER_CACHE_SameAsInner:
+case GIC_BASER_CACHE_nC:
+return field;
+default:
+return GIC_BASER_CACHE_nC;
+}
+}
+
+static uint64_t sanitize_propbaser(uint64_t reg)
+{
+reg = vgic_sanitise_field(reg, GICR_PROPBASER_SHAREABILITY_MASK,
+  GICR_PROPBASER_SHAREABILITY_SHIFT,
+  vgic_sanitise_shareability);
+reg = vgic_sanitise_field(reg, GICR_PROPBASER_INNER_CACHEABILITY_MASK,
+  GICR_PROPBASER_INNER_CACHEABILITY_SHIFT,
+  vgic_sanitise_inner_cacheability);
+reg = vgic_sanitise_field(reg, GICR_PROPBASER_OUTER_CACHEABILITY_MASK,
+  GICR_PROPBASER_OUTER_CACHEABILITY_SHIFT,
+  vgic_sanitise_outer_cacheability);
+
+reg &= ~GICR_PROPBASER_RES0_MASK;


Newline here please.


+return reg;
+}
+
+static uint64_t sanitize_pendbaser(uint64_t reg)
+{
+reg = vgic_sanitise_field(reg, GICR_PENDBASER_SHAREABILITY_MASK,
+  GICR_PENDBASER_SHAREABILITY_SHIFT,
+  vgic_sanitise_shareability);
+reg = vgic_sanitise_field(reg, GICR_PENDBASER_INNER_CACHEABILITY_MASK,
+  GICR_PENDBASER_INNER_CACHEABILITY_SHIFT,
+  vgic_sanitise_inner_cacheability);
+reg = vgic_sanitise_field(reg, GICR_PENDBASER_OUTER_CACHEABILITY_MASK,
+  GICR_PENDBASER_OUTER_CACHEABILITY_SHIFT,
+  vgic_sanitise_outer_cacheability);
+
+reg &= ~GICR_PENDBASER_RES0_MASK;


Newline here please.


+return reg;
+}
+
+/*
+ * Mark a given number of guest pages as used (by increasing their refcount),
+ * starting with the given guest address. This needs to be called once before
+ * calling (possibly repeatedly) map_guest_pages().
+ * Be

[Xen-devel] Network interface change notifications between an ethX and vif?

[Jeremy Bender]

I will apologize up front for my ignorance on the topic of 'Xen' since I
have just been thrown into it.  My task at hand is to make modifications to
the Linux kernel so that when the vif on one VHD connected to the
corresponding eth0 on another VHD goes down (ip link set vif1.0 down), eth0
appears to be down as well.

I have assigned a new common function to the function pointer
".ndo_change_carrier" of xennet_netdev_ops defined in xen-netfront.c which
simply either calls "netif_carrier_on(dev)" or "netif_carrier_off(dev)".
But my new function never gets called.

Whether or not I assign the same IP to eth0 and the vif or whether I use a
bridge makes no difference.

Any help would be appreciated.  Also, the documentation on
.ndo_change_carrier is a little terse, if someone could give me a little
more detail about when it is actually called would be great.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3] displif: add ABI for para-virtual display

[Oleksandr Andrushchenko]

On 02/15/2017 05:45 PM, Konrad Rzeszutek Wilk wrote:

On Wed, Feb 15, 2017 at 09:33:41AM +0200, Oleksandr Andrushchenko wrote:

On 02/14/2017 10:27 PM, Konrad Rzeszutek Wilk wrote:

On Mon, Feb 13, 2017 at 10:50:49AM +0200, Oleksandr Andrushchenko wrote:

Hi, Konrad!

Thank you for reviewing this.

On 02/10/2017 11:27 PM, Konrad Rzeszutek Wilk wrote:

On Fri, Feb 10, 2017 at 09:29:58AM +0200, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko 

This is the ABI for the two halves of a para-virtualized
display driver.

This protocol aims to provide a unified protocol which fits more
sophisticated use-cases than a framebuffer device can handle. At the
moment basic functionality is supported with the intention to extend:
 o multiple dynamically allocated/destroyed framebuffers
 o buffers of arbitrary sizes
 o better configuration options including multiple display support

Note: existing fbif can be used together with displif running at the
same time, e.g. on Linux one provides framebuffer and another DRM/KMS

Future extensions to the existing protocol may include:
 o allow display/connector cloning
 o allow allocating objects other than display buffers
 o add planes/overlays support
 o support scaling
 o support rotation

==
Rationale for introducing this protocol instead of
using the existing fbif:
==

1. In/out event sizes
 o fbif - 40 octets
 o displif - 40 octets
This is only the initial version of the displif protocol
which means that there could be requests which will not fit
(WRT introducing some GPU related functionality
later on). In that case we cannot alter fbif sizes as we need to
be backward compatible an will be forced to handle those
apart of fbif.

2. Shared page
Displif doesn't use anything like struct xenfb_page, but
DEFINE_RING_TYPES(xen_displif, struct xendispl_req, struct
xendispl_resp) which is a better and more common way.
Output events use a shared page which only has in_cons and in_prod
and all the rest is used for incoming events. Here struct xenfb_page
could probably be used as is despite the fact that it only has a half
of a page for incoming events which is only 50 events. (consider
something like 60Hz display)

3. Amount of changes.
fbif only provides XENFB_TYPE_UPDATE and XENFB_TYPE_RESIZE
events, so it looks like it is easier to get fb support into displif

.. would it make sense to reserve some of those values (2, 3)
in the XENDISPL_OP_ values? So that if this happens there is a nice
fit in there? Thought looking at the structure there is no easy
way to 'overlay' the xenfb_out_event structure as it is missing the 'id'.

I guess one can get creative.

Or you could swap positions of 'id' and 'type'? And then it would fit much
nicer?

yeap, in order no one needs to be creative, why not
explicitly define those?
Anyways, it won't be possible to simply lay the structures from
fbif on top of displif (different structure, size, workflow etc.),
what is more that would give some room to find workarounds, rather than
have well defined solution. BTW, there was an attempt [1] to update
fbdev to meet modern application needs. If we decide to add FBDEV
functionality into this protocol, then I can re-use already
proven to work solution from [1] into DISPLIF, but defining
structures and events to fit the current protocol.

I was thinking that since the size of the structure is 64bytes
you have enough space to jam in the old structures too.

yes, I understand your intention

Naturally the driver would need adjustments as it offsets
of where this goes are all wrong.

exactly

What do you think?

so, what is the decision? Options:
1) Leave the protocol as is, if need be it can be extended later
2) Implement something similar to [1]
3) Give room for workarounds and reserve XENDISPL_OP_XXX for
what current fbif uses

I would do 3) so that it becomes easier to migrate the old code over.

Ok, so I will reserve XENDISPL_OP_XXX to fit fbif, namely:
I'll put XENDISPL_OP_RESERVED{0|1...} for those used by fbif

than vice versa. displif at the moment has 6 requests and 1 event,
multiple connector support, etc.

Changes since v2:
* updated XenStore configuration template/pattern
* added "Recovery flow" to state diagram description
* renamed gref_directory_start to gref_directory
* added missing "versions" and "version" string constants

Changes since v1:
* fixed xendispl_event_page padding size
* added versioning support
* explicitly define value types for XenStore fields
* text decoration re-work
* added offsets to ASCII box notation

Changes since initial:
* DRM changed to DISPL, protocol made generic
* major re-work addressing issues raised for sndif

Signed-off-by: Oleksandr Grytsov 
Signed-off-by: Oleksandr Andrushchenko 
---
xen/include/public/io/displif.h | 778 

[Xen-devel] [PATCH v3 0/2] x86/kvm: Reduce vcpu_is_preempted() overhead

[Waiman Long]

 v2->v3:
  - Provide an optimized __raw_callee_save___kvm_vcpu_is_preempted()
in assembly as suggested by PeterZ.
  - Add a new patch to change vcpu_is_preempted() argument type to long
to ease the writing of the assembly code.

 v1->v2:
  - Rerun the fio test on a different system on both bare-metal and a
KVM guest. Both sockets were utilized in this test.
  - The commit log was updated with new performance numbers, but the
patch wasn't changed.
  - Drop patch 2.

As it was found that the overhead of callee-save vcpu_is_preempted()
can have some impact on system performance on a VM guest, especially
of x86-64 guest, this patch set intends to reduce this performance
overhead by replacing the C __kvm_vcpu_is_preempted() function by
an optimized version of __raw_callee_save___kvm_vcpu_is_preempted()
written in assembly.

Waiman Long (2):
  x86/paravirt: Change vcp_is_preempted() arg type to long
  x86/kvm: Provide optimized version of vcpu_is_preempted() for x86-64

 arch/x86/include/asm/paravirt.h  |  2 +-
 arch/x86/include/asm/qspinlock.h |  2 +-
 arch/x86/kernel/kvm.c| 30 +-
 arch/x86/kernel/paravirt-spinlocks.c |  2 +-
 4 files changed, 32 insertions(+), 4 deletions(-)

-- 
1.8.3.1


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

[Xen-devel] [PATCH v3 2/2] x86/kvm: Provide optimized version of vcpu_is_preempted() for x86-64

[Waiman Long]

It was found when running fio sequential write test with a XFS ramdisk
on a KVM guest running on a 2-socket x86-64 system, the %CPU times
as reported by perf were as follows:

 69.75%  0.59%  fio  [k] down_write
 69.15%  0.01%  fio  [k] call_rwsem_down_write_failed
 67.12%  1.12%  fio  [k] rwsem_down_write_failed
 63.48% 52.77%  fio  [k] osq_lock
  9.46%  7.88%  fio  [k] __raw_callee_save___kvm_vcpu_is_preempt
  3.93%  3.93%  fio  [k] __kvm_vcpu_is_preempted

Making vcpu_is_preempted() a callee-save function has a relatively
high cost on x86-64 primarily due to at least one more cacheline of
data access from the saving and restoring of registers (8 of them)
to and from stack as well as one more level of function call.

To reduce this performance overhead, an optimized assembly version
of the the __raw_callee_save___kvm_vcpu_is_preempt() function is
provided for x86-64.

With this patch applied on a KVM guest on a 2-socekt 16-core 32-thread
system with 16 parallel jobs (8 on each socket), the aggregrate
bandwidth of the fio test on an XFS ramdisk were as follows:

   I/O Type  w/o patchwith patch
     ---
   random read   8141.2 MB/s  8497.1 MB/s
   seq read  8229.4 MB/s  8304.2 MB/s
   random write  1675.5 MB/s  1701.5 MB/s
   seq write 1681.3 MB/s  1699.9 MB/s

There are some increases in the aggregated bandwidth because of
the patch.

The perf data now became:

 70.78%  0.58%  fio  [k] down_write
 70.20%  0.01%  fio  [k] call_rwsem_down_write_failed
 69.70%  1.17%  fio  [k] rwsem_down_write_failed
 59.91% 55.42%  fio  [k] osq_lock
 10.14% 10.14%  fio  [k] __kvm_vcpu_is_preempted

The assembly code was verified by using a test kernel module to
compare the output of C __kvm_vcpu_is_preempted() and that of assembly
__raw_callee_save___kvm_vcpu_is_preempt() to verify that they matched.

Suggested-by: Peter Zijlstra 
Signed-off-by: Waiman Long 
---
 arch/x86/kernel/kvm.c | 28 
 1 file changed, 28 insertions(+)

diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 85ed343..83e22c1 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -589,6 +589,7 @@ static void kvm_wait(u8 *ptr, u8 val)
local_irq_restore(flags);
 }
 
+#ifdef CONFIG_X86_32
 __visible bool __kvm_vcpu_is_preempted(long cpu)
 {
struct kvm_steal_time *src = &per_cpu(steal_time, cpu);
@@ -597,11 +598,38 @@ __visible bool __kvm_vcpu_is_preempted(long cpu)
 }
 PV_CALLEE_SAVE_REGS_THUNK(__kvm_vcpu_is_preempted);
 
+#else
+
+extern bool __raw_callee_save___kvm_vcpu_is_preempted(long);
+
+/*
+ * Hand-optimize version for x86-64 to avoid 8 64-bit register saving and
+ * restoring to/from the stack. It is assumed that the preempted value
+ * is at an offset of 16 from the beginning of the kvm_steal_time structure
+ * which is verified by the BUILD_BUG_ON() macro below.
+ */
+#define PREEMPTED_OFFSET   16
+asm(
+".pushsection .text;"
+".global __raw_callee_save___kvm_vcpu_is_preempted;"
+".type __raw_callee_save___kvm_vcpu_is_preempted, @function;"
+"__raw_callee_save___kvm_vcpu_is_preempted:"
+"movq  __per_cpu_offset(,%rdi,8), %rax;"
+"cmpb  $0, " __stringify(PREEMPTED_OFFSET) "+steal_time(%rax);"
+"setne %al;"
+"ret;"
+".popsection");
+
+#endif
+
 /*
  * Setup pv_lock_ops to exploit KVM_FEATURE_PV_UNHALT if present.
  */
 void __init kvm_spinlock_init(void)
 {
+   BUILD_BUG_ON((offsetof(struct kvm_steal_time, preempted)
+   != PREEMPTED_OFFSET) || (sizeof(steal_time.preempted) != 1));
+
if (!kvm_para_available())
return;
/* Does host kernel support KVM_FEATURE_PV_UNHALT? */
-- 
1.8.3.1


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

[Xen-devel] [PATCH v3 1/2] x86/paravirt: Change vcp_is_preempted() arg type to long

[Waiman Long]

The cpu argument in the function prototype of vcpu_is_preempted()
is changed from int to long. That makes it easier to provide a better
optimized assembly version of that function.

For Xen, vcpu_is_preempted(long) calls xen_vcpu_stolen(int), the
downcast from long to int is not a problem as vCPU number won't exceed
32 bits.

Signed-off-by: Waiman Long 
---
 arch/x86/include/asm/paravirt.h  | 2 +-
 arch/x86/include/asm/qspinlock.h | 2 +-
 arch/x86/kernel/kvm.c| 2 +-
 arch/x86/kernel/paravirt-spinlocks.c | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 864f57b..2a46f73 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -674,7 +674,7 @@ static __always_inline void pv_kick(int cpu)
PVOP_VCALL1(pv_lock_ops.kick, cpu);
 }
 
-static __always_inline bool pv_vcpu_is_preempted(int cpu)
+static __always_inline bool pv_vcpu_is_preempted(long cpu)
 {
return PVOP_CALLEE1(bool, pv_lock_ops.vcpu_is_preempted, cpu);
 }
diff --git a/arch/x86/include/asm/qspinlock.h b/arch/x86/include/asm/qspinlock.h
index c343ab5..48a706f 100644
--- a/arch/x86/include/asm/qspinlock.h
+++ b/arch/x86/include/asm/qspinlock.h
@@ -34,7 +34,7 @@ static inline void queued_spin_unlock(struct qspinlock *lock)
 }
 
 #define vcpu_is_preempted vcpu_is_preempted
-static inline bool vcpu_is_preempted(int cpu)
+static inline bool vcpu_is_preempted(long cpu)
 {
return pv_vcpu_is_preempted(cpu);
 }
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 099fcba..85ed343 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -589,7 +589,7 @@ static void kvm_wait(u8 *ptr, u8 val)
local_irq_restore(flags);
 }
 
-__visible bool __kvm_vcpu_is_preempted(int cpu)
+__visible bool __kvm_vcpu_is_preempted(long cpu)
 {
struct kvm_steal_time *src = &per_cpu(steal_time, cpu);
 
diff --git a/arch/x86/kernel/paravirt-spinlocks.c 
b/arch/x86/kernel/paravirt-spinlocks.c
index 6259327..8f2d1c9 100644
--- a/arch/x86/kernel/paravirt-spinlocks.c
+++ b/arch/x86/kernel/paravirt-spinlocks.c
@@ -20,7 +20,7 @@ bool pv_is_native_spin_unlock(void)
__raw_callee_save___native_queued_spin_unlock;
 }
 
-__visible bool __native_vcpu_is_preempted(int cpu)
+__visible bool __native_vcpu_is_preempted(long cpu)
 {
return false;
 }
-- 
1.8.3.1


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

Re: [Xen-devel] [PATCH 04/28] ARM: GICv3 ITS: allocate device and collection table

[Shanker Donthineni]

Hi Andre,


On 01/30/2017 12:31 PM, Andre Przywara wrote:

Each ITS maps a pair of a DeviceID (usually the PCI b/d/f triplet) and
an EventID (the MSI payload or interrupt ID) to a pair of LPI number
and collection ID, which points to the target CPU.
This mapping is stored in the device and collection tables, which software
has to provide for the ITS to use.
Allocate the required memory and hand it the ITS.
The maximum number of devices is limited to a compile-time constant
exposed in Kconfig.

Signed-off-by: Andre Przywara 
---
  xen/arch/arm/Kconfig |  14 +
  xen/arch/arm/gic-v3-its.c| 129
+++
  xen/arch/arm/gic-v3.c|   5 ++
  xen/include/asm-arm/gic_v3_its.h |  55 -
  4 files changed, 202 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 71734a1..81bc233 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -64,6 +64,20 @@ config MAX_PHYS_LPI_BITS
This can be overriden on the command line with the max_lpi_bits
parameter.

+config MAX_PHYS_ITS_DEVICE_BITS
+depends on HAS_ITS
+int "Number of device bits the ITS supports"
+range 1 32
+default "10"
+help
+  Specifies the maximum number of devices which want to use the
ITS.
+  Xen needs to allocates memory for the whole range very early.
+  The allocation scheme may be sparse, so a much larger number must
+  be supported to cover devices with a high bus number or those on
+  separate bus segments.
+  This can be overriden on the command line with the
max_its_device_bits
+  parameter.
+
The number of DEVID bits that hardware supports is discoverable through 
a register field GITS_TYPER.Devbits. The XEN driver must all the devices 
that hardware says like in the Linux kernel. I'm seeing a XEN crash if I 
set DEVID to 32bits.

  endmenu

  menu "ARM errata workaround via the alternative framework"
diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index ff0f571..c31fef6 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -20,9 +20,138 @@
  #include 
  #include 
  #include 
+#include 
+#include 
  #include 
  #include 
  #include 
+#include 
+
+#define BASER_ATTR_MASK   \
+((0x3UL << GITS_BASER_SHAREABILITY_SHIFT)   | \
+ (0x7UL << GITS_BASER_OUTER_CACHEABILITY_SHIFT) | \
+ (0x7UL << GITS_BASER_INNER_CACHEABILITY_SHIFT))
+#define BASER_RO_MASK   (GENMASK(58, 56) | GENMASK(52, 48))
+
+static uint64_t encode_phys_addr(paddr_t addr, int page_bits)
+{
+uint64_t ret;
+
+if ( page_bits < 16 )
+return (uint64_t)addr & GENMASK(47, page_bits);
+
+ret = addr & GENMASK(47, 16);
+return ret | (addr & GENMASK(51, 48)) >> (48 - 12);
+}
+
+#define PAGE_BITS(sz) ((sz) * 2 + PAGE_SHIFT)
+
+static int its_map_baser(void __iomem *basereg, uint64_t regc, int
nr_items)
+{
+uint64_t attr, reg;
+int entry_size = ((regc >> GITS_BASER_ENTRY_SIZE_SHIFT) & 0x1f) + 1;
+int pagesz = 0, order, table_size;
Better try using ITS page sizes in ote order 64K, 16K and 4K to cover 
maximum device as possible using a single level translation.

+void *buffer = NULL;
+
+attr  = GIC_BASER_InnerShareable << GITS_BASER_SHAREABILITY_SHIFT;
+attr |= GIC_BASER_CACHE_SameAsInner <<
GITS_BASER_OUTER_CACHEABILITY_SHIFT;
+attr |= GIC_BASER_CACHE_RaWaWb << GITS_BASER_INNER_CACHEABILITY_SHIFT;
+
+/*
+ * Setup the BASE register with the attributes that we like. Then read
+ * it back and see what sticks (page size, cacheability and
shareability
+ * attributes), retrying if necessary.
+ */
+while ( 1 )
+{
+table_size = ROUNDUP(nr_items * entry_size,
BIT(PAGE_BITS(pagesz)));
+order = get_order_from_bytes(table_size);
+
You can map a maximum of 256 ITS pages, order must be 'table_size >> 
PAGE_BITS(pagesz) <= 256'.



+if ( !buffer )
+buffer = alloc_xenheap_pages(order, 0);
+if ( !buffer )
+return -ENOMEM;
+
+reg  = attr;
+reg |= (pagesz << GITS_BASER_PAGE_SIZE_SHIFT);
+reg |= table_size >> PAGE_BITS(pagesz);

Change to 'reg |= table_size >> (PAGE_BITS(pagesz)) & 0xff'

+reg |= regc & BASER_RO_MASK;
+reg |= GITS_VALID_BIT;
+reg |= encode_phys_addr(virt_to_maddr(buffer), PAGE_BITS(pagesz));
+
+writeq_relaxed(reg, basereg);
+regc = readl_relaxed(basereg);
+
+/* The host didn't like our attributes, just use what it returned.
*/
+if ( (regc & BASER_ATTR_MASK) != attr )
+{
+/* If we can't map it shareable, drop cacheability as well. */
+if ( (regc & GITS_BASER_SHAREABILITY_MASK) ==
GIC_BASER_NonShareable )
+{
+regc &= ~GITS_BASER_INNER_CACHEABILITY_MASK;
+attr 

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf cb8674999c6bf94cdb3be18df3746131aac6386b
baseline version:
 ovmf 5e9e151c2061cc10e5aa9f41c6f1d7d1b865954e

Last test of basis68562  2017-02-15 10:16:47 Z0 days
Testing same since68564  2017-02-15 14:20:57 Z0 days1 attempts


People who touched revisions under test:
  Hao Wu 

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



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

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

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


Push not applicable.


commit cb8674999c6bf94cdb3be18df3746131aac6386b
Author: Hao Wu 
Date:   Tue Feb 14 10:11:58 2017 +0800

MdePkg/BaseLib: Refine logic for (Ascii)StrnLenS to handle MaxSize = 0

https://bugzilla.tianocore.org/show_bug.cgi?id=378

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
Reviewed-by: Jiewen Yao 

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

[Xen-devel] [linux-next test] 105812: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-pvh-intel 11 guest-start fail REGR. vs. 105807
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail 
REGR. vs. 105807
 test-amd64-amd64-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail REGR. vs. 
105807
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 17 guest-start/win.repeat fail REGR. 
vs. 105807

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stopfail REGR. vs. 105807
 test-armhf-armhf-xl-arndale 15 guest-start/debian.repeat fail blocked in 105807
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-check fail blocked in 
105807
 test-armhf-armhf-libvirt   13 saverestore-support-check fail blocked in 105807
 test-armhf-armhf-libvirt-raw 12 saverestore-support-check fail blocked in 
105807
 test-armhf-armhf-xl-rtds   15 guest-start/debian.repeat fail blocked in 105807
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 105807
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 105807
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 105807

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

version targeted for testing:
 linuxfee922e6a9938c0242fccd544f00abe9322ea578
baseline version:
 linux747ae0a96f1a78b35c5a3d93ad37a16655e16340

Last test of basis  (not found) 
Failing since 0  1970-01-01 00:00:00 Z 17212 days
Testing same since   105812  2017-02-15 10:04:28 Z0 days1 attempts

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

[Xen-devel] [PATCH 3/3] xen/include: Include xen/kconfig.h automatically

[Andrew Cooper]

generated/autoconf.h is already included automatically so CONFIG_* defines are
avaialble.  However, the companion macros such as IS_ENABLED() are not
included.

Include them uniformally everywhere.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Stefano Stabellini 
CC: Julien Grall 
---
 xen/drivers/acpi/osl.c| 1 -
 xen/include/asm-arm/alternative.h | 1 -
 xen/include/xen/config.h  | 2 +-
 3 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/xen/drivers/acpi/osl.c b/xen/drivers/acpi/osl.c
index f75dfb7..94dbf04 100644
--- a/xen/drivers/acpi/osl.c
+++ b/xen/drivers/acpi/osl.c
@@ -37,7 +37,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #define _COMPONENT ACPI_OS_SERVICES
 ACPI_MODULE_NAME("osl")
diff --git a/xen/include/asm-arm/alternative.h 
b/xen/include/asm-arm/alternative.h
index c9740b8..6cc9d0d 100644
--- a/xen/include/asm-arm/alternative.h
+++ b/xen/include/asm-arm/alternative.h
@@ -2,7 +2,6 @@
 #define __ASM_ALTERNATIVE_H
 
 #include 
-#include 
 
 #ifdef CONFIG_HAS_ALTERNATIVE
 
diff --git a/xen/include/xen/config.h b/xen/include/xen/config.h
index 473c5e8..9f39687 100644
--- a/xen/include/xen/config.h
+++ b/xen/include/xen/config.h
@@ -7,7 +7,7 @@
 #ifndef __XEN_CONFIG_H__
 #define __XEN_CONFIG_H__
 
-#include 
+#include 
 
 #ifndef __ASSEMBLY__
 #include 
-- 
2.1.4


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

[Xen-devel] [PATCH 2/3] xen/include: Remove explicit asm/config.h includes

[Andrew Cooper]

xen/config.h includes asm/config.h, and is included automatically via CFLAGS.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Stefano Stabellini 
CC: Julien Grall 
---
 xen/arch/arm/acpi/lib.c| 1 -
 xen/arch/arm/arm32/debug.S | 1 -
 xen/arch/arm/arm32/head.S  | 1 -
 xen/arch/arm/arm64/debug.S | 1 -
 xen/arch/arm/arm64/head.S  | 1 -
 5 files changed, 5 deletions(-)

diff --git a/xen/arch/arm/acpi/lib.c b/xen/arch/arm/acpi/lib.c
index 79f7edd..9bd769c 100644
--- a/xen/arch/arm/acpi/lib.c
+++ b/xen/arch/arm/acpi/lib.c
@@ -23,7 +23,6 @@
 
 #include 
 #include 
-#include 
 
 char *__acpi_map_table(paddr_t phys, unsigned long size)
 {
diff --git a/xen/arch/arm/arm32/debug.S b/xen/arch/arm/arm32/debug.S
index a95d9da..1538090 100644
--- a/xen/arch/arm/arm32/debug.S
+++ b/xen/arch/arm/arm32/debug.S
@@ -17,7 +17,6 @@
  * GNU General Public License for more details.
  */
 
-#include 
 #include 
 
 #ifdef EARLY_PRINTK_INC
diff --git a/xen/arch/arm/arm32/head.S b/xen/arch/arm/arm32/head.S
index e1f29bd..ec63ba4 100644
--- a/xen/arch/arm/arm32/head.S
+++ b/xen/arch/arm/arm32/head.S
@@ -17,7 +17,6 @@
  * GNU General Public License for more details.
  */
 
-#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/arm/arm64/debug.S b/xen/arch/arm/arm64/debug.S
index a855358..87ee8dc 100644
--- a/xen/arch/arm/arm64/debug.S
+++ b/xen/arch/arm/arm64/debug.S
@@ -17,7 +17,6 @@
  * GNU General Public License for more details.
  */
 
-#include 
 #include 
 
 #ifdef EARLY_PRINTK_INC
diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index 3a54356..72ea4e0 100644
--- a/xen/arch/arm/arm64/head.S
+++ b/xen/arch/arm/arm64/head.S
@@ -20,7 +20,6 @@
  * GNU General Public License for more details.
  */
 
-#include 
 #include 
 #include 
 #include 
-- 
2.1.4


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

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

[Julien Grall]

On 30/01/17 18:31, Andre Przywara wrote:

Hi,


Hi Andre,


Compared to the previous post (RFC-v2) this has seen a lot of reworks
and cleanups in various areas.
I tried to address all of the review comments, though some are hard to
follow due to rewrites. So apologies if some points have slipped through.


A lot of the comments were not in the code reworked. It is not that 
difficult to check whether a comment still apply or not before sending a 
series and can save a lot of bandwidth review.


For the next version please go through all the comments from the first 2 
versions and see whether they need to be addressed.


Cheers,

--
Julien Grall

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

[Xen-devel] [xen-unstable-smoke test] 105822: regressions - trouble: broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl  11 guest-start  fail REGR. vs. 105820

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   5 xen-buildfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass

version targeted for testing:
 xen  b7a3ce49d5283b5940fe2dba85f7abfd6f8192e0
baseline version:
 xen  93e1435290867703c50acad1f54b9208df473562

Last test of basis   105820  2017-02-15 13:01:10 Z0 days
Testing same since   105822  2017-02-15 16:02:25 Z0 days1 attempts


People who touched revisions under test:
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Konrad Rzeszutek Wilk 
  Oleksandr Andrushchenko 
  Stefano Stabellini 
  Wei Liu 

jobs:
 build-amd64  pass
 build-arm64  fail
 build-armhf  pass
 build-amd64-libvirt  pass
 build-arm64-pvopsfail
 test-armhf-armhf-xl  fail
 test-arm64-arm64-xl-xsm  broken  
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



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

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

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

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


Not pushing.


commit b7a3ce49d5283b5940fe2dba85f7abfd6f8192e0
Author: Oleksandr Andrushchenko 
Date:   Wed Feb 8 09:38:18 2017 +0200

xen/kbdif: add multi-touch support

Multi-touch fields re-use the page that is used by the other features
which means that you can interleave multi-touch, motion, and key
events.

Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Stefano Stabellini 
Signed-off-by: Oleksandr Andrushchenko 

commit b3b23a764f6d3a83297f24f70e24a7716a04549f
Author: Oleksandr Andrushchenko 
Date:   Tue Feb 7 12:38:41 2017 -0500

xen/kbdif: Update protocol description

The patch clarifies the protocol that is used by the PV keyboard
drivers.

Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Stefano Stabellini 
Signed-off-by: Oleksandr Andrushchenko 

commit 993056190e5630701b316925956e3026a5ec2da2
Author: Konrad Rzeszutek Wilk 
Date:   Fri Nov 18 11:18:24 2016 -0500

MAINTAINERS: Add myself as the public API "Czar"

That way we have one person who can: a) poke other maintainers
or pull them in with new drivers are introduced, b) we have
one maintainer who can shepherd the patches along instead of
depending on the REST maintainers which may be busy with
other responsibilities.

Acked-by: Ian Jackson 
Acked-by: Jan Beulich 
Acked-by: Stefano Stabellini 
Acked-by: George Dunlap 
Acked-by: Wei Liu 
Signed-off-by: Konrad Rzeszutek Wilk 
(qemu changes not included)

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

Re: [Xen-devel] Unshared IOMMU issues

[Oleksandr Tyshchenko]

Hi, Jan.

On Wed, Feb 15, 2017 at 6:22 PM, Jan Beulich  wrote:
 On 15.02.17 at 16:52,  wrote:
>> I think, but I am not 100% sure that we could avoid actions above if
>> we would have knowledge about device assignment for particular
>> domain before making any updates in P2M.
>
> Well, one could in theory make this work for boot time assigned
> devices, but since this won't cover runtime assigned (hotplugged)
> ones, I don't think this would gain you anything.

Indeed, I didn't take into account hotplugged devices.

>
>> Could you please suggest me a right way in resolving such problems?
>
> Well, you described what you do (with quite a bit of ARM terminology
> I don't understand), but I'm not sure you made explicit what problem(s)
> you need to solve. I'm sorry if it's just me not understanding what you
> wrote.
Ok.

Sorry, if I was unclear. Let rephrase a bit.

I described some generic problems I had faced during playing with
new IOMMU driver (that doesn't share page table with the CPU unlike
existing SMMU driver) in XEN on ARM.
I described how I had resolved it somehow, just to see it working.
Now, I want to hear community opinion about
whether these changes are correct and might be acceptable in general
or these changes should be done in other way.

1.
I need:
Allow P2M core on ARM to update IOMMU mapping from the first "p2m_set_entry".
I do:
I explicitly set need_iommu flag for *every* guest domain during
iommu_domain_init() on ARM in case if page table is not shared.
At that moment I have no knowledge about will any device be assigned
to this domain or not. I am just want to receive all mapping updates
from P2M code. The P2M will update IOMMU mapping only when need_iommu
is set and page table is not shared.
I have doubts:
Is it correct to just force need_iommu flag? Or maybe another flag
should be introduced?
Or we don't need to check for need_iommu flag before updating IOMMU
mapping in P2M code, maybe iommu_enabled would be enough?

2.
I need:
Allow IOMMU driver to be ready to handle IOMMU mapping updates from
the first "p2m_set_entry".
I do:
I always allocate IOMMU page table during iommu_domain_init() for every
domain even this domain won't have any assigned devices in future. I
don't wait for iommu_construct.
I have doubts:
Is it correct? It might be just wasting memory and CPU time if domain
doesn't have any assigned devices in future.

>
> Jan
>



-- 
Regards,

Oleksandr Tyshchenko

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

[Xen-devel] [PATCH 1/2] xen/sched.h Whitespace and bool cleanup

[Andrew Cooper]

Extend the Maptrack comment to point at the Grant table subsystem.

No functional change.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Stefano Stabellini 
CC: Julien Grall 
---
 xen/include/xen/sched.h | 48 
 1 file changed, 24 insertions(+), 24 deletions(-)

diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 063efe6..def097e 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -139,7 +139,7 @@ void evtchn_destroy_final(struct domain *d); /* from 
complete_domain_destroy */
 
 struct waitqueue_vcpu;
 
-struct vcpu 
+struct vcpu
 {
 int  vcpu_id;
 
@@ -176,20 +176,20 @@ struct vcpu
 uint64_t last_run_time;
 
 /* Has the FPU been initialised? */
-bool_t   fpu_initialised;
+bool fpu_initialised;
 /* Has the FPU been used since it was last saved? */
-bool_t   fpu_dirtied;
+bool fpu_dirtied;
 /* Initialization completed for this VCPU? */
-bool_t   is_initialised;
+bool is_initialised;
 /* Currently running on a CPU? */
-bool_t   is_running;
+bool is_running;
 /* VCPU should wake fast (do not deep sleep the CPU). */
-bool_t   is_urgent;
+bool is_urgent;
 
 #ifdef VCPU_TRAP_LAST
 #define VCPU_TRAP_NONE0
 struct {
-bool_t   pending;
+bool pending;
 uint8_t  old_mask;
 }async_exception_state[VCPU_TRAP_LAST];
 #define async_exception_state(t) async_exception_state[(t)-1]
@@ -197,11 +197,11 @@ struct vcpu
 #endif
 
 /* Require shutdown to be deferred for some asynchronous operation? */
-bool_t   defer_shutdown;
+bool defer_shutdown;
 /* VCPU is paused following shutdown request (d->is_shutting_down)? */
-bool_t   paused_for_shutdown;
+bool paused_for_shutdown;
 /* VCPU need affinity restored */
-bool_t   affinity_broken;
+bool affinity_broken;
 
 
 /*
@@ -222,7 +222,7 @@ struct vcpu
 /* VCPU paused by system controller. */
 int  controller_pause_count;
 
-/* Maptrack */
+/* Grant table map tracking. */
 unsigned int maptrack_head;
 unsigned int maptrack_tail;
 
@@ -375,17 +375,17 @@ struct domain
 s8   need_iommu;
 #endif
 /* is node-affinity automatically computed? */
-bool_t   auto_node_affinity;
+bool auto_node_affinity;
 /* Is this guest fully privileged (aka dom0)? */
-bool_t   is_privileged;
+bool is_privileged;
 /* Is this a xenstore domain (not dom0)? */
-bool_t   is_xenstore;
+bool is_xenstore;
 /* Domain's VCPUs are pinned 1:1 to physical CPUs? */
-bool_t   is_pinned;
+bool is_pinned;
 /* Non-migratable and non-restoreable? */
-bool_t   disable_migrate;
+bool disable_migrate;
 /* Is this guest being debugged by dom0? */
-bool_t   debugger_attached;
+bool debugger_attached;
 /*
  * Set to true at the very end of domain creation, when the domain is
  * unpaused for the first time by the systemcontroller.
@@ -408,8 +408,8 @@ struct domain
 
 /* Guest has shut down (inc. reason code)? */
 spinlock_t   shutdown_lock;
-bool_t   is_shutting_down; /* in process of shutting down? */
-bool_t   is_shut_down; /* fully shut down? */
+bool is_shutting_down; /* in process of shutting down? */
+bool is_shut_down; /* fully shut down? */
 #define SHUTDOWN_CODE_INVALID ~0u
 unsigned int shutdown_code;
 
@@ -558,7 +558,7 @@ struct domain *domain_create(domid_t domid, unsigned int 
domcr_flags,
 /*
  * rcu_lock_domain_by_id() is more efficient than get_domain_by_id().
  * This is the preferred function if the returned domain reference
- * is short lived,  but it cannot be used if the domain reference needs 
+ * is short lived,  but it cannot be used if the domain reference needs
  * to be kept beyond the current scope (e.g., across a softirq).
  * The returned domain reference must be discarded using rcu_unlock_domain().
  */
@@ -675,7 +675,7 @@ void sync_local_execstate(void);
  * sync_vcpu_execstate() will switch and commit @prev's state.
  */
 void context_switch(
-struct vcpu *prev, 
+struct vcpu *prev,
 struct vcpu *next);
 
 /*
@@ -853,7 +853,7 @@ uint64_t get_cpu_idle_time(unsigned int cpu);
 void watchdog_domain_init(struct domain *d);
 void watchdog_domain_destroy(struct domain *d);
 
-/* 
+/*
  * Use this check when the following are both true:
  *  - Using this feature or interface requires full access to the hardware
  *(that is, this would not be suitable for a driver domain)
@@ -882,7 +882,7 @@ void watchdog_dom

[Xen-devel] [PATCH 2/2] common/vcpu: Switch v->vcpu_info_mfn to mfn_t

[Andrew Cooper]

No functional change.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Stefano Stabellini 
CC: Julien Grall 
---
 xen/common/domain.c | 15 ++-
 xen/include/xen/sched.h |  2 +-
 2 files changed, 7 insertions(+), 10 deletions(-)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index 05130e2..5b069b9 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -117,7 +117,7 @@ static void vcpu_info_reset(struct vcpu *v)
 v->vcpu_info = ((v->vcpu_id < XEN_LEGACY_MAX_VCPUS)
 ? (vcpu_info_t *)&shared_info(d, vcpu_info[v->vcpu_id])
 : &dummy_vcpu_info);
-v->vcpu_info_mfn = mfn_x(INVALID_MFN);
+v->vcpu_info_mfn = INVALID_MFN;
 }
 
 struct vcpu *alloc_vcpu(
@@ -1150,7 +1150,7 @@ int map_vcpu_info(struct vcpu *v, unsigned long gfn, 
unsigned offset)
 if ( offset > (PAGE_SIZE - sizeof(vcpu_info_t)) )
 return -EINVAL;
 
-if ( v->vcpu_info_mfn != mfn_x(INVALID_MFN) )
+if ( !mfn_eq(v->vcpu_info_mfn, INVALID_MFN) )
 return -EINVAL;
 
 /* Run this command on yourself or on other offline VCPUS. */
@@ -1189,7 +1189,7 @@ int map_vcpu_info(struct vcpu *v, unsigned long gfn, 
unsigned offset)
 }
 
 v->vcpu_info = new_info;
-v->vcpu_info_mfn = page_to_mfn(page);
+v->vcpu_info_mfn = _mfn(page_to_mfn(page));
 
 /* Set new vcpu_info pointer /before/ setting pending flags. */
 smp_wmb();
@@ -1208,22 +1208,19 @@ int map_vcpu_info(struct vcpu *v, unsigned long gfn, 
unsigned offset)
 
 /*
  * Unmap the vcpu info page if the guest decided to place it somewhere
- * else. This is used from arch_domain_destroy and domain_soft_reset.
+ * else. This is used from domain_kill() and domain_soft_reset().
  */
 void unmap_vcpu_info(struct vcpu *v)
 {
-unsigned long mfn;
-
-if ( v->vcpu_info_mfn == mfn_x(INVALID_MFN) )
+if ( mfn_eq(v->vcpu_info_mfn, INVALID_MFN) )
 return;
 
-mfn = v->vcpu_info_mfn;
 unmap_domain_page_global((void *)
  ((unsigned long)v->vcpu_info & PAGE_MASK));
 
 vcpu_info_reset(v);
 
-put_page_and_type(mfn_to_page(mfn));
+put_page_and_type(mfn_to_page(mfn_x(v->vcpu_info_mfn)));
 }
 
 int default_initialise_vcpu(struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg)
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index def097e..32893de 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -252,7 +252,7 @@ struct vcpu
 struct waitqueue_vcpu *waitqueue_vcpu;
 
 /* Guest-specified relocation of vcpu_info. */
-unsigned long vcpu_info_mfn;
+mfn_tvcpu_info_mfn;
 
 struct evtchn_fifo_vcpu *evtchn_fifo;
 
-- 
2.1.4


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

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

[Julien Grall]

Hi Andre,

On 30/01/17 18:31, Andre Przywara wrote:

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

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/gic-v3-its.c | 34 --
 xen/arch/arm/gic-v3.c | 19 +++
 2 files changed, 51 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index f073ab5..2a7093f 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -62,6 +62,28 @@ static int its_send_command(struct host_its *hw_its, const 
void *its_cmd)
 return 0;
 }

+/* Wait for an ITS to finish processing all commands. */
+static int gicv3_its_wait_commands(struct host_its *hw_its)
+{
+s_time_t deadline = NOW() + MILLISECS(1000);
+uint64_t readp, writep;
+
+do {
+spin_lock(&hw_its->cmd_lock);
+readp = readq_relaxed(hw_its->its_base + GITS_CREADR) & BUFPTR_MASK;
+writep = readq_relaxed(hw_its->its_base + GITS_CWRITER) & BUFPTR_MASK;
+spin_unlock(&hw_its->cmd_lock);
+
+if ( readp == writep )
+return 0;
+
+cpu_relax();
+udelay(1);
+} while ( NOW() <= deadline );
+
+return -ETIMEDOUT;
+}
+
 static uint64_t encode_rdbase(struct host_its *hw_its, int cpu, uint64_t reg)
 {
 reg &= ~GENMASK(51, 16);
@@ -161,6 +183,10 @@ int gicv3_its_setup_collection(int cpu)
 ret = its_send_cmd_sync(its, cpu);
 if ( ret )
 return ret;
+
+ret = gicv3_its_wait_commands(its);
+if ( ret )
+return ret;


Why are all the gicv3_its_wait_commands are added now and not when the 
command was added?


Maybe I am missing something but base on the commit message, this patch 
should really just turning on the enable bit.


Cheers,

--
Julien Grall

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt  6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-credit2   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-arndale   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-xsm   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-libvirt-xsm  6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail REGR. vs. 59254
 build-armhf   4 host-build-prep fail in 105803 REGR. vs. 59254

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 
guest-localmigrate/x10 fail in 105795 pass in 105807
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail 
in 105803 pass in 105795
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail in 105803 pass in 105807
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 13 guest-localmigrate fail pass 
in 105803
 test-amd64-amd64-xl-qemut-winxpsp3 15 guest-localmigrate/x10 fail pass in 
105803

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds  6 xen-boot  fail REGR. vs. 59254
 test-amd64-amd64-xl-rtds  9 debian-installfail REGR. vs. 59254
 test-armhf-armhf-libvirt-raw  6 xen-bootfail baseline untested
 test-armhf-armhf-xl-vhd   6 xen-bootfail baseline untested
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 59254
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 59254

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

version targeted for testing:
 linux747ae0a96f1a78b35c5a3d93ad37a16655e16340
baseline version:
 linux45820c294fe1b1a9df495d57f40585ef2d069a39

Last test of basis59254  2015-07-09 04:20:48 Z  5

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

[Julien Grall]

Hi Andre,

On 30/01/17 18:31, Andre Przywara wrote:

Upon receiving an LPI, we need to find the right VCPU and virtual IRQ
number to get this IRQ injected.
Iterate our two-level LPI table to find this information quickly when
the host takes an LPI. Call the existing injection function to let the
GIC emulation deal with this interrupt.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/gic-v3-lpi.c | 41 +
 xen/arch/arm/gic.c|  6 --
 xen/include/asm-arm/irq.h |  8 
 3 files changed, 53 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c
index 8f6e7f3..d270053 100644
--- a/xen/arch/arm/gic-v3-lpi.c
+++ b/xen/arch/arm/gic-v3-lpi.c
@@ -86,6 +86,47 @@ uint64_t gicv3_get_redist_address(int cpu, bool use_pta)
 return per_cpu(redist_id, cpu) << 16;
 }

+/*
+ * Handle incoming LPIs, which are a bit special, because they are potentially
+ * numerous and also only get injected into guests. Treat them specially here,
+ * by just looking up their target vCPU and virtual LPI number and hand it
+ * over to the injection function.
+ */
+void do_LPI(unsigned int lpi)
+{
+struct domain *d;
+union host_lpi *hlpip, hlpi;
+struct vcpu *vcpu;
+
+WRITE_SYSREG32(lpi, ICC_EOIR1_EL1);
+
+hlpip = gic_get_host_lpi(lpi);
+if ( !hlpip )
+return;
+
+hlpi.data = read_u64_atomic(&hlpip->data);
+
+/* We may have mapped more host LPIs than the guest actually asked for. */


Another way, is the interrupt has been received at the same time the 
guest is configuring it. What will happen if the interrupt is lost?



+if ( !hlpi.virt_lpi )
+return;
+
+d = get_domain_by_id(hlpi.dom_id);
+if ( !d )
+return;
+
+if ( hlpi.vcpu_id >= d->max_vcpus )


A comment would be certainly useful here to explain why this check.


+{
+put_domain(d);
+return;
+}
+
+vcpu = d->vcpu[hlpi.vcpu_id];
+
+put_domain(d);
+
+vgic_vcpu_inject_irq(vcpu, hlpi.virt_lpi);
+}
+
 uint64_t gicv3_lpi_allocate_pendtable(void)
 {
 uint64_t reg;
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index bd3c032..7286e5d 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -700,8 +700,10 @@ void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
 local_irq_enable();
 do_IRQ(regs, irq, is_fiq);
 local_irq_disable();
-}
-else if (unlikely(irq < 16))
+} else if ( is_lpi(irq) )


Coding style:

}
else if (...)
{
}
else if (...)


+{
+do_LPI(irq);


I really don't want to see GICv3 specific code called in common code. 
Please introduce a specific callback in gic_hw_operations.



+} else if ( unlikely(irq < 16) )
 {
 do_sgi(regs, irq);
 }
diff --git a/xen/include/asm-arm/irq.h b/xen/include/asm-arm/irq.h
index 8f7a167..ee47de8 100644
--- a/xen/include/asm-arm/irq.h
+++ b/xen/include/asm-arm/irq.h
@@ -34,6 +34,14 @@ struct irq_desc *__irq_to_desc(int irq);

 void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, int is_fiq);

+#ifdef CONFIG_HAS_ITS
+void do_LPI(unsigned int irq);
+#else
+static inline void do_LPI(unsigned int irq)
+{
+}
+#endif
+


This would avoid such ugly hack where do_LPI is define in gic-v3-its.c 
but declared in irq.h.


Cheers,

--
Julien Grall

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

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

[Julien Grall]

Hi Stefano,

On 14/02/17 21:00, Stefano Stabellini wrote:

On Mon, 30 Jan 2017, Andre Przywara wrote:

+/*
+ * Handle incoming LPIs, which are a bit special, because they are potentially
+ * numerous and also only get injected into guests. Treat them specially here,
+ * by just looking up their target vCPU and virtual LPI number and hand it
+ * over to the injection function.
+ */
+void do_LPI(unsigned int lpi)
+{
+struct domain *d;
+union host_lpi *hlpip, hlpi;
+struct vcpu *vcpu;
+
+WRITE_SYSREG32(lpi, ICC_EOIR1_EL1);
+
+hlpip = gic_get_host_lpi(lpi);
+if ( !hlpip )
+return;
+
+hlpi.data = read_u64_atomic(&hlpip->data);
+
+/* We may have mapped more host LPIs than the guest actually asked for. */
+if ( !hlpi.virt_lpi )
+return;
+
+d = get_domain_by_id(hlpi.dom_id);
+if ( !d )
+return;
+
+if ( hlpi.vcpu_id >= d->max_vcpus )
+{
+put_domain(d);
+return;
+}
+
+vcpu = d->vcpu[hlpi.vcpu_id];
+
+put_domain(d);
+
+vgic_vcpu_inject_irq(vcpu, hlpi.virt_lpi);


put_domain should be here


Why? I don't even understand why we would need to take a reference on 
the domain for LPIs. Would not it be enough to use rcu_lock_domain_by_id 
here?


Regards,

--
Julien Grall

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

[Xen-devel] [PATCH 2/2] tools/libxl: Introduce LIBXL_CPUPOOL_POOLID_ANY

[George Dunlap]

Callers to libxl_cpupool_create() can either request a specific pool
id, or request that Xen do it for them.  But at the moment, the
"automatic" selection is indicated by using a magic value, 0.  This is
undesirable both because it doesn't obviously have meaning, but also
because '0' is a valid cpupool (albeit one which at the moment can't
be changed).

Introduce a constant, LIBXL_CPUPOOL_POOLID_ANY, to indicate this
instead.  Still accept '0' as meaning "ANY" for backwards
compatibility.

Signed-off-by: George Dunlap 
Reviewed-by: Dario Faggioli 
---
v2: Rebase over libxl.c-split series

CC: Ian Jackson 
CC: Wei Liu 
CC: Juergen Gross 
CC: Dario Faggioli 
CC: Ronald Rojas 
---
 tools/libxl/libxl.h | 6 ++
 tools/libxl/libxl_cpupool.c | 8 ++--
 tools/libxl/xl_cmdimpl.c| 2 +-
 3 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 3924464..d5559c0 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -2086,6 +2086,12 @@ int libxl_tmem_shared_auth(libxl_ctx *ctx, uint32_t 
domid, char* uuid,
 int libxl_tmem_freeable(libxl_ctx *ctx);
 
 int libxl_get_freecpus(libxl_ctx *ctx, libxl_bitmap *cpumap);
+
+/* 
+ * Set poolid to LIBXL_CPUOOL_POOLID_ANY to have Xen choose a
+ * free poolid for you.
+ */
+#define LIBXL_CPUPOOL_POOLID_ANY 0x
 int libxl_cpupool_create(libxl_ctx *ctx, const char *name,
  libxl_scheduler sched,
  libxl_bitmap cpumap, libxl_uuid *uuid,
diff --git a/tools/libxl/libxl_cpupool.c b/tools/libxl/libxl_cpupool.c
index 0ff8724..ef9ff84 100644
--- a/tools/libxl/libxl_cpupool.c
+++ b/tools/libxl/libxl_cpupool.c
@@ -139,8 +139,12 @@ int libxl_cpupool_create(libxl_ctx *ctx, const char *name,
 char *uuid_string;
 uint32_t xcpoolid;
 
-/* Zero means "choose a poolid for me" */
-xcpoolid = (*poolid) ? (*poolid) : XC_CPUPOOL_POOLID_ANY;
+/* Accept '0' as 'any poolid' for backwards compatibility */
+if ( *poolid == LIBXL_CPUPOOL_POOLID_ANY
+ || *poolid == 0 ) 
+xcpoolid = XC_CPUPOOL_POOLID_ANY;
+else
+xcpoolid = *poolid;
 
 uuid_string = libxl__uuid2string(gc, *uuid);
 if (!uuid_string) {
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 37ebdce..0add5dc 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -8368,7 +8368,7 @@ int main_cpupoolcreate(int argc, char **argv)
 printf("number of cpus: %d\n", n_cpus);
 
 if (!dryrun_only) {
-poolid = 0;
+poolid = LIBXL_CPUPOOL_POOLID_ANY;
 if (libxl_cpupool_create(ctx, name, sched, cpumap, &uuid, &poolid)) {
 fprintf(stderr, "error on creating cpupool\n");
 goto out_cfg;
-- 
2.1.4


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

[Xen-devel] [PATCH 1/2] tools/libxc: Introduce XC_CPUPOOL_POOLID_ANY

[George Dunlap]

Callers to xc_cpupool_create() can either request a specific pool id,
or request that Xen do it for them.  But at the moment, the
"automatic" selection is indicated by using a magic value, 0.  This is
undesirable both because it doesn't obviously have meaning, but also
because '0' is a valid cpupool (albeit one which at the moment can't
be changed).

Introduce a constant, XC_CPUPOOL_POOLID_ANY, to indicate this instead.
Have it be the default for the python bindings.

Manually translate it, even though it's the same underlying value,
because we don't yet have a relaible way of enforcing that these
values are the same.

Signed-off-by: George Dunlap 
Reviewed-by: Dario Faggioli 
Acked-by: Wei Liu 
---
v2: Rebase over libxl.c-split series

CC: Ian Jackson 
CC: Wei Liu 
CC: Juergen Gross 
CC: Dario Faggioli 
CC: Ronald Rojas 
---
 tools/libxc/include/xenctrl.h | 2 ++
 tools/libxc/xc_cpupool.c  | 2 +-
 tools/libxl/libxl_cpupool.c   | 7 ++-
 tools/python/xen/lowlevel/xc/xc.c | 2 +-
 4 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 85d7fe5..927e373 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1052,6 +1052,8 @@ typedef struct xc_cpupoolinfo {
 xc_cpumap_t cpumap;
 } xc_cpupoolinfo_t;
 
+#define XC_CPUPOOL_POOLID_ANY 0x
+
 /**
  * Create a new cpupool.
  *
diff --git a/tools/libxc/xc_cpupool.c b/tools/libxc/xc_cpupool.c
index 70011d1..fbd8cc9 100644
--- a/tools/libxc/xc_cpupool.c
+++ b/tools/libxc/xc_cpupool.c
@@ -43,7 +43,7 @@ int xc_cpupool_create(xc_interface *xch,
 
 sysctl.cmd = XEN_SYSCTL_cpupool_op;
 sysctl.u.cpupool_op.op = XEN_SYSCTL_CPUPOOL_OP_CREATE;
-sysctl.u.cpupool_op.cpupool_id = (*ppoolid == 0) ?
+sysctl.u.cpupool_op.cpupool_id = (*ppoolid == XC_CPUPOOL_POOLID_ANY) ?
 XEN_SYSCTL_CPUPOOL_PAR_ANY : *ppoolid;
 sysctl.u.cpupool_op.sched_id = sched_id;
 if ( (err = do_sysctl_save(xch, &sysctl)) != 0 )
diff --git a/tools/libxl/libxl_cpupool.c b/tools/libxl/libxl_cpupool.c
index f3d22b1..0ff8724 100644
--- a/tools/libxl/libxl_cpupool.c
+++ b/tools/libxl/libxl_cpupool.c
@@ -137,6 +137,10 @@ int libxl_cpupool_create(libxl_ctx *ctx, const char *name,
 int i;
 xs_transaction_t t;
 char *uuid_string;
+uint32_t xcpoolid;
+
+/* Zero means "choose a poolid for me" */
+xcpoolid = (*poolid) ? (*poolid) : XC_CPUPOOL_POOLID_ANY;
 
 uuid_string = libxl__uuid2string(gc, *uuid);
 if (!uuid_string) {
@@ -144,12 +148,13 @@ int libxl_cpupool_create(libxl_ctx *ctx, const char *name,
 return ERROR_NOMEM;
 }
 
-rc = xc_cpupool_create(ctx->xch, poolid, sched);
+rc = xc_cpupool_create(ctx->xch, &xcpoolid, sched);
 if (rc) {
 LOGEV(ERROR, rc, "Could not create cpupool");
 GC_FREE;
 return ERROR_FAIL;
 }
+*poolid = xcpoolid;
 
 libxl_for_each_bit(i, cpumap)
 if (libxl_bitmap_test(&cpumap, i)) {
diff --git a/tools/python/xen/lowlevel/xc/xc.c 
b/tools/python/xen/lowlevel/xc/xc.c
index 39be1d5..9e93d49 100644
--- a/tools/python/xen/lowlevel/xc/xc.c
+++ b/tools/python/xen/lowlevel/xc/xc.c
@@ -1715,7 +1715,7 @@ static PyObject *pyxc_cpupool_create(XcObject *self,
  PyObject *args,
  PyObject *kwds)
 {
-uint32_t cpupool = 0, sched = XEN_SCHEDULER_CREDIT;
+uint32_t cpupool = XC_CPUPOOL_POOLID_ANY, sched = XEN_SCHEDULER_CREDIT;
 
 static char *kwd_list[] = { "pool", "sched", NULL };
 
-- 
2.1.4


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

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

[Julien Grall]

Hi Stefano,

On 14/02/17 20:39, Stefano Stabellini wrote:

On Mon, 30 Jan 2017, Andre Przywara wrote:

For the same reason that allocating a struct irq_desc for each
possible LPI is not an option, having a struct pending_irq for each LPI
is also not feasible. However we actually only need those when an
interrupt is on a vCPU (or is about to be injected).
Maintain a list of those structs that we can use for the lifecycle of
a guest LPI. We allocate new entries if necessary, however reuse
pre-owned entries whenever possible.
I added some locking around this list here, however my gut feeling is
that we don't need one because this a per-VCPU structure anyway.
If someone could confirm this, I'd be grateful.
Teach the existing VGIC functions to find the right pointer when being
given a virtual LPI number.

Signed-off-by: Andre Przywara 


Please address past comments, specifically use a data structure per
domain, rather than per-vcpu. Also please move to a more efficient data
structure, such as an hashtable or a tree.


+1 for both. We need to limit the memory used by a domain.

Cheers,

--
Julien Grall

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

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

[Julien Grall]

Hi Andre,

On 30/01/17 18:31, Andre Przywara wrote:

For the same reason that allocating a struct irq_desc for each
possible LPI is not an option, having a struct pending_irq for each LPI
is also not feasible. However we actually only need those when an
interrupt is on a vCPU (or is about to be injected).
Maintain a list of those structs that we can use for the lifecycle of
a guest LPI. We allocate new entries if necessary, however reuse
pre-owned entries whenever possible.
I added some locking around this list here, however my gut feeling is
that we don't need one because this a per-VCPU structure anyway.
If someone could confirm this, I'd be grateful.
Teach the existing VGIC functions to find the right pointer when being
given a virtual LPI number.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/gic.c   |  3 +++
 xen/arch/arm/vgic-v3.c   |  3 +++
 xen/arch/arm/vgic.c  | 64 +---
 xen/include/asm-arm/domain.h |  2 ++
 xen/include/asm-arm/vgic.h   | 14 ++
 5 files changed, 83 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index a5348f2..bd3c032 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -509,6 +509,9 @@ static void gic_update_one_lr(struct vcpu *v, int i)
 struct vcpu *v_target = vgic_get_target_vcpu(v, irq);
 irq_set_affinity(p->desc, cpumask_of(v_target->processor));
 }
+/* If this was an LPI, mark this struct as available again. */
+if ( is_lpi(p->irq) )
+p->irq = 0;
 }
 }
 }
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index 1fadb00..b0653c2 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -1426,6 +1426,9 @@ static int vgic_v3_vcpu_init(struct vcpu *v)
 if ( v->vcpu_id == last_cpu || (v->vcpu_id == (d->max_vcpus - 1)) )
 v->arch.vgic.flags |= VGIC_V3_RDIST_LAST;

+spin_lock_init(&v->arch.vgic.pending_lpi_list_lock);
+INIT_LIST_HEAD(&v->arch.vgic.pending_lpi_list);
+
 return 0;
 }

diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 364d5f0..7e3440f 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -31,6 +31,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 


I really don't want to see gic_v3_* header included in common code.



 static inline struct vgic_irq_rank *vgic_get_rank(struct vcpu *v, int rank)
 {
@@ -61,7 +63,7 @@ struct vgic_irq_rank *vgic_rank_irq(struct vcpu *v, unsigned 
int irq)
 return vgic_get_rank(v, rank);
 }

-static void vgic_init_pending_irq(struct pending_irq *p, unsigned int virq)
+void vgic_init_pending_irq(struct pending_irq *p, unsigned int virq)
 {
 INIT_LIST_HEAD(&p->inflight);
 INIT_LIST_HEAD(&p->lr_queue);
@@ -244,10 +246,14 @@ struct vcpu *vgic_get_target_vcpu(struct vcpu *v, 
unsigned int virq)

 static int vgic_get_virq_priority(struct vcpu *v, unsigned int virq)
 {
-struct vgic_irq_rank *rank = vgic_rank_irq(v, virq);
+struct vgic_irq_rank *rank;
 unsigned long flags;
 int priority;

+if ( is_lpi(virq) )
+return vgic_lpi_get_priority(v->domain, virq);


This would benefit some comments to explain why LPI handling is a 
different path.



+
+rank = vgic_rank_irq(v, virq);
 vgic_lock_rank(v, rank, flags);
 priority = rank->priority[virq & INTERRUPT_RANK_MASK];
 vgic_unlock_rank(v, rank, flags);
@@ -446,13 +452,63 @@ bool vgic_to_sgi(struct vcpu *v, register_t sgir, enum 
gic_sgi_mode irqmode,
 return true;
 }

+/*
+ * Holding struct pending_irq's for each possible virtual LPI in each domain
+ * requires too much Xen memory, also a malicious guest could potentially
+ * spam Xen with LPI map requests. We cannot cover those with (guest allocated)
+ * ITS memory, so we use a dynamic scheme of allocating struct pending_irq's
+ * on demand.
+ */


I am afraid this will not prevent a guest to use too much Xen memory. 
Let's imagine the guest is mapping thousands of LPIs but decides to 
never handle them or is slowly. You would allocate pending_irq for each 
LPI, and never release the memory.


If we use dynamic allocation, we need a way to limit the number of LPIs 
received by a guest to avoid memory exhaustion. The only idea I have is 
an artificial limit, but I don't think it is good. Any other ideas?



+struct pending_irq *lpi_to_pending(struct vcpu *v, unsigned int lpi,
+   bool allocate)
+{
+struct lpi_pending_irq *lpi_irq, *empty = NULL;
+
+spin_lock(&v->arch.vgic.pending_lpi_list_lock);
+list_for_each_entry(lpi_irq, &v->arch.vgic.pending_lpi_list, entry)
+{
+if ( lpi_irq->pirq.irq == lpi )
+{
+spin_unlock(&v->arch.vgic.pending_lpi_list_lock);
+return &lpi_irq->pirq;
+}
+
+if ( lpi_irq->pirq.irq == 0 && !empty )
+empty = lpi_irq;
+}
+
+if ( !allocate )
+{
+spin_unlock(&v->a

Re: [Xen-devel] [PATCH] x86/asm: Use ASM_FLAG_OUT() to simplify atomic and bitop stubs

[Jan Beulich]

>>> On 15.02.17 at 17:53,  wrote:
> bitops.h cannot include asm_defns.h, because the static inlines in cpumasks.h
> result in forward declarations of the bitops.h contents.  Move 
> ASM_FLAG_OUT()
> to a new asm/compiler.h to compensate.
> 
> While making changes, switch bool_t to bool and use named asm parameters.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 



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

Re: [Xen-devel] RFC v2: Scope of Vulnerabilities for which XSAs are issued

[Jan Beulich]

>>> On 15.02.17 at 17:37,  wrote:
> On 15/02/17 09:44, Jan Beulich wrote:
> On 14.02.17 at 18:25,  wrote:
>>> 4. The security team will only issue an advisory if there is a known
>>> combination of software in which the vulnerability can be exploited.
>> 
>> Considering the following text, perhaps "may" would end up a little
>> less strict here than "can"? Or add "possibly"? Everything else looks
>> good to me now, fwiw.
> 
> I understand your concern, I think: There are lots of situations that
> won't be black-and-white (because of lack of knowledge), and this makes
> it sound like we won't issue an advisory for any gray areas.
> 
> I don't think in this context "can" and "may" have significantly
> different meanings in English.
> 
> How about:
> 
> 4. The security team will only issue an advisory if there is a known
> combination of software in which the vulnerability can be exploited, or
> a significant risk that such a combination exists.

That sounds fine.

Jan


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

Re: [Xen-devel] [PATCH v3.1 01/18] x86emul: catch exceptions occurring in stubs

[Jan Beulich]

Before adding more use of stubs cloned from decoded guest insns, guard
ourselves against mistakes there: Should an exception (with the
noteworthy exception of #PF) occur inside the stub, forward it to the
guest.

Since the exception fixup table entry can't encode the address of the
faulting insn itself, attach it to the return address instead. This at
once provides a convenient place to hand the exception information
back: The return address is being overwritten by it before branching to
the recovery code.

Take the opportunity and (finally!) add symbol resolution to the
respective log messages (the new one is intentionally not being coded
that way, as it covers stub addresses only, which don't have symbols
associated).

Also take the opportunity and make search_one_extable() static again.

Suggested-by: Andrew Cooper 
Signed-off-by: Jan Beulich 
Reviewed-by: Andrew Cooper 
---
v4: Also print stub bytes when recovering from an exception. Bail after
calling domain_crash().
v3: Also recover from #PF and #DB, eliminating the need for the 2nd
parameter of search_exception_table(). Move its invocation in
do_trap(), as already suggested as option in v1. Use union
stub_exception_token also on the producing side. Shrink the union's
ec field to 16 bits. Only propagate #UD to guest, crash it for all
other unexpected exceptions. Log a message in both cases.
---
There's one possible caveat here: A stub invocation immediately
followed by another instruction having fault revovery attached to it
would not work properly, as the table lookup can only ever find one of
the two entries. Such CALL instructions would therefore need to be
followed by a NOP for disambiguation (even if only a slim chance exists
for the compiler to emit things that way).

Note that the two SIMD related stub invocations in the insn emulator
intentionally don't get adjusted here, as subsequent patches will
replace them anyway.

--- a/xen/arch/x86/extable.c
+++ b/xen/arch/x86/extable.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -62,7 +63,7 @@ void __init sort_exception_tables(void)
 sort_exception_table(__start___pre_ex_table, __stop___pre_ex_table);
 }
 
-unsigned long
+static unsigned long
 search_one_extable(const struct exception_table_entry *first,
const struct exception_table_entry *last,
unsigned long value)
@@ -85,15 +86,91 @@ search_one_extable(const struct exceptio
 }
 
 unsigned long
-search_exception_table(unsigned long addr)
+search_exception_table(const struct cpu_user_regs *regs)
 {
-const struct virtual_region *region = find_text_region(addr);
+const struct virtual_region *region = find_text_region(regs->rip);
+unsigned long stub = this_cpu(stubs.addr);
 
 if ( region && region->ex )
-return search_one_extable(region->ex, region->ex_end - 1, addr);
+return search_one_extable(region->ex, region->ex_end - 1, regs->rip);
+
+if ( regs->rip >= stub + STUB_BUF_SIZE / 2 &&
+ regs->rip < stub + STUB_BUF_SIZE &&
+ regs->rsp > (unsigned long)regs &&
+ regs->rsp < (unsigned long)get_cpu_info() )
+{
+unsigned long retptr = *(unsigned long *)regs->rsp;
+
+region = find_text_region(retptr);
+retptr = region && region->ex
+ ? search_one_extable(region->ex, region->ex_end - 1, retptr)
+ : 0;
+if ( retptr )
+{
+/*
+ * Put trap number and error code on the stack (in place of the
+ * original return address) for recovery code to pick up.
+ */
+union stub_exception_token token = {
+.fields.ec = regs->error_code,
+.fields.trapnr = regs->entry_vector,
+};
+
+*(unsigned long *)regs->rsp = token.raw;
+return retptr;
+}
+}
+
+return 0;
+}
+
+#ifndef NDEBUG
+static int __init stub_selftest(void)
+{
+static const struct {
+uint8_t opc[4];
+uint64_t rax;
+union stub_exception_token res;
+} tests[] __initconst = {
+{ .opc = { 0x0f, 0xb9, 0xc3, 0xc3 }, /* ud1 */
+  .res.fields.trapnr = TRAP_invalid_op },
+{ .opc = { 0x90, 0x02, 0x00, 0xc3 }, /* nop; add (%rax),%al */
+  .rax = 0x0123456789abcdef,
+  .res.fields.trapnr = TRAP_gp_fault },
+{ .opc = { 0x02, 0x04, 0x04, 0xc3 }, /* add (%rsp,%rax),%al */
+  .rax = 0xfedcba9876543210,
+  .res.fields.trapnr = TRAP_stack_error },
+};
+unsigned long addr = this_cpu(stubs.addr) + STUB_BUF_SIZE / 2;
+unsigned int i;
+
+for ( i = 0; i < ARRAY_SIZE(tests); ++i )
+{
+uint8_t *ptr = map_domain_page(_mfn(this_cpu(stubs.mfn))) +
+   (addr & ~PAGE_MASK);
+unsigned long res = ~0;
+
+memset(ptr, 0xcc, STUB_BUF_SIZE / 2);
+memcpy(ptr, tests[i].opc, ARRAY_SIZE(tests[i].opc));
+un

[Xen-devel] [PATCH] x86/asm: Use ASM_FLAG_OUT() to simplify atomic and bitop stubs

[Andrew Cooper]

bitops.h cannot include asm_defns.h, because the static inlines in cpumasks.h
result in forward declarations of the bitops.h contents.  Move ASM_FLAG_OUT()
to a new asm/compiler.h to compensate.

While making changes, switch bool_t to bool and use named asm parameters.

No functional change.

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

v2:
 * Move ASM_FLAG_OUT() to xen/compiler.h rather than introducing
   asm-x86/compiler.h
 * Drop a lot of the commit message.
---
 xen/include/asm-x86/asm_defns.h |  6 ---
 xen/include/asm-x86/atomic.h| 64 ---
 xen/include/asm-x86/bitops.h| 85 ++---
 xen/include/xen/compiler.h  |  6 +++
 4 files changed, 58 insertions(+), 103 deletions(-)

diff --git a/xen/include/asm-x86/asm_defns.h b/xen/include/asm-x86/asm_defns.h
index 220ae2e..f1c6fa1 100644
--- a/xen/include/asm-x86/asm_defns.h
+++ b/xen/include/asm-x86/asm_defns.h
@@ -413,10 +413,4 @@ static always_inline void stac(void)
 #define REX64_PREFIX "rex64/"
 #endif
 
-#ifdef __GCC_ASM_FLAG_OUTPUTS__
-# define ASM_FLAG_OUT(yes, no) yes
-#else
-# define ASM_FLAG_OUT(yes, no) no
-#endif
-
 #endif /* __X86_ASM_DEFNS_H__ */
diff --git a/xen/include/asm-x86/atomic.h b/xen/include/asm-x86/atomic.h
index ef7e70b..d2a311c 100644
--- a/xen/include/asm-x86/atomic.h
+++ b/xen/include/asm-x86/atomic.h
@@ -133,17 +133,13 @@ static inline int atomic_sub_return(int i, atomic_t *v)
 
 static inline int atomic_sub_and_test(int i, atomic_t *v)
 {
-bool_t c;
-
-#ifdef __GCC_ASM_FLAG_OUTPUTS__
-asm volatile ( "lock; subl %2,%0"
-   : "+m" (*(volatile int *)&v->counter), "=@ccz" (c)
-   : "ir" (i) : "memory" );
-#else
-asm volatile ( "lock; subl %2,%0; setz %1"
-   : "+m" (*(volatile int *)&v->counter), "=qm" (c)
-   : "ir" (i) : "memory" );
-#endif
+bool c;
+
+asm volatile ( "lock; subl %[i], %[counter]\n\t"
+   ASM_FLAG_OUT(, "setz %[zf]\n\t")
+   : [counter] "+m" (*(volatile int *)&v->counter),
+ [zf] ASM_FLAG_OUT("=@ccz", "=qm") (c)
+   : [i] "ir" (i) : "memory" );
 
 return c;
 }
@@ -163,17 +159,13 @@ static inline int atomic_inc_return(atomic_t *v)
 
 static inline int atomic_inc_and_test(atomic_t *v)
 {
-bool_t c;
+bool c;
 
-#ifdef __GCC_ASM_FLAG_OUTPUTS__
-asm volatile ( "lock; incl %0"
-   : "+m" (*(volatile int *)&v->counter), "=@ccz" (c)
-   :: "memory" );
-#else
-asm volatile ( "lock; incl %0; setz %1"
-   : "+m" (*(volatile int *)&v->counter), "=qm" (c)
+asm volatile ( "lock; incl %[counter]\n\t"
+   ASM_FLAG_OUT(, "setz %[zf]\n\t")
+   : [counter] "+m" (*(volatile int *)&v->counter),
+ [zf] ASM_FLAG_OUT("=@ccz", "=qm") (c)
:: "memory" );
-#endif
 
 return c;
 }
@@ -193,34 +185,26 @@ static inline int atomic_dec_return(atomic_t *v)
 
 static inline int atomic_dec_and_test(atomic_t *v)
 {
-bool_t c;
+bool c;
 
-#ifdef __GCC_ASM_FLAG_OUTPUTS__
-asm volatile ( "lock; decl %0"
-   : "+m" (*(volatile int *)&v->counter), "=@ccz" (c)
+asm volatile ( "lock; decl %[counter]\n\t"
+   ASM_FLAG_OUT(, "setz %[zf]\n\t")
+   : [counter] "+m" (*(volatile int *)&v->counter),
+ [zf] ASM_FLAG_OUT("=@ccz", "=qm") (c)
:: "memory" );
-#else
-asm volatile ( "lock; decl %0; setz %1"
-   : "+m" (*(volatile int *)&v->counter), "=qm" (c)
-   :: "memory" );
-#endif
 
 return c;
 }
 
 static inline int atomic_add_negative(int i, atomic_t *v)
 {
-bool_t c;
-
-#ifdef __GCC_ASM_FLAG_OUTPUTS__
-asm volatile ( "lock; addl %2,%0"
-   : "+m" (*(volatile int *)&v->counter), "=@ccs" (c)
-   : "ir" (i) : "memory" );
-#else
-asm volatile ( "lock; addl %2,%0; sets %1"
-   : "+m" (*(volatile int *)&v->counter), "=qm" (c)
-   : "ir" (i) : "memory" );
-#endif
+bool c;
+
+asm volatile ( "lock; addl %[i], %[counter]\n\t"
+   ASM_FLAG_OUT(, "sets %[sf]\n\t")
+   : [counter] "+m" (*(volatile int *)&v->counter),
+ [sf] ASM_FLAG_OUT("=@ccs", "=qm") (c)
+   : [i] "ir" (i) : "memory" );
 
 return c;
 }
diff --git a/xen/include/asm-x86/bitops.h b/xen/include/asm-x86/bitops.h
index 0f18645..440abb7 100644
--- a/xen/include/asm-x86/bitops.h
+++ b/xen/include/asm-x86/bitops.h
@@ -144,13 +144,10 @@ static inline int test_and_set_bit(int nr, volatile void 
*addr)
 {
 int oldbit;
 
-#ifdef __GCC_ASM_FLAG_OUTPUTS__
-asm volatile ( "lock; btsl %2,%1"
-   : "=@ccc" (oldbit), "+m" (ADDR) : "Ir" (nr) : "memory" );
-#else
-asm volatile ( "lock; btsl %2,%1\n\tsbbl %0,%0"
-   : "=r

Re: [Xen-devel] [PATCH v8 01/24] docs: create Cache Allocation Technology (CAT) and Code and Data Prioritization (CDP) feature document

[Konrad Rzeszutek Wilk]

On Wed, Feb 15, 2017 at 04:49:16PM +0800, Yi Sun wrote:
> This patch creates CAT and CDP feature document in doc/features/. It describes
> key points to implement L3 CAT/CDP and L2 CAT which is described in details in
> Intel SDM "INTEL® RESOURCE DIRECTOR TECHNOLOGY (INTEL® RDT) ALLOCATION 
> FEATURES".
> 
> Signed-off-by: Yi Sun 
> ---
> v8:
> - change revision info.
> - add content int 'Areas for improvement'.

Reviewed-by: Konrad Rzeszutek Wilk 

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

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

[Konrad Rzeszutek Wilk]

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

Reviewed-by: Konrad Rzeszutek Wilk 

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

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

[Konrad Rzeszutek Wilk]

> >> We could split out the following git repos: mini-os, osstest, raisin,
> >> livepatch-build-tools, xtf

, xentesttools/*
> >> In terms of contributions per release, there is more activity than Windows
> >> PV Drivers, which are a separate project.
> > 
> > I see what you meant now. That could be OK.
> 
> I think that is the cleanest and simplest approach in my view and would 
> unblock this proposal.

/me nods.
> 
> With this in mind, do you think, this would work?

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

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

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

[Konrad Rzeszutek Wilk]

On Wed, Nov 23, 2016 at 12:20:45PM +, Lars Kurth wrote:
> Contains items that at some point need to be addressed.
> The items do not directly affect governance.pandoc
> 
> Signed-off-by: Lars Kurth 

Reviewed-by: Konrad Rzeszutek Wilk 

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

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

Re: [Xen-devel] [PATCH 07/28] ARM: GICv3 ITS: introduce device mapping

[Julien Grall]

Hi Andre,

On 30/01/17 18:31, Andre Przywara wrote:

+static int its_send_cmd_mapd(struct host_its *its, uint32_t deviceid,
+ int size, uint64_t itt_addr, bool valid)
+{
+uint64_t cmd[4];
+
+cmd[0] = GITS_CMD_MAPD | ((uint64_t)deviceid << 32);
+cmd[1] = size & GENMASK(4, 0);
+cmd[2] = itt_addr & GENMASK(51, 8);
+if ( valid )
+cmd[2] |= GITS_VALID_BIT;
+cmd[3] = 0x00;
+
+return its_send_command(its, cmd);
+}
+
 /* Set up the (1:1) collection mapping for the given host CPU. */
 int gicv3_its_setup_collection(int cpu)
 {
@@ -293,6 +310,7 @@ int gicv3_its_init(struct host_its *hw_its)
 reg = readq_relaxed(hw_its->its_base + GITS_TYPER);
 if ( reg & GITS_TYPER_PTA )
 hw_its->flags |= HOST_ITS_USES_PTA;
+hw_its->itte_size = GITS_TYPER_ITT_SIZE(reg);


The GITS_TYPER.ITT_entry_size indicates the number of bytes minus one. 
So you would have to add a + 1.


I would add it in the GITS_TYPER_ITT_SIZE macro to simplify it.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] RFC v2: Scope of Vulnerabilities for which XSAs are issued

[George Dunlap]

On 15/02/17 09:44, Jan Beulich wrote:
 On 14.02.17 at 18:25,  wrote:
>> 4. The security team will only issue an advisory if there is a known
>> combination of software in which the vulnerability can be exploited.
> 
> Considering the following text, perhaps "may" would end up a little
> less strict here than "can"? Or add "possibly"? Everything else looks
> good to me now, fwiw.

I understand your concern, I think: There are lots of situations that
won't be black-and-white (because of lack of knowledge), and this makes
it sound like we won't issue an advisory for any gray areas.

I don't think in this context "can" and "may" have significantly
different meanings in English.

How about:

4. The security team will only issue an advisory if there is a known
combination of software in which the vulnerability can be exploited, or
a significant risk that such a combination exists.

 -George


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

Re: [Xen-devel] [PATCH RFC V2 7/7] COLO-Proxy: Use socket to get checkpoint event.

[Konrad Rzeszutek Wilk]

On Wed, Feb 15, 2017 at 05:54:33PM +0800, Zhang Chen wrote:
> We use kernel colo proxy's way to get the checkpoint event
> from qemu colo-compare.
> Qemu colo-compare need add a API to support this(I will add this in qemu).
> 
> Signed-off-by: Zhang Chen 
> ---
>  tools/libxl/libxl_colo.h |  2 +
>  tools/libxl/libxl_colo_proxy.c   | 84 
> +---
>  tools/libxl/libxl_colo_restore.c | 11 --
>  tools/libxl/libxl_colo_save.c| 22 +++
>  tools/libxl/libxl_nic.c  |  4 ++
>  tools/libxl/libxl_types.idl  |  4 +-
>  tools/libxl/xl_cmdimpl.c |  4 ++
>  7 files changed, 113 insertions(+), 18 deletions(-)
> 
> diff --git a/tools/libxl/libxl_colo.h b/tools/libxl/libxl_colo.h
> index 4746d8c..6c01b55 100644
> --- a/tools/libxl/libxl_colo.h
> +++ b/tools/libxl/libxl_colo.h
> @@ -69,6 +69,8 @@ struct libxl__colo_proxy_state {
>   *  False means use kernel colo proxy.
>   */
>  bool is_userspace_proxy;
> +const char *checkpoint_host;
> +const char *checkpoint_port;
>  };
>  
>  struct libxl__colo_save_state {
> diff --git a/tools/libxl/libxl_colo_proxy.c b/tools/libxl/libxl_colo_proxy.c
> index dd902fc..9d21cf1 100644
> --- a/tools/libxl/libxl_colo_proxy.c
> +++ b/tools/libxl/libxl_colo_proxy.c
> @@ -18,6 +18,9 @@
>  #include "libxl_internal.h"
>  
>  #include 
> +#include 
> +#include 
> +#include 
>  
>  /* Consistent with the new COLO netlink channel in kernel side */
>  #define NETLINK_COLO 28
> @@ -76,6 +79,26 @@ static int colo_proxy_send(libxl__colo_proxy_state *cps, 
> uint8_t *buff,
>  return ret;
>  }
>  
> +static int colo_userspace_proxy_recv(libxl__colo_proxy_state *cps,
> + char *buff,
> + unsigned int timeout_us)
> +{
> +struct timeval tv;
> +int ret;
> +
> +STATE_AO_GC(cps->ao);
> +
> +if (timeout_us) {
> +tv.tv_sec = timeout_us / 100;
> +tv.tv_usec = timeout_us % 100;
> +setsockopt(cps->sock_fd, SOL_SOCKET, SO_RCVTIMEO, &tv, sizeof(tv));
> +}
> +
> +ret = recv(cps->sock_fd, buff, sizeof(buff),0);
> +
> +return ret;
> +}
> +
>  /* error: return -1, otherwise return 0 */
>  static int64_t colo_proxy_recv(libxl__colo_proxy_state *cps, uint8_t **buff,
> unsigned int timeout_us)
> @@ -153,8 +176,45 @@ int colo_proxy_setup(libxl__colo_proxy_state *cps)
>  STATE_AO_GC(cps->ao);
>  
>  /* If enable userspace proxy mode, we don't need setup kernel proxy */
> -if (cps->is_userspace_proxy)
> +if (cps->is_userspace_proxy) {
> +struct sockaddr_in addr;
> +int port;
> +char recvbuff[1024];
> +
> +memset(&addr, 0, sizeof(addr));
> +port = atoi(cps->checkpoint_port);
> +addr.sin_family = AF_INET;
> +addr.sin_port = htons(port);
> +addr.sin_addr.s_addr = inet_addr(cps->checkpoint_host);
> +
> +skfd = socket(AF_INET, SOCK_STREAM, 0);
> +if (skfd < 0) {
> +LOGD(ERROR, ao->domid, "can not create a TCP socket: %s",
> + strerror(errno));
> +goto out;
> +}
> +
> +cps->sock_fd = skfd;
> +
> +if (connect(skfd, (struct sockaddr *)&addr, sizeof(addr)) < 0) {
> +LOGD(ERROR, ao->domid, "connect error");
> +goto out;
> +}
> +
> +char sendbuf[] = "COLO_USERSPACE_PROXY_INIT";

Um, could you move it right around 'char recvbuff' ?

> +ret = send(skfd, sendbuf, strlen(sendbuf),0);
> +if (ret < 0)
> +goto out;
> +
> +ret = colo_userspace_proxy_recv(cps, recvbuff, 50);

That 50 looks like a good candidate for a #define?

> +if (size < 0) {
> +LOGD(ERROR, ao->domid, "Can't recv msg from qemu colo-compare: 
> %s",
> + strerror(errno));
> +goto out;
> +}
> +
>  return 0;
> +}
>  
>  skfd = socket(PF_NETLINK, SOCK_RAW, NETLINK_COLO);
>  if (skfd < 0) {
> @@ -247,8 +307,11 @@ void colo_proxy_preresume(libxl__colo_proxy_state *cps)
>   * If enable userspace proxy mode,
>   * we don't need preresume kernel proxy
>   */
> -if (cps->is_userspace_proxy)
> +if (cps->is_userspace_proxy) {
> +char sendbuf[] = "COLO_CHECKPOINT";
> +send(cps->sock_fd, sendbuf, strlen(sendbuf),0);
>  return;
> +}
>  
>  colo_proxy_send(cps, NULL, 0, COLO_CHECKPOINT);
>  /* TODO: need to handle if the call fails... */
> @@ -277,16 +340,25 @@ int colo_proxy_checkpoint(libxl__colo_proxy_state *cps,
>  struct nlmsghdr *h;
>  struct colo_msg *m;
>  int ret = -1;
> +char recvbuff[1024];
>  
>  STATE_AO_GC(cps->ao);
>  
>  /*
> - * enable userspace proxy mode, tmp sleep.
> - * then we will add qemu API support this func.
> + * enable userspace proxy mode.
> + * Then we will add qemu API support for this fu

Re: [Xen-devel] Unshared IOMMU issues

[Jan Beulich]

>>> On 15.02.17 at 16:52,  wrote:
> I think, but I am not 100% sure that we could avoid actions above if
> we would have knowledge about device assignment for particular
> domain before making any updates in P2M.

Well, one could in theory make this work for boot time assigned
devices, but since this won't cover runtime assigned (hotplugged)
ones, I don't think this would gain you anything.

> Could you please suggest me a right way in resolving such problems?

Well, you described what you do (with quite a bit of ARM terminology
I don't understand), but I'm not sure you made explicit what problem(s)
you need to solve. I'm sorry if it's just me not understanding what you
wrote.

Jan


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

Re: [Xen-devel] [PATCH RFC V2 0/7] COLO-Proxy: Make Xen COLO use userspace colo-proxy

[Konrad Rzeszutek Wilk]

On Wed, Feb 15, 2017 at 05:54:26PM +0800, Zhang Chen wrote:
> Because of some reason, We no longer support COLO kernel proxy.
> So we send this patch set to make Xen use userspace colo-proxy in qemu.

How come it is RFC? It looks quite baked?

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

Re: [Xen-devel] [PATCH v8 00/24] Enable L2 Cache Allocation Technology & Refactor psr.c

[Konrad Rzeszutek Wilk]

On Wed, Feb 15, 2017 at 04:49:15PM +0800, Yi Sun wrote:
> Hi all,
> 
> We plan to bring a new PSR (Platform Shared Resource) feature called
> Intel L2 Cache Allocation Technology (L2 CAT) to Xen.
> 
> Besides the L2 CAT implementaion, we refactor the psr.c to make it more
> flexible to add new features and fulfill the principle, open for extension
> but closed for modification. We abstract the general operations of all
> features and encapsulate them into a structure. Then, the development
> of new feature is simple to mainly implement these callback functions.
> 
> The patch set can be found at:
> https://github.com/yisun-git/xen.git l2_cat_v8
> 
> v7:
> - patch 1:
> - change revision info.
> - add content int 'Areas for improvement'.
> - patch 4:
> - remove unused parameter of psr_cpu_prepare.
> - add comments in cpu_fini_work.
> - coding style fix.
> - patch 12:
> - modify 'write_msr' callback function to 'void' because we have to set
>   all features' cbm. When input cos exceeds some features' cos_max, just
>   skip them but not break the iteration.
> - patch 16:
> - modify 'l3_cdp_write_msr' to 'void'.
> - patch 20:
> - modify 'l2_cat_write_msr' to 'void'.


While I appreciate you acting so quickly on the changes it is kind of hard to
review while you repost so quickly.

Please in the future just respond to your patch (say #4)
with an updated patch (v6.1 for example) which would have
the changes requested.

Ditto for #12, #16 and #20.

Unless of course there are some big changes to be done (those
above seem pretty small).

Also you may want to include a legend of which patch has been acked,
reviewed and which needs attention.

Something like:

 a - acked
 r - reviewed-by

 ar  docs: create Cache Allocation Technology (CAT) and Code and Data
 ar  x86: refactor psr: remove L3 CAT/CDP codes.
 ar  x86: refactor psr: implement main data structures.

..snip..
x86: refactor psr: implement get hw info flow for CDP.

And so on. That helps folks figure out which to jump
to.

Or you can say at the description:

PAtch #1->#6 have been Reviewed.

#7-blah need help, etc.

Thanks!

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

Re: [Xen-devel] [PATCH] x86/asm: Use ASM_FLAG_OUT() to simplify atomic and bitop stubs

[Jan Beulich]

>>> On 15.02.17 at 17:00,  wrote:
> On 15/02/17 14:55, Jan Beulich wrote:
> On 15.02.17 at 15:22,  wrote:
>>> bitops.h cannot include asm_defns.h, because the static inlines in 
> cpumasks.h
>>> result in forward declarations of the bitops.h contents.  Move 
> ASM_FLAG_OUT()
>>> to a new asm/compiler.h to compensate.
>>>
>>> While making changes, switch bool_t to bool and use named asm parameters.
>>>
>>> No (intended) functional change.  Without GCC flags, the disassembly is
>>> identical before and after this patch.  With GCC flags however, this patch
>>> seems to cause GCC to make instruction scheduling decisions.
>>>
>>> The first place with significant changes in the disassembly is the the 
> middle
>>> of do_domctl(), which switches from:
>>>
>>> lock decl 0x1d8(%rax)
>>> sete   %r14b
>>> mov$0xffea,%rbx
>>> test   %r14b,%r14b
>>> je 82d0801034d4
>>>
>>> to:
>>>
>>> lock decl 0x1d8(%rax)
>>> mov$0x0,%r14d
>>> mov$0xffea,%rbx
>>> jne82d0801034d4
>>>
>>> avoiding the use of %r14d as an intermediate for calculating the conditional
>>> jump, freeing it up for later use.  As a result, the compiled code is a 
> little
>>> more efficient and smaller overall.
>> I have to admit that I find this rather surprising, especially since
>> (leaving the naming of the asm() operands aside) the preprocessed
>> source should not change afaict. It being unexpected I think calls
>> for better understanding what's going on here.
> 
> I presume you are happy now given your other discovery?

Yes, albeit the commit message may want refining a little.

>>> --- a/xen/include/asm-x86/config.h
>>> +++ b/xen/include/asm-x86/config.h
>>> @@ -107,6 +107,7 @@ extern unsigned char boot_edid_info[128];
>>>  #define asmlinkage
>>>  
>>>  #include 
>>> +#include 
>> Why here? You need it in bitops.h and maybe (it's not really used
>> there) asm_defns.h only for now.
> 
> I am looking to avoid duplicating the definition, and this seemed like
> an appropriate place to live.
> 
> Would you instead prefer me to duplicate it in bitops?

Duplicate what? The macro? No. The new header is fine, just that
I'd rather not see it included from config.h. And btw., other than
when Sergey wanted to put in a non-x86 header, instead of
introducing asm/compiler.h here, I think I would then agree to
simply put it in xen/compiler.h and be done once and for all.

Jan


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

Re: [Xen-devel] [PATCH v2 00/10] xen: credit2: improve style, and tracing; fix two bugs

[George Dunlap]

On Thu, Feb 9, 2017 at 1:58 PM, Dario Faggioli
 wrote:
> Hello,
>
> This series contains mostly style or cosmetic fixes for Credit2, with the
> following two exceptions:
>  - 2 actual fixes for (not so severe) behavioral bugs (patches 5 and 6);
>  - some tracing improvements (last 3 patches).
>
> More info on the specific changelogs.
>
> This is basically a resubmission of
> https://lists.xen.org/archives/html/xen-devel/2017-01/msg02837.html
>
> but with:
>  - 2 patches (the first two) that were not here before, and are now
>upon request from George of rebasind and resending all the scheduler
>patches I have outstanding in one series;
>  - all rebased on current staging.
>
> The series is also available as a git tree here:
>
>   git://xenbits.xen.org/people/dariof/xen.git 
> rel/sched/credit2-style-tracing-accounting-v
>   https://travis-ci.org/xen-project/xen/builds/199958381
>   (there are some clang failures, but they look unrelated).
>
> Thanks and Regards,
> Dario
>
> ---
> Dario Faggioli (10):
>   xen: sched: harmonize debug dump output among schedulers.
>   xen: credit2: clear bit instead of skip step in runq_tickle()
>   xen: credit2: improve comments' style and definition of CSFLAG-s

I've pushed these three.  I would have pushed patch 7 and 8 as well
(with the fix to patch 7), but they didn't apply without the other
patches.

 -George

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