[Xen-devel] [distros-debian-squeeze test] 66621: tolerable trouble: blocked/broken

[Platform Team regression test user]

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

Failures :-/ but no regressions.

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

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

baseline version:
 flight   66561

jobs:
 build-amd64  broken  
 build-armhf  broken  
 build-i386   broken  
 build-amd64-pvopsbroken  
 build-armhf-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-amd64-squeeze-netboot-pygrubblocked 
 test-amd64-i386-amd64-squeeze-netboot-pygrub blocked 
 test-amd64-amd64-i386-squeeze-netboot-pygrub blocked 
 test-amd64-i386-i386-squeeze-netboot-pygrub  blocked 



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

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

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


Push not applicable.


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

[Xen-devel] [PATCH v2 2/2] tools: make xenstore domain easy configurable

[Juergen Gross]

Add configuration entries to sysconfig.xencommons for selection of the
xenstore type (domain or daemon) and start the selected xenstore
service via a script called from sysvinit or systemd.

Signed-off-by: Juergen Gross 
---
V2: add .gitignore entry for launch-xenstore
---
 .gitignore |  1 +
 tools/configure|  2 +-
 tools/hotplug/Linux/Makefile   |  1 +
 tools/hotplug/Linux/init.d/sysconfig.xencommons.in | 42 ++-
 tools/hotplug/Linux/init.d/xencommons.in   | 35 ++---
 tools/hotplug/Linux/launch-xenstore.in | 84 ++
 tools/hotplug/Linux/systemd/xenstored.service.in   |  8 +--
 7 files changed, 131 insertions(+), 42 deletions(-)
 create mode 100644 tools/hotplug/Linux/launch-xenstore.in

diff --git a/.gitignore b/.gitignore
index e019f2e..0e5e20c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -156,6 +156,7 @@ tools/hotplug/Linux/init.d/xen-watchdog
 tools/hotplug/Linux/init.d/xencommons
 tools/hotplug/Linux/init.d/xendomains
 tools/hotplug/Linux/init.d/xendriverdomain
+tools/hotplug/Linux/launch-xenstore
 tools/hotplug/Linux/systemd/*.conf
 tools/hotplug/Linux/systemd/*.mount
 tools/hotplug/Linux/systemd/*.socket
diff --git a/tools/configure b/tools/configure
index a04fe3f..45529eb 100755
--- a/tools/configure
+++ b/tools/configure
@@ -2410,7 +2410,7 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu
 
 
 
-ac_config_files="$ac_config_files ../config/Tools.mk 
hotplug/FreeBSD/rc.d/xencommons hotplug/FreeBSD/rc.d/xendriverdomain 
hotplug/Linux/init.d/sysconfig.xencommons 
hotplug/Linux/init.d/sysconfig.xendomains hotplug/Linux/init.d/xen-watchdog 
hotplug/Linux/init.d/xencommons hotplug/Linux/init.d/xendomains 
hotplug/Linux/init.d/xendriverdomain hotplug/Linux/vif-setup 
hotplug/Linux/xen-hotplug-common.sh hotplug/Linux/xendomains 
hotplug/NetBSD/rc.d/xencommons hotplug/NetBSD/rc.d/xendriverdomain 
libxl/xenlight.pc.in libxl/xlutil.pc.in ocaml/xenstored/oxenstored.conf"
+ac_config_files="$ac_config_files ../config/Tools.mk 
hotplug/FreeBSD/rc.d/xencommons hotplug/FreeBSD/rc.d/xendriverdomain 
hotplug/Linux/init.d/sysconfig.xencommons 
hotplug/Linux/init.d/sysconfig.xendomains hotplug/Linux/init.d/xen-watchdog 
hotplug/Linux/init.d/xencommons hotplug/Linux/init.d/xendomains 
hotplug/Linux/init.d/xendriverdomain hotplug/Linux/launch-xenstore 
hotplug/Linux/vif-setup hotplug/Linux/xen-hotplug-common.sh 
hotplug/Linux/xendomains hotplug/NetBSD/rc.d/xencommons 
hotplug/NetBSD/rc.d/xendriverdomain libxl/xenlight.pc.in libxl/xlutil.pc.in 
ocaml/xenstored/oxenstored.conf"
 
 ac_config_headers="$ac_config_headers config.h"
 
diff --git a/tools/hotplug/Linux/Makefile b/tools/hotplug/Linux/Makefile
index 6d6ccee..29280cb 100644
--- a/tools/hotplug/Linux/Makefile
+++ b/tools/hotplug/Linux/Makefile
@@ -30,6 +30,7 @@ XEN_SCRIPTS += block-drbd-probe
 XEN_SCRIPTS += block-dummy
 XEN_SCRIPTS += $(XEN_SCRIPTS-y)
 XEN_SCRIPTS += colo-proxy-setup
+XEN_SCRIPTS += launch-xenstore
 
 SUBDIRS-$(CONFIG_SYSTEMD) += systemd
 
diff --git a/tools/hotplug/Linux/init.d/sysconfig.xencommons.in 
b/tools/hotplug/Linux/init.d/sysconfig.xencommons.in
index c27a476..cc8185c 100644
--- a/tools/hotplug/Linux/init.d/sysconfig.xencommons.in
+++ b/tools/hotplug/Linux/init.d/sysconfig.xencommons.in
@@ -6,12 +6,24 @@
 #XENCONSOLED_TRACE=[none|guest|hv|all]
 
 ## Type: string
+## Default: daemon
+#
+# Select type of xentore service.
+#
+# This can be either of:
+#  * daemon
+#  * domain
+#
+# Changing this requires a reboot to take effect.
+#
+#XENSTORETYPE=daemon
+
+## Type: string
 ## Default: xenstored
 #
 # Select xenstore implementation, this can be either
-# of these below. If using systemd it's preferred that you
-# just edit the xenstored.service unit file and change
-# the XENSTORED variable there.
+# of these below.
+# Only evaluated if XENSTORETYPE is "daemon".
 #
 # This can be either of:
 #  * @sbindir@/oxenstored
@@ -26,21 +38,45 @@
 # Additional commandline arguments to start xenstored,
 # like "--trace-file @XEN_LOG_DIR@/xenstored-trace.log"
 # See "@sbindir@/xenstored --help" for possible options.
+# Only evaluated if XENSTORETYPE is "daemon".
 XENSTORED_ARGS=
 
 ## Type: string
 ## Default: Not defined, tracing off
 #
 # Log xenstored messages
+# Only evaluated if XENSTORETYPE is "daemon".
 #XENSTORED_TRACE=[yes|on|1]
 
 ## Type: string
 ## Default: "@XEN_LIB_STORED@"
 #
 # Running xenstored on XENSTORED_ROOTDIR
+# Only evaluated if XENSTORETYPE is "daemon".
 #XENSTORED_ROOTDIR=@XEN_LIB_STORED@
 
 ## Type: string
+## Default: @LIBEXEC@/boot/xenstore-stubdom.gz
+#
+# xenstore domain kernel.
+# Only evaluated if XENSTORETYPE is "domain".
+#XENSTORE_DOMAIN_KERNEL=@LIBEXEC@/boot/xenstore-stubdom.gz
+
+## Type: integer
+## Default: 8
+#
+# xenstore domain memory size in MiB.
+# Only evaluated if XENSTORETYPE is "domain".
+#XENSTORE_DOMAIN_SIZE=8
+
+## Type: string
+## Default: ""
+#
+# Additional arguments f

[Xen-devel] [PATCH v2 1/2] tools: remove systemd xenstore socket definitions

[Juergen Gross]

On a system with systemd the xenstore sockets are created via systemd.
Remove the related configuration files in order to be able to decide
at runtime whether the sockets should be created or not. This will
enable Xen to start xenstore either via a daemon or via a stub domain.

Signed-off-by: Juergen Gross 
---
 tools/configure|   2 +-
 tools/hotplug/Linux/systemd/Makefile   |   5 -
 tools/hotplug/Linux/systemd/xenstored.service.in   |   6 +-
 tools/hotplug/Linux/systemd/xenstored.socket.in|  13 --
 tools/hotplug/Linux/systemd/xenstored_ro.socket.in |  13 --
 tools/ocaml/xenstored/Makefile |  10 +-
 tools/ocaml/xenstored/systemd.ml   |  17 ---
 tools/ocaml/xenstored/systemd.mli  |  24 
 tools/ocaml/xenstored/systemd_stubs.c  | 153 -
 tools/ocaml/xenstored/utils.ml |  21 +--
 tools/ocaml/xenstored/xenstored.ml |   2 -
 tools/xenstore/Makefile|   3 -
 tools/xenstore/xenstored_core.c| 113 +--
 13 files changed, 13 insertions(+), 369 deletions(-)
 delete mode 100644 tools/hotplug/Linux/systemd/xenstored.socket.in
 delete mode 100644 tools/hotplug/Linux/systemd/xenstored_ro.socket.in
 delete mode 100644 tools/ocaml/xenstored/systemd.ml
 delete mode 100644 tools/ocaml/xenstored/systemd.mli
 delete mode 100644 tools/ocaml/xenstored/systemd_stubs.c

diff --git a/tools/configure b/tools/configure
index 5b5dcce..a04fe3f 100755
--- a/tools/configure
+++ b/tools/configure
@@ -9670,7 +9670,7 @@ fi
 
 if test "x$systemd" = "xy"; then :
 
-ac_config_files="$ac_config_files hotplug/Linux/systemd/proc-xen.mount 
hotplug/Linux/systemd/var-lib-xenstored.mount 
hotplug/Linux/systemd/xen-init-dom0.service 
hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service 
hotplug/Linux/systemd/xen-watchdog.service 
hotplug/Linux/systemd/xenconsoled.service 
hotplug/Linux/systemd/xendomains.service 
hotplug/Linux/systemd/xendriverdomain.service 
hotplug/Linux/systemd/xenstored.service hotplug/Linux/systemd/xenstored.socket 
hotplug/Linux/systemd/xenstored_ro.socket"
+ac_config_files="$ac_config_files hotplug/Linux/systemd/proc-xen.mount 
hotplug/Linux/systemd/var-lib-xenstored.mount 
hotplug/Linux/systemd/xen-init-dom0.service 
hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service 
hotplug/Linux/systemd/xen-watchdog.service 
hotplug/Linux/systemd/xenconsoled.service 
hotplug/Linux/systemd/xendomains.service 
hotplug/Linux/systemd/xendriverdomain.service 
hotplug/Linux/systemd/xenstored.service"
 
 
 fi
diff --git a/tools/hotplug/Linux/systemd/Makefile 
b/tools/hotplug/Linux/systemd/Makefile
index 558e459..7d24bbe 100644
--- a/tools/hotplug/Linux/systemd/Makefile
+++ b/tools/hotplug/Linux/systemd/Makefile
@@ -6,9 +6,6 @@ XEN_SYSTEMD_MODULES = xen.conf
 XEN_SYSTEMD_MOUNT =  proc-xen.mount
 XEN_SYSTEMD_MOUNT += var-lib-xenstored.mount
 
-XEN_SYSTEMD_SOCKET  = xenstored.socket
-XEN_SYSTEMD_SOCKET += xenstored_ro.socket
-
 XEN_SYSTEMD_SERVICE  = xenstored.service
 XEN_SYSTEMD_SERVICE += xenconsoled.service
 XEN_SYSTEMD_SERVICE += xen-qemu-dom0-disk-backend.service
@@ -19,7 +16,6 @@ XEN_SYSTEMD_SERVICE += xendriverdomain.service
 
 ALL_XEN_SYSTEMD =  $(XEN_SYSTEMD_MODULES)  \
$(XEN_SYSTEMD_MOUNT)\
-   $(XEN_SYSTEMD_SOCKET)   \
$(XEN_SYSTEMD_SERVICE)
 
 .PHONY: all
@@ -38,7 +34,6 @@ install: $(ALL_XEN_SYSTEMD)
$(INSTALL_DIR) $(DESTDIR)$(XEN_SYSTEMD_DIR)
[ -d $(DESTDIR)$(XEN_SYSTEMD_MODULES_LOAD) ] || \
$(INSTALL_DIR) $(DESTDIR)$(XEN_SYSTEMD_MODULES_LOAD)
-   $(INSTALL_DATA) *.socket $(DESTDIR)$(XEN_SYSTEMD_DIR)
$(INSTALL_DATA) *.service $(DESTDIR)$(XEN_SYSTEMD_DIR)
$(INSTALL_DATA) *.mount $(DESTDIR)$(XEN_SYSTEMD_DIR)
$(INSTALL_DATA) *.conf $(DESTDIR)$(XEN_SYSTEMD_MODULES_LOAD)
diff --git a/tools/hotplug/Linux/systemd/xenstored.service.in 
b/tools/hotplug/Linux/systemd/xenstored.service.in
index a5f836b..4dff683 100644
--- a/tools/hotplug/Linux/systemd/xenstored.service.in
+++ b/tools/hotplug/Linux/systemd/xenstored.service.in
@@ -1,13 +1,14 @@
 [Unit]
 Description=The Xen xenstore
-Requires=xenstored_ro.socket xenstored.socket proc-xen.mount 
var-lib-xenstored.mount
+Requires=proc-xen.mount var-lib-xenstored.mount
 After=proc-xen.mount var-lib-xenstored.mount
 Before=libvirtd.service libvirt-guests.service
 RefuseManualStop=true
 ConditionPathExists=/proc/xen/capabilities
 
 [Service]
-Type=notify
+Type=oneshot
+RemainAfterExit=true
 KillMode=none
 Environment=XENSTORED_ARGS=
 Environment=XENSTORED=@XENSTORED@
@@ -19,6 +20,5 @@ ExecStart=/bin/sh -c "exec $XENSTORED --no-fork 
$XENSTORED_ARGS"
 
 [Install]
 WantedBy=multi-user.target
-Also=xenstored_ro.socket xenstored.socket
 Also=proc-xen.mount
 Also=var-lib-xenstored.mount
diff --git a/tools/hotplug/Linux/sy

[Xen-devel] [PATCH v2 0/2] tools: make xenstore domain/daemon configurable

[Juergen Gross]

Add a configuration option to /etc/sysconfig/xencommons to let the
user configure whether he wants to start xenstore service as a daemon
or as a stubdom.

Changes in V2:
- move service type modification form patch 2 to patch 1 as implied by
  Ross Lagerwall (at least I guess so)
- add .gitignore entry for launch-xenstore

Juergen Gross (2):
  tools: remove systemd xenstore socket definitions
  tools: make xenstore domain easy configurable

 .gitignore |   1 +
 tools/configure|   4 +-
 tools/hotplug/Linux/Makefile   |   1 +
 tools/hotplug/Linux/init.d/sysconfig.xencommons.in |  42 +-
 tools/hotplug/Linux/init.d/xencommons.in   |  35 +
 tools/hotplug/Linux/launch-xenstore.in |  84 +++
 tools/hotplug/Linux/systemd/Makefile   |   5 -
 tools/hotplug/Linux/systemd/xenstored.service.in   |  14 +-
 tools/hotplug/Linux/systemd/xenstored.socket.in|  13 --
 tools/hotplug/Linux/systemd/xenstored_ro.socket.in |  13 --
 tools/ocaml/xenstored/Makefile |  10 +-
 tools/ocaml/xenstored/systemd.ml   |  17 ---
 tools/ocaml/xenstored/systemd.mli  |  24 
 tools/ocaml/xenstored/systemd_stubs.c  | 153 -
 tools/ocaml/xenstored/utils.ml |  21 +--
 tools/ocaml/xenstored/xenstored.ml |   2 -
 tools/xenstore/Makefile|   3 -
 tools/xenstore/xenstored_core.c| 113 +--
 18 files changed, 144 insertions(+), 411 deletions(-)
 create mode 100644 tools/hotplug/Linux/launch-xenstore.in
 delete mode 100644 tools/hotplug/Linux/systemd/xenstored.socket.in
 delete mode 100644 tools/hotplug/Linux/systemd/xenstored_ro.socket.in
 delete mode 100644 tools/ocaml/xenstored/systemd.ml
 delete mode 100644 tools/ocaml/xenstored/systemd.mli
 delete mode 100644 tools/ocaml/xenstored/systemd_stubs.c

-- 
2.6.6


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

[Xen-devel] [PATCH] xl: rename variable pause to pause_after_migration

[Wei Liu]

Gcc 4.4.4 complained that the "pause" variable introduced in 22b430e0
("xl: add option to leave domain paused after migration") shadowed
pause(2) declaration in unistd.h.

Rename "pause" to "pause_after_migration" to fix this issue.

Reported-by: Boris Ostrovsky 
Signed-off-by: Wei Liu 
---
Cc: Ian Jackson 
Cc: Roger Pau Monne 
Cc: Boris Ostrovsky 
---
 tools/libxl/xl_cmdimpl.c | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 82d6254..9267de8 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -4778,7 +4778,8 @@ static void migrate_domain(uint32_t domid, const char 
*rune, int debug,
 exit(EXIT_FAILURE);
 }
 
-static void migrate_receive(int debug, int daemonize, int monitor, int pause,
+static void migrate_receive(int debug, int daemonize, int monitor,
+int pause_after_migration,
 int send_fd, int recv_fd,
 libxl_checkpointed_stream checkpointed,
 char *colo_proxy_script)
@@ -4888,7 +4889,7 @@ static void migrate_receive(int debug, int daemonize, int 
monitor, int pause,
 if (rc) goto perhaps_destroy_notify_rc;
 }
 
-if (!pause) {
+if (!pause_after_migration) {
 rc = libxl_domain_unpause(ctx, domid);
 if (rc) goto perhaps_destroy_notify_rc;
 }
@@ -5005,7 +5006,7 @@ int main_restore(int argc, char **argv)
 
 int main_migrate_receive(int argc, char **argv)
 {
-int debug = 0, daemonize = 1, monitor = 1, pause = 0;
+int debug = 0, daemonize = 1, monitor = 1, pause_after_migration = 0;
 libxl_checkpointed_stream checkpointed = LIBXL_CHECKPOINTED_STREAM_NONE;
 int opt;
 char *script = NULL;
@@ -5037,7 +5038,7 @@ int main_migrate_receive(int argc, char **argv)
 script = optarg;
 break;
 case 'p':
-pause = 1;
+pause_after_migration = 1;
 break;
 }
 
@@ -5045,7 +5046,7 @@ int main_migrate_receive(int argc, char **argv)
 help("migrate-receive");
 return EXIT_FAILURE;
 }
-migrate_receive(debug, daemonize, monitor, pause,
+migrate_receive(debug, daemonize, monitor, pause_after_migration,
 STDOUT_FILENO, STDIN_FILENO,
 checkpointed, script);
 
@@ -5091,7 +5092,7 @@ int main_migrate(int argc, char **argv)
 const char *ssh_command = "ssh";
 char *rune = NULL;
 char *host;
-int opt, daemonize = 1, monitor = 1, debug = 0, pause = 0;
+int opt, daemonize = 1, monitor = 1, debug = 0, pause_after_migration = 0;
 static struct option opts[] = {
 {"debug", 0, 0, 0x100},
 {"live", 0, 0, 0x200},
@@ -5113,7 +5114,7 @@ int main_migrate(int argc, char **argv)
 monitor = 0;
 break;
 case 'p':
-pause = 1;
+pause_after_migration = 1;
 break;
 case 0x100: /* --debug */
 debug = 1;
@@ -5148,7 +5149,7 @@ int main_migrate(int argc, char **argv)
   verbose_len, verbose_buf,
   daemonize ? "" : " -e",
   debug ? " -d" : "",
-  pause ? " -p" : "");
+  pause_after_migration ? " -p" : "");
 }
 
 migrate_domain(domid, rune, debug, config_filename);
-- 
2.1.4


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

Re: [Xen-devel] [PATCH v2 7/9] xen/arm: Allow DOM0 to set the IRQ type

[Julien Grall]

Hi Stefano,

On 20/07/2016 00:43, Stefano Stabellini wrote:

On Thu, 14 Jul 2016, Julien Grall wrote:

 void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n)
 {
 const unsigned long mask = r;
@@ -352,6 +368,7 @@ void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n)
 unsigned long flags;
 int i = 0;
 struct vcpu *v_target;
+struct domain *d = v->domain;

 while ( (i = find_next_bit(&mask, 32, i)) < 32 ) {
 irq = i + (32 * n);
@@ -366,6 +383,8 @@ void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n)
 {
 irq_set_affinity(p->desc, cpumask_of(v_target->processor));
 spin_lock_irqsave(&p->desc->lock, flags);
+if ( irq_type_set_by_domain(d) )
+gic_set_irq_type(p->desc, vgic_get_virq_type(v, n, i));


The patch looks good, but we should probably set the type only for irq >= 32.


It is not possible to route PPIs to a guest for the moment. I remembered 
that Ian Campbell sent a series to route PPIs to the guest [1]. I would 
have to look whether we still want this series upstream (I guess so).


For the time being, I would prefer to add an ASSERT(irq >= 32). We could 
handle PPI properly when it will be supported.


Cheers,

[1] https://lists.xen.org/archives/html/xen-devel/2015-11/msg00921.html

--
Julien Grall

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

Re: [Xen-devel] [PATCH 1/2] tools: remove systemd xenstore socket definitions

[Ross Lagerwall]

On 06/29/2016 02:44 PM, Juergen Gross wrote:

On 29/06/16 15:31, Ross Lagerwall wrote:

On 06/29/2016 02:00 PM, Juergen Gross wrote:

On 29/06/16 14:52, Andrew Cooper wrote:

On 29/06/16 13:44, Juergen Gross wrote:

@@ -2068,13 +1964,6 @@ int main(int argc, char *argv[])
 /* Tell the kernel we're up and running. */
 xenbus_notify_running();

-#if defined(XEN_SYSTEMD_ENABLED)
-if (systemd) {
-sd_notify(1, "READY=1");
-fprintf(stderr, SD_NOTICE "xenstored is ready\n");
-}
-#endif


Getting rid of the socket configuration for systemd is ok, but we should
keep the sd_notify() calls for when the daemon is started by systemd.

Socket activiation and sd_notify() are orthogonal, and sd_notify() is
still required if we don't want systemd to treat xenstored as a legacy
unix daemon.


So what is the downside of xenstored being treated as a legacy daemon?
This question is especially interesting for the case of patch 2 being
considered: xenstored is no longer started by systemd, but by a wrapper
script which might decide to start the xenstore domain instead.

Another problem: today xenstored decides whether to call sd_notify()
by testing the xenstore sockets being specified via systemd. This will
no longer work. So how to do it now?




One problem with the patch as it currently is implemented is that the
service type is not correct for when xenstored is a daemon. This makes
it difficult to manage with systemd and difficult for other services to
depend on it in a sensible fashion. The end result is subtle races and
occasional failures.


Could you please educate me what's wrong? I'm no systemd expert.


Sorry for the late response.

With Type=oneshot, systemd considers the service to be "started" as soon 
as the ExecStart command completes. After re-reading the patches, I 
realize that timeout_xenstore() should ensure that xenstored is actually 
ready before systemd starts dependent services. This should prevent the 
races I was mentioned previously.


Nevertheless, I feel that this patch series makes the implementation 
worse for users of xenstored as a daemon:


- Because Type=oneshot is not intended to be used for daemon processes, 
systemctl status does not show the service as "running", instead it 
shows "exited". This is surprising, at the very least. I haven't tested, 
but I believe it would also prevent us someday using the systemd service 
management features like Restart=on-failure


- Removes socket activation. Services would have to explicitly depend on 
xenstored.service rather than having an implicit dependency on simply by 
using xenstored.socket. This means configuring explicit ordering, etc., 
which is easier to get wrong. Socket activation is also generally the 
most efficient way of starting a service.


- Uses a poll loop to determine whether the daemon is ready or not 
rather than explicit notification from the daemon itself.


- Uses a shell script wrapper...




How about:
* Maintain the existing service for xenstored
* Have a separate service (with different a service type) for starting
the xenstore domain
* Switch between the two services


How could I specify e.g. in xendomains.service the dependency to
xenstore?


Hmm. I'm not sure of the best way, but it should be possible to define 
something like xenstored.target:

[Unit]
Description=...
Wants=xenstored.service
Wants=xenstore-domain.service

and then have services depend on xenstored.target. With the ExecStartPre 
lines I mentioned previously, only one of the xenstore*.service will 
actually start.





Personally I think it is better and more uniform for the administrator
to enable and disable services in the normal fashion, but if you want to


The two services would be mutually exclusive. Can I tell systemd this
is the case?


It is possible to set Conflicts=... on a service. I'm not sure if that 
would suit your needs.





make it configurable with /etc/sysconfig/xencommons, then you can add
something like this to xenstored.service:

ExecStartPre=/bin/grep -q XENSTORETYPE=daemon /etc/sysconfig/xencommons

and to xenstore-domain.service:

ExecStartPre=/bin/grep -q XENSTORETYPE=domain /etc/sysconfig/xencommons


That's no good idea. Someone commenting out the old line and adding the
other option would end in both variants to be tried. This would have to
be a little bit more sophisticated. :-)



Yeah, indeed...


I would suggest asking on the systemd-devel mailing list or the #systemd 
IRC channel on freenode. They should be able to suggest the best way of 
solving this.


Thanks,
--
Ross Lagerwall

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

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

[Wei Liu]

On Wed, Jul 20, 2016 at 02:52:05PM +0800, Shannon Zhao wrote:
> 
> 
> On 2016/7/19 18:38, Wei Liu wrote:
> > On Fri, Jul 15, 2016 at 05:39:32PM +0800, Shannon Zhao wrote:
> > [...]
> >>> > > 
> >>> > > It would be trivial to have another option in xl.cfg to allow MB
> >>> > > granularity. But I don't think that's a good idea. Asking for more
> >>> > > memory when you don't really know how much is enough is not very 
> >>> > > useful.
> >>> > > If an admin can know how much is needed, surely the library can be
> >>> > > taught to obtain that knowledge, too.
> >>> > > 
> >>> > > We need to decide which model we should go with. And, if we decide to
> >>> > > diverge, document the difference between x86 and ARM model.
> >>> > > 
> >> > Hi Wei,
> >> > 
> >> > Do you decide how to add the size of ACPI blob to max_memkb?
> >> > 
> > AFAICT ARM and x86 maintainers hold different opinions on how memory
> > should be accounted.
> > 
> > I would like to have a unified memory accounting model. But if we can't
> > have that at the moment, I'm fine with divergence, but please document
> > it somewhere (comment near code snippet, in header, or a file under docs
> > etc). And the amount added to max_memkb needs to be properly calculated,
> > not some magic number, so that we have a chance in the future to
> > confidently change how we do thing.
> If it's only allowed to add the size to max_memkb in
> libxl__domain_build_info_setdefault(), it only can use a const number
> since the tables are not generted and we don;t know the size. But the
> const number could be chosen properly since we could know the maximum
> ACPI tables size of current ARM approach.
> 
> But maybe in the future, if we add some new ACPI tables, it should
> increase the size as well. So I think this should be documented.
> 
> As I asked before, is it ok to add the size to max_memkb after
> generating the ACPI tables and before loading the tables to guest space?
> 

Yes. I don't think shoehorning everything into setdefault is a good
idea.

I think libxl_arm.c:libxl__arch_domain_create would be the right place
to do it.

I am thinking about calling xc_domain_setmaxmem there, but not adding a
number to d_config->b_info.max_memkb. Adding that to ->max_memkb would
be wrong because the bigger ->max_memkb will be recored and the same
algorithm will be applied every time you migrate your guest, so the
max_memkb will grow bigger and bigger.

Given the different approach taken by ARM and x86, maybe we need to also
record the size of acpi blobs somewhere in xenstore (also needs to be
documented) so that subsequent libxl_domain_setmaxmem can extract that
number again.

Please wait a bit for Stefano and Julien to comment before you do work.

I know, memory accounting is a bit messy. I don't claim that I figure
every last detail out. If I'm not clear enough or ignores some basic
facts do let me know.

Wei.

> Thanks,
> -- 
> Shannon
> 

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

Re: [Xen-devel] [PATCH v2 1/2] xen: credit2: fix two s_time_t handling issues in load balancing

[George Dunlap]

On Tue, Jul 19, 2016 at 4:33 PM, Dario Faggioli
 wrote:
> both introduced in d205f8a7f48e2ec ("xen: credit2: rework
> load tracking logic").
>
> First, in __update_runq_load(), the ASSERT() was actually
> useless. Let's instead check that the computed value of
> the load has not overflowed (and hence gone negative).
>
> While there, do that in __update_svc_load() as well.
>
> Second, in balance_load(), cpus_max needs being extended
> in order to be correctly shifted, and the result compared
> with an s_time_t value, without risking loosing info.
>
> Spotted by Coverity.
>
> Signed-off-by: Dario Faggioli 
> Reported-by: Andrew Cooper 

Reviewed-by: George Dunlap 

And queued.

> ---
> Cc: George Dunlap 
> Cc: Anshul Makkar 
> ---
> Changed from v1:
>  * fixed a '> 0' which wanted to be '>= 0' in the ASSERT()-s;
>  * cite Coverity in the changelog.
> ---
>  xen/common/sched_credit2.c |8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
> index b33ba7a..a55240f 100644
> --- a/xen/common/sched_credit2.c
> +++ b/xen/common/sched_credit2.c
> @@ -656,7 +656,8 @@ __update_runq_load(const struct scheduler *ops,
>  rqd->load += change;
>  rqd->load_last_update = now;
>
> -ASSERT(rqd->avgload <= STIME_MAX && rqd->b_avgload <= STIME_MAX);
> +/* Overflow, capable of making the load look negative, must not occur. */
> +ASSERT(rqd->avgload >= 0 && rqd->b_avgload >= 0);
>
>  if ( unlikely(tb_init_done) )
>  {
> @@ -714,6 +715,9 @@ __update_svc_load(const struct scheduler *ops,
>  }
>  svc->load_last_update = now;
>
> +/* Overflow, capable of making the load look negative, must not occur. */
> +ASSERT(svc->avgload >= 0);
> +
>  if ( unlikely(tb_init_done) )
>  {
>  struct {
> @@ -1742,7 +1746,7 @@ retry:
>   * If we're under 100% capacaty, only shift if load difference
>   * is > 1.  otherwise, shift if under 12.5%
>   */
> -if ( load_max < (cpus_max << prv->load_precision_shift) )
> +if ( load_max < ((s_time_t)cpus_max << prv->load_precision_shift) )
>  {
>  if ( st.load_delta < (1ULL << (prv->load_precision_shift +
> opt_underload_balance_tolerance)) 
> )
>
>
> ___
> 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] Xen 4.8 Development Update

[Andrew Cooper]

On 19/07/16 14:48, Wei Liu wrote:
> This email only tracks big items for xen.git tree. Please reply for items you
> woulk like to see in 4.8 so that people have an idea what is going on and
> prioritise accordingly.
>
> You're welcome to provide description and use cases of the feature you're
> working on.
>
> = Timeline =
>
> We now adopt a fixed cut-off date scheme. We will release twice a
> year. The upcoming 4.8 timeline are as followed:
>
> * Last posting date: September 16, 2016
> * Hard code freeze: September 30, 2016
> * RC1: TBD
> * Release: December 2, 2016
>
> Note that we don't have freeze exception scheme anymore. All patches
> that wish to go into 4.8 must be posted no later than the last posting
> date. All patches posted after that date will be automatically queued
> into next release.
>
> RCs will be arranged immediately after freeze.
>
> = Projects =

I think it would be very wise to have a goal of

== Testing ==
*  Have OSSTest running XTF tests
  - Wei Liu
  - Andrew Cooper

for 4.8

~Andrew

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

Re: [Xen-devel] [PATCH] xl: rename variable pause to pause_after_migration

[Roger Pau Monne]

On Wed, Jul 20, 2016 at 09:30:17AM +0100, Wei Liu wrote:
> Gcc 4.4.4 complained that the "pause" variable introduced in 22b430e0
> ("xl: add option to leave domain paused after migration") shadowed
> pause(2) declaration in unistd.h.
> 
> Rename "pause" to "pause_after_migration" to fix this issue.
> 
> Reported-by: Boris Ostrovsky 
> Signed-off-by: Wei Liu 

Acked-by: Roger Pau Monné 

Thanks, I haven't noticied that it was shadowing pause(2).

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

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

[Geert Uytterhoeven]

Hi Dirk,

On Tue, Jul 12, 2016 at 9:46 AM, Dirk Behme  wrote:
> Clocks described by this property are reserved for use by Xen, and the OS
> must not alter their state any way, such as disabling or gating a clock,
> or modifying its rate. Ensuring this may impose constraints on parent
> clocks or other resources used by the clock tree.
>
> This property is used to proxy clocks for devices Xen has taken ownership
> of, such as UARTs, for which the associated clock controller(s) remain
> under the control of Dom0.

I'm not familiar with using XEN at all, but I'm a bit puzzled...

Can't you just add a clocks property to the (virtual) serial device node in DT?
Then the (virtual) serial device driver can get and enable the clock?

Alternatively, you can add a (virtual) clock controller, and power-domains
and clock properties to all affected devices (I assume there can be others,
besides virtual UARTs?), and let it be handled by Runtime PM, without the
(virtual) device drivers having to care about clocks at all.

Thanks!

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

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

Re: [Xen-devel] [PATCH v2 2/2] xen: credit2: fix potential issues in csched2_cpu_pick with tracing enabled

[George Dunlap]

On Tue, Jul 19, 2016 at 4:34 PM, Dario Faggioli
 wrote:
> In fact, when not finding a suitable runqueue where to
> place a vCPU, and hence using a fallback, we either:
>  - don't issue any trace record (while we should),
>  - risk underruning when accessing the runqueues
>array, while preparing the trace record.
>
> Fix both issues and, while there, also a couple of style
> problems found nearby.
>
> Spotted by Coverity.
>
> Signed-off-by: Dario Faggioli 
> Reported-by: Andrew Cooper 
> ---
> Cc: George Dunlap 
> Cc: Anshul Makkar 
> ---
> Changes from v1:
>  * cite Coverity in the changelog.
> ---
>  xen/common/sched_credit2.c |   13 +++--
>  1 file changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
> index a55240f..3009ff9 100644
> --- a/xen/common/sched_credit2.c
> +++ b/xen/common/sched_credit2.c
> @@ -1443,7 +1443,8 @@ csched2_cpu_pick(const struct scheduler *ops, struct 
> vcpu *vc)
>  {
>  /* We may be here because someone requested us to migrate. */
>  __clear_bit(__CSFLAG_runq_migrate_request, &svc->flags);
> -return get_fallback_cpu(svc);
> +new_cpu = get_fallback_cpu(svc);
> +goto out;
>  }
>
>  /* First check to see if we're here because someone else suggested a 
> place
> @@ -1505,7 +1506,7 @@ csched2_cpu_pick(const struct scheduler *ops, struct 
> vcpu *vc)
>  if ( rqd_avgload < min_avgload )
>  {
>  min_avgload = rqd_avgload;
> -min_rqi=i;
> +min_rqi = i;
>  }
>  }
>
> @@ -1520,20 +1521,20 @@ csched2_cpu_pick(const struct scheduler *ops, struct 
> vcpu *vc)
>  BUG_ON(new_cpu >= nr_cpu_ids);
>  }
>
> -out_up:
> + out_up:
>  read_unlock(&prv->lock);
> -
> + out:
>  if ( unlikely(tb_init_done) )
>  {
>  struct {
>  uint64_t b_avgload;
>  unsigned vcpu:16, dom:16;
>  unsigned rq_id:16, new_cpu:16;
> -   } d;
> -d.b_avgload = prv->rqd[min_rqi].b_avgload;
> +} d;
>  d.dom = vc->domain->domain_id;
>  d.vcpu = vc->vcpu_id;
>  d.rq_id = c2r(ops, new_cpu);
> +d.b_avgload = prv->rqd[d.rq_id].b_avgload;

Hmm, actually -- is this unlocked access to the prv structure the best
idea?  It looks like at the moment nothing bad should happen (as we
don't re-initialize a pcpu's entry in prv->runq_map[] to -1 when
de-initializing the pcpu), but if we ever *did*, then there'd be a
race condition we could possibly trip over.

Sorry for missing this during review.

What about having a local variable that we initialize to something
sensible (like 0 or -1) and setting it before the read_unlock()?

 -George

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

[Xen-devel] [xen-unstable-coverity test] 97701: regressions - ALL FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 coverity-amd645 coverity-buildfail REGR. vs. 96924

version targeted for testing:
 xen  22b430e0e3c5f3d071cb8e2713d7ea33ee8624ec
baseline version:
 xen  7da483b0236d8974cc97f81780dcf8e559a63175

Last test of basis96924  2016-07-10 09:19:23 Z   10 days
Failing since 97501  2016-07-17 09:26:52 Z3 days2 attempts
Testing same since97701  2016-07-20 09:23:32 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Anshul Makkar 
  Corneliu ZUZU 
  Daniel De Graaf 
  Dario Faggioli 
  Doug Goldstein 
  Elena Ufimtseva 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Juergen Gross 
  Julien Grall 
  Kevin Tian 
  Konrad Rzeszutek Wilk 
  Marek Marczykowski-Górecki 
  Quan Xu 
  Razvan Cojocaru 
  Roger Pau Monne 
  Roger Pau Monné 
  Shanker Donthineni 
  Stefano Stabellini 
  Tamas K Lengyel 
  Tim Deegan 
  Vitaly Kuznetsov 
  Wei Liu 

jobs:
 coverity-amd64   fail



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

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

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

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


Not pushing.

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

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

Re: [Xen-devel] [PATCH 1/2] tools: remove systemd xenstore socket definitions

[Juergen Gross]

On 20/07/16 11:02, Ross Lagerwall wrote:
> On 06/29/2016 02:44 PM, Juergen Gross wrote:
>> On 29/06/16 15:31, Ross Lagerwall wrote:
>>> On 06/29/2016 02:00 PM, Juergen Gross wrote:
 On 29/06/16 14:52, Andrew Cooper wrote:
> On 29/06/16 13:44, Juergen Gross wrote:
>> @@ -2068,13 +1964,6 @@ int main(int argc, char *argv[])
>>  /* Tell the kernel we're up and running. */
>>  xenbus_notify_running();
>>
>> -#if defined(XEN_SYSTEMD_ENABLED)
>> -if (systemd) {
>> -sd_notify(1, "READY=1");
>> -fprintf(stderr, SD_NOTICE "xenstored is ready\n");
>> -}
>> -#endif
>
> Getting rid of the socket configuration for systemd is ok, but we
> should
> keep the sd_notify() calls for when the daemon is started by systemd.
>
> Socket activiation and sd_notify() are orthogonal, and sd_notify() is
> still required if we don't want systemd to treat xenstored as a legacy
> unix daemon.

 So what is the downside of xenstored being treated as a legacy daemon?
 This question is especially interesting for the case of patch 2 being
 considered: xenstored is no longer started by systemd, but by a wrapper
 script which might decide to start the xenstore domain instead.

 Another problem: today xenstored decides whether to call sd_notify()
 by testing the xenstore sockets being specified via systemd. This will
 no longer work. So how to do it now?


>>>
>>> One problem with the patch as it currently is implemented is that the
>>> service type is not correct for when xenstored is a daemon. This makes
>>> it difficult to manage with systemd and difficult for other services to
>>> depend on it in a sensible fashion. The end result is subtle races and
>>> occasional failures.
>>
>> Could you please educate me what's wrong? I'm no systemd expert.
> 
> Sorry for the late response.
> 
> With Type=oneshot, systemd considers the service to be "started" as soon
> as the ExecStart command completes. After re-reading the patches, I
> realize that timeout_xenstore() should ensure that xenstored is actually
> ready before systemd starts dependent services. This should prevent the
> races I was mentioned previously.
> 
> Nevertheless, I feel that this patch series makes the implementation
> worse for users of xenstored as a daemon:
> 
> - Because Type=oneshot is not intended to be used for daemon processes,
> systemctl status does not show the service as "running", instead it
> shows "exited". This is surprising, at the very least. I haven't tested,
> but I believe it would also prevent us someday using the systemd service
> management features like Restart=on-failure
> 
> - Removes socket activation. Services would have to explicitly depend on
> xenstored.service rather than having an implicit dependency on simply by
> using xenstored.socket. This means configuring explicit ordering, etc.,
> which is easier to get wrong. Socket activation is also generally the
> most efficient way of starting a service.

So you are not taking xenstore domain into account at all.

There is no socket for xenstore domain so wanting to rely on socket
activation is the wrong way.

> - Uses a poll loop to determine whether the daemon is ready or not
> rather than explicit notification from the daemon itself.

How to do this in the domain case?

> - Uses a shell script wrapper...

That's on purpose: this enables me to switch between both setups
(daemon or domain) by modifying only _one_ configuration file.

>>> How about:
>>> * Maintain the existing service for xenstored
>>> * Have a separate service (with different a service type) for starting
>>> the xenstore domain
>>> * Switch between the two services
>>
>> How could I specify e.g. in xendomains.service the dependency to
>> xenstore?
> 
> Hmm. I'm not sure of the best way, but it should be possible to define
> something like xenstored.target:
> [Unit]
> Description=...
> Wants=xenstored.service
> Wants=xenstore-domain.service
> 
> and then have services depend on xenstored.target. With the ExecStartPre
> lines I mentioned previously, only one of the xenstore*.service will
> actually start.

And the other will be "failed". How is this better than the current
"exited" state?

>>> Personally I think it is better and more uniform for the administrator
>>> to enable and disable services in the normal fashion, but if you want to
>>
>> The two services would be mutually exclusive. Can I tell systemd this
>> is the case?
> 
> It is possible to set Conflicts=... on a service. I'm not sure if that
> would suit your needs.

On a first glance I don't think so. This would be interesting in case I
could switch between both setups during runtime, but it is no easy way
to select one of two mutual exclusive services at boot time.

>>> make it configurable with /etc/sysconfig/xencommons, then you can add
>>> something like this to xenstored.service:
>>>
>>> ExecStartPre=/bin/grep -q XENS

Re: [Xen-devel] Xen 4.8 Development Update

[Wei Liu]

On Wed, Jul 20, 2016 at 10:34:01AM +0100, Andrew Cooper wrote:
> On 19/07/16 14:48, Wei Liu wrote:
> > This email only tracks big items for xen.git tree. Please reply for items 
> > you
> > woulk like to see in 4.8 so that people have an idea what is going on and
> > prioritise accordingly.
> >
> > You're welcome to provide description and use cases of the feature you're
> > working on.
> >
> > = Timeline =
> >
> > We now adopt a fixed cut-off date scheme. We will release twice a
> > year. The upcoming 4.8 timeline are as followed:
> >
> > * Last posting date: September 16, 2016
> > * Hard code freeze: September 30, 2016
> > * RC1: TBD
> > * Release: December 2, 2016
> >
> > Note that we don't have freeze exception scheme anymore. All patches
> > that wish to go into 4.8 must be posted no later than the last posting
> > date. All patches posted after that date will be automatically queued
> > into next release.
> >
> > RCs will be arranged immediately after freeze.
> >
> > = Projects =
> 
> I think it would be very wise to have a goal of
> 
> == Testing ==
> *  Have OSSTest running XTF tests
>   - Wei Liu
>   - Andrew Cooper
> 
> for 4.8
> 

This email only tracks code that would affect xen.git so I didn't add
that here.

But since you think it is relevant I can track it as well.

Wei.

> ~Andrew

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

Re: [Xen-devel] [PATCH] xl: rename variable pause to pause_after_migration

[Wei Liu]

On Wed, Jul 20, 2016 at 11:43:19AM +0200, Roger Pau Monne wrote:
> On Wed, Jul 20, 2016 at 09:30:17AM +0100, Wei Liu wrote:
> > Gcc 4.4.4 complained that the "pause" variable introduced in 22b430e0
> > ("xl: add option to leave domain paused after migration") shadowed
> > pause(2) declaration in unistd.h.
> > 
> > Rename "pause" to "pause_after_migration" to fix this issue.
> > 
> > Reported-by: Boris Ostrovsky 
> > Signed-off-by: Wei Liu 
> 
> Acked-by: Roger Pau Monné 
> 
> Thanks, I haven't noticied that it was shadowing pause(2).

My compile test passed. Newer gcc is happy with that. I didn't bother to
look into the differences between different gcc versions though.

Wei.

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

Re: [Xen-devel] [PATCH v2 1/2] tools: remove systemd xenstore socket definitions

[Ian Jackson]

Juergen Gross writes ("[PATCH v2 1/2] tools: remove systemd xenstore socket 
definitions"):
> On a system with systemd the xenstore sockets are created via systemd.
> Remove the related configuration files in order to be able to decide
> at runtime whether the sockets should be created or not. This will
> enable Xen to start xenstore either via a daemon or via a stub domain.

The core parts of this look OK to me.  I think this needs an ack from
Dave Scott.  I'd also like to invite comments from any systemd
experts.

However:

> diff --git a/tools/configure b/tools/configure
> index 5b5dcce..a04fe3f 100755
> --- a/tools/configure
> +++ b/tools/configure

Where is the corresponding original source change for this hunk ?
You need to include that.  (Also please write a note in the commit
message to remind the committer to rerun autogen.sh.)

Thanks,
Ian.

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

Re: [Xen-devel] [PATCH v2 2/2] tools: make xenstore domain easy configurable

[Ian Jackson]

Juergen Gross writes ("[PATCH v2 2/2] tools: make xenstore domain easy 
configurable"):
> Add configuration entries to sysconfig.xencommons for selection of the
> xenstore type (domain or daemon) and start the selected xenstore
> service via a script called from sysvinit or systemd.

Can you please split this up into two patches,
 * Break launch-xenstore out of xencommons (no functional change)
 * Use launch-xenstore instead of sockets with systemd
?

As ever it's a lot easier to review the functional change when it's
not mixed in with code motion.

I suspect that the latter mnay need to be combined with parts of what
is currently 1/2, since AFAICT after applying 1 nothing starts
xenstored any more under systemd.

(Also your patch again contains a patch to configure but no
corresponding patch to the source file(s).)

Thanks,
Ian.

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

Re: [Xen-devel] [PATCH 1/2] tools: remove systemd xenstore socket definitions

[George Dunlap]

On Wed, Jul 20, 2016 at 10:58 AM, Juergen Gross  wrote:
> On 20/07/16 11:02, Ross Lagerwall wrote:
>> On 06/29/2016 02:44 PM, Juergen Gross wrote:
>>> On 29/06/16 15:31, Ross Lagerwall wrote:
 On 06/29/2016 02:00 PM, Juergen Gross wrote:
> On 29/06/16 14:52, Andrew Cooper wrote:
>> On 29/06/16 13:44, Juergen Gross wrote:
>>> @@ -2068,13 +1964,6 @@ int main(int argc, char *argv[])
>>>  /* Tell the kernel we're up and running. */
>>>  xenbus_notify_running();
>>>
>>> -#if defined(XEN_SYSTEMD_ENABLED)
>>> -if (systemd) {
>>> -sd_notify(1, "READY=1");
>>> -fprintf(stderr, SD_NOTICE "xenstored is ready\n");
>>> -}
>>> -#endif
>>
>> Getting rid of the socket configuration for systemd is ok, but we
>> should
>> keep the sd_notify() calls for when the daemon is started by systemd.
>>
>> Socket activiation and sd_notify() are orthogonal, and sd_notify() is
>> still required if we don't want systemd to treat xenstored as a legacy
>> unix daemon.
>
> So what is the downside of xenstored being treated as a legacy daemon?
> This question is especially interesting for the case of patch 2 being
> considered: xenstored is no longer started by systemd, but by a wrapper
> script which might decide to start the xenstore domain instead.
>
> Another problem: today xenstored decides whether to call sd_notify()
> by testing the xenstore sockets being specified via systemd. This will
> no longer work. So how to do it now?
>
>

 One problem with the patch as it currently is implemented is that the
 service type is not correct for when xenstored is a daemon. This makes
 it difficult to manage with systemd and difficult for other services to
 depend on it in a sensible fashion. The end result is subtle races and
 occasional failures.
>>>
>>> Could you please educate me what's wrong? I'm no systemd expert.
>>
>> Sorry for the late response.
>>
>> With Type=oneshot, systemd considers the service to be "started" as soon
>> as the ExecStart command completes. After re-reading the patches, I
>> realize that timeout_xenstore() should ensure that xenstored is actually
>> ready before systemd starts dependent services. This should prevent the
>> races I was mentioned previously.
>>
>> Nevertheless, I feel that this patch series makes the implementation
>> worse for users of xenstored as a daemon:
>>
>> - Because Type=oneshot is not intended to be used for daemon processes,
>> systemctl status does not show the service as "running", instead it
>> shows "exited". This is surprising, at the very least. I haven't tested,
>> but I believe it would also prevent us someday using the systemd service
>> management features like Restart=on-failure
>>
>> - Removes socket activation. Services would have to explicitly depend on
>> xenstored.service rather than having an implicit dependency on simply by
>> using xenstored.socket. This means configuring explicit ordering, etc.,
>> which is easier to get wrong. Socket activation is also generally the
>> most efficient way of starting a service.
>
> So you are not taking xenstore domain into account at all.
>
> There is no socket for xenstore domain so wanting to rely on socket
> activation is the wrong way.
>
>> - Uses a poll loop to determine whether the daemon is ready or not
>> rather than explicit notification from the daemon itself.
>
> How to do this in the domain case?
>
>> - Uses a shell script wrapper...
>
> That's on purpose: this enables me to switch between both setups
> (daemon or domain) by modifying only _one_ configuration file.

FWIW I'm pretty sure using a shell script wrapper also clobbers the
SELinux context.  (I forget whether this means xenstore doesn't run or
xenstore runs completely unrestricted.)

(Ross, does XenServer use SELinux?  Any ideas here?)

>> I would suggest asking on the systemd-devel mailing list or the #systemd
>> IRC channel on freenode. They should be able to suggest the best way of
>> solving this.
>
> I'm sure I could tweak the whole setup more in direction of systemd.
> I'm not sure the final picture would be the preferred one.

But as Ross said, there are advantages to using the systemd-specific
functionality; and it's likely that the majority of our users will be
running xenstored in dom0.  Doesn't it make sense to at least see if
there are sensible options for how we can take advantage of those
before we just drop it?

 -George

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

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

[Julien Grall]

On 20/07/16 10:43, Geert Uytterhoeven wrote:

Hi Dirk,


Hi Geert,


On Tue, Jul 12, 2016 at 9:46 AM, Dirk Behme  wrote:

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

This property is used to proxy clocks for devices Xen has taken ownership
of, such as UARTs, for which the associated clock controller(s) remain
under the control of Dom0.


I'm not familiar with using XEN at all, but I'm a bit puzzled...

Can't you just add a clocks property to the (virtual) serial device node in DT?
Then the (virtual) serial device driver can get and enable the clock?


There is no DT node for the Xen console (hvc). The UART used by Xen will 
be completely removed from the Device tree.




Alternatively, you can add a (virtual) clock controller, and power-domains
and clock properties to all affected devices (I assume there can be others,
besides virtual UARTs?), and let it be handled by Runtime PM, without the
(virtual) device drivers having to care about clocks at all.


I am not sure to understand here. The problem is not because we provide 
virtual device to DOM0 but because the physical devices will be 
completely hidden (i.e remove from the DT) from DOM0.


Those devices will be removed from the Device Tree and may not have a 
corresponding virtual device. So we cannot replicate the clocks property 
in the device.


In a previous mail [1], Stefano suggested to add a new property for the 
clock to mention that the clock should not changed (i.e rate, 
disable...). How would that fit?


Regards,

[1] 
https://lists.xenproject.org/archives/html/xen-devel/2016-07/msg01614.html


--
Julien Grall

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt-xsm  6 xen-bootfail pass in 97623
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat   fail pass in 97623

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

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

version targeted for testing:
 xen  e763268781d341fef05d461f3057e6ced5e033f2
baseline version:
 xen  e763268781d341fef05d461f3057e6ced5e033f2

Last test of basis97664  2016-07-19 15:37:51 Z0 days
Testing same since0  1970-01-01 00:00:00 Z 17002 days0 attempts

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

Re: [Xen-devel] [PATCH 1/2] tools: remove systemd xenstore socket definitions

[Juergen Gross]

On 20/07/16 12:52, George Dunlap wrote:
> On Wed, Jul 20, 2016 at 10:58 AM, Juergen Gross  wrote:
>> On 20/07/16 11:02, Ross Lagerwall wrote:
>>> On 06/29/2016 02:44 PM, Juergen Gross wrote:
 On 29/06/16 15:31, Ross Lagerwall wrote:
> On 06/29/2016 02:00 PM, Juergen Gross wrote:
>> On 29/06/16 14:52, Andrew Cooper wrote:
>>> On 29/06/16 13:44, Juergen Gross wrote:
 @@ -2068,13 +1964,6 @@ int main(int argc, char *argv[])
  /* Tell the kernel we're up and running. */
  xenbus_notify_running();

 -#if defined(XEN_SYSTEMD_ENABLED)
 -if (systemd) {
 -sd_notify(1, "READY=1");
 -fprintf(stderr, SD_NOTICE "xenstored is ready\n");
 -}
 -#endif
>>>
>>> Getting rid of the socket configuration for systemd is ok, but we
>>> should
>>> keep the sd_notify() calls for when the daemon is started by systemd.
>>>
>>> Socket activiation and sd_notify() are orthogonal, and sd_notify() is
>>> still required if we don't want systemd to treat xenstored as a legacy
>>> unix daemon.
>>
>> So what is the downside of xenstored being treated as a legacy daemon?
>> This question is especially interesting for the case of patch 2 being
>> considered: xenstored is no longer started by systemd, but by a wrapper
>> script which might decide to start the xenstore domain instead.
>>
>> Another problem: today xenstored decides whether to call sd_notify()
>> by testing the xenstore sockets being specified via systemd. This will
>> no longer work. So how to do it now?
>>
>>
>
> One problem with the patch as it currently is implemented is that the
> service type is not correct for when xenstored is a daemon. This makes
> it difficult to manage with systemd and difficult for other services to
> depend on it in a sensible fashion. The end result is subtle races and
> occasional failures.

 Could you please educate me what's wrong? I'm no systemd expert.
>>>
>>> Sorry for the late response.
>>>
>>> With Type=oneshot, systemd considers the service to be "started" as soon
>>> as the ExecStart command completes. After re-reading the patches, I
>>> realize that timeout_xenstore() should ensure that xenstored is actually
>>> ready before systemd starts dependent services. This should prevent the
>>> races I was mentioned previously.
>>>
>>> Nevertheless, I feel that this patch series makes the implementation
>>> worse for users of xenstored as a daemon:
>>>
>>> - Because Type=oneshot is not intended to be used for daemon processes,
>>> systemctl status does not show the service as "running", instead it
>>> shows "exited". This is surprising, at the very least. I haven't tested,
>>> but I believe it would also prevent us someday using the systemd service
>>> management features like Restart=on-failure
>>>
>>> - Removes socket activation. Services would have to explicitly depend on
>>> xenstored.service rather than having an implicit dependency on simply by
>>> using xenstored.socket. This means configuring explicit ordering, etc.,
>>> which is easier to get wrong. Socket activation is also generally the
>>> most efficient way of starting a service.
>>
>> So you are not taking xenstore domain into account at all.
>>
>> There is no socket for xenstore domain so wanting to rely on socket
>> activation is the wrong way.
>>
>>> - Uses a poll loop to determine whether the daemon is ready or not
>>> rather than explicit notification from the daemon itself.
>>
>> How to do this in the domain case?
>>
>>> - Uses a shell script wrapper...
>>
>> That's on purpose: this enables me to switch between both setups
>> (daemon or domain) by modifying only _one_ configuration file.
> 
> FWIW I'm pretty sure using a shell script wrapper also clobbers the
> SELinux context.  (I forget whether this means xenstore doesn't run or
> xenstore runs completely unrestricted.)

Okay, this would need to be corrected. I assume it is possible to
address such an issue in a script?

> (Ross, does XenServer use SELinux?  Any ideas here?)
> 
>>> I would suggest asking on the systemd-devel mailing list or the #systemd
>>> IRC channel on freenode. They should be able to suggest the best way of
>>> solving this.
>>
>> I'm sure I could tweak the whole setup more in direction of systemd.
>> I'm not sure the final picture would be the preferred one.
> 
> But as Ross said, there are advantages to using the systemd-specific
> functionality; and it's likely that the majority of our users will be
> running xenstored in dom0.  Doesn't it make sense to at least see if
> there are sensible options for how we can take advantage of those
> before we just drop it?

I still don't see the advantages, as relying on socket activation of
the xenstore service is no option: as soon as you do this you drop the
possibility to ever use the xenstore domain on such a system.

To be clear

Re: [Xen-devel] [PATCH v2 1/2] tools: remove systemd xenstore socket definitions

[Juergen Gross]

On 20/07/16 12:36, Ian Jackson wrote:
> Juergen Gross writes ("[PATCH v2 1/2] tools: remove systemd xenstore socket 
> definitions"):
>> On a system with systemd the xenstore sockets are created via systemd.
>> Remove the related configuration files in order to be able to decide
>> at runtime whether the sockets should be created or not. This will
>> enable Xen to start xenstore either via a daemon or via a stub domain.
> 
> The core parts of this look OK to me.  I think this needs an ack from
> Dave Scott.  I'd also like to invite comments from any systemd
> experts.
> 
> However:
> 
>> diff --git a/tools/configure b/tools/configure
>> index 5b5dcce..a04fe3f 100755
>> --- a/tools/configure
>> +++ b/tools/configure
> 
> Where is the corresponding original source change for this hunk ?
> You need to include that.  (Also please write a note in the commit
> message to remind the committer to rerun autogen.sh.)

Okay, will do.


Juergen

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

Re: [Xen-devel] [PATCH v2 2/2] tools: make xenstore domain easy configurable

[Juergen Gross]

On 20/07/16 12:43, Ian Jackson wrote:
> Juergen Gross writes ("[PATCH v2 2/2] tools: make xenstore domain easy 
> configurable"):
>> Add configuration entries to sysconfig.xencommons for selection of the
>> xenstore type (domain or daemon) and start the selected xenstore
>> service via a script called from sysvinit or systemd.
> 
> Can you please split this up into two patches,
>  * Break launch-xenstore out of xencommons (no functional change)
>  * Use launch-xenstore instead of sockets with systemd
> ?
> 
> As ever it's a lot easier to review the functional change when it's
> not mixed in with code motion.
> 
> I suspect that the latter mnay need to be combined with parts of what
> is currently 1/2, since AFAICT after applying 1 nothing starts
> xenstored any more under systemd.
> 
> (Also your patch again contains a patch to configure but no
> corresponding patch to the source file(s).)

Okay, I'll have a try.


Juergen

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

Re: [Xen-devel] [PATCH 1/2] tools: remove systemd xenstore socket definitions

[Andrew Cooper]

On 20/07/16 12:12, Juergen Gross wrote:
> On 20/07/16 12:52, George Dunlap wrote:
>> On Wed, Jul 20, 2016 at 10:58 AM, Juergen Gross  wrote:
>>> On 20/07/16 11:02, Ross Lagerwall wrote:
 On 06/29/2016 02:44 PM, Juergen Gross wrote:
> On 29/06/16 15:31, Ross Lagerwall wrote:
>> On 06/29/2016 02:00 PM, Juergen Gross wrote:
>>> On 29/06/16 14:52, Andrew Cooper wrote:
 On 29/06/16 13:44, Juergen Gross wrote:
> @@ -2068,13 +1964,6 @@ int main(int argc, char *argv[])
>  /* Tell the kernel we're up and running. */
>  xenbus_notify_running();
>
> -#if defined(XEN_SYSTEMD_ENABLED)
> -if (systemd) {
> -sd_notify(1, "READY=1");
> -fprintf(stderr, SD_NOTICE "xenstored is ready\n");
> -}
> -#endif
 Getting rid of the socket configuration for systemd is ok, but we
 should
 keep the sd_notify() calls for when the daemon is started by systemd.

 Socket activiation and sd_notify() are orthogonal, and sd_notify() is
 still required if we don't want systemd to treat xenstored as a legacy
 unix daemon.
>>> So what is the downside of xenstored being treated as a legacy daemon?
>>> This question is especially interesting for the case of patch 2 being
>>> considered: xenstored is no longer started by systemd, but by a wrapper
>>> script which might decide to start the xenstore domain instead.
>>>
>>> Another problem: today xenstored decides whether to call sd_notify()
>>> by testing the xenstore sockets being specified via systemd. This will
>>> no longer work. So how to do it now?
>>>
>>>
>> One problem with the patch as it currently is implemented is that the
>> service type is not correct for when xenstored is a daemon. This makes
>> it difficult to manage with systemd and difficult for other services to
>> depend on it in a sensible fashion. The end result is subtle races and
>> occasional failures.
> Could you please educate me what's wrong? I'm no systemd expert.
 Sorry for the late response.

 With Type=oneshot, systemd considers the service to be "started" as soon
 as the ExecStart command completes. After re-reading the patches, I
 realize that timeout_xenstore() should ensure that xenstored is actually
 ready before systemd starts dependent services. This should prevent the
 races I was mentioned previously.

 Nevertheless, I feel that this patch series makes the implementation
 worse for users of xenstored as a daemon:

 - Because Type=oneshot is not intended to be used for daemon processes,
 systemctl status does not show the service as "running", instead it
 shows "exited". This is surprising, at the very least. I haven't tested,
 but I believe it would also prevent us someday using the systemd service
 management features like Restart=on-failure

 - Removes socket activation. Services would have to explicitly depend on
 xenstored.service rather than having an implicit dependency on simply by
 using xenstored.socket. This means configuring explicit ordering, etc.,
 which is easier to get wrong. Socket activation is also generally the
 most efficient way of starting a service.
>>> So you are not taking xenstore domain into account at all.
>>>
>>> There is no socket for xenstore domain so wanting to rely on socket
>>> activation is the wrong way.
>>>
 - Uses a poll loop to determine whether the daemon is ready or not
 rather than explicit notification from the daemon itself.
>>> How to do this in the domain case?
>>>
 - Uses a shell script wrapper...
>>> That's on purpose: this enables me to switch between both setups
>>> (daemon or domain) by modifying only _one_ configuration file.
>> FWIW I'm pretty sure using a shell script wrapper also clobbers the
>> SELinux context.  (I forget whether this means xenstore doesn't run or
>> xenstore runs completely unrestricted.)
> Okay, this would need to be corrected. I assume it is possible to
> address such an issue in a script?
>
>> (Ross, does XenServer use SELinux?  Any ideas here?)

XenServer does not use any SELinux.


>>
 I would suggest asking on the systemd-devel mailing list or the #systemd
 IRC channel on freenode. They should be able to suggest the best way of
 solving this.
>>> I'm sure I could tweak the whole setup more in direction of systemd.
>>> I'm not sure the final picture would be the preferred one.
>> But as Ross said, there are advantages to using the systemd-specific
>> functionality; and it's likely that the majority of our users will be
>> running xenstored in dom0.  Doesn't it make sense to at least see if
>> there are sensible options for how we can take advantage of those
>> before we just drop it?
> I still don't see the advantages, as relying on socket activation of
> the xenstore serv

Re: [Xen-devel] [PATCH V2 2/4] xen: Add generic implementation of binary search

[Julien Grall]

Hi Shanker,

On 18/07/16 00:26, Shanker Donthineni wrote:

This patch adds the generic implementation of binary search algorithm
whcih is copied from Linux kernel v4.7-rc7. No functional changes.


NIT: ws/whcih/which/



Signed-off-by: Shanker Donthineni 
Reviewed-by: Andrew Cooper 


FWIW:

Reviewed-by: Julien Grall 

Regards,


---
Changes since v1:
 Removed the header file xen/include/xen/bsearch.h.
 Defined function bsearch() prototype in the header file xen/lib.h.

 xen/common/Makefile   |  1 +
 xen/common/bsearch.c  | 51 +++
 xen/include/xen/lib.h |  3 +++
 3 files changed, 55 insertions(+)
 create mode 100644 xen/common/bsearch.c

diff --git a/xen/common/Makefile b/xen/common/Makefile
index dbf00c6..f8123c2 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -43,6 +43,7 @@ obj-y += schedule.o
 obj-y += shutdown.o
 obj-y += softirq.o
 obj-y += sort.o
+obj-y += bsearch.o
 obj-y += smp.o
 obj-y += spinlock.o
 obj-y += stop_machine.o
diff --git a/xen/common/bsearch.c b/xen/common/bsearch.c
new file mode 100644
index 000..7090930
--- /dev/null
+++ b/xen/common/bsearch.c
@@ -0,0 +1,51 @@
+/*
+ * A generic implementation of binary search for the Linux kernel
+ *
+ * Copyright (C) 2008-2009 Ksplice, Inc.
+ * Author: Tim Abbott 
+ *
+ * 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; version 2.
+ */
+
+#include 
+
+/*
+ * bsearch - binary search an array of elements
+ * @key: pointer to item being searched for
+ * @base: pointer to first element to search
+ * @num: number of elements
+ * @size: size of each element
+ * @cmp: pointer to comparison function
+ *
+ * This function does a binary search on the given array.  The
+ * contents of the array should already be in ascending sorted order
+ * under the provided comparison function.
+ *
+ * Note that the key need not have the same type as the elements in
+ * the array, e.g. key could be a string and the comparison function
+ * could compare the string with the struct's name field.  However, if
+ * the key and elements in the array are of the same type, you can use
+ * the same comparison function for both sort() and bsearch().
+ */
+void *bsearch(const void *key, const void *base, size_t num, size_t size,
+ int (*cmp)(const void *key, const void *elt))
+{
+   size_t start = 0, end = num;
+   int result;
+
+   while (start < end) {
+   size_t mid = start + (end - start) / 2;
+
+   result = cmp(key, base + mid * size);
+   if (result < 0)
+   end = mid;
+   else if (result > 0)
+   start = mid + 1;
+   else
+   return (void *)base + mid * size;
+   }
+
+   return NULL;
+}
diff --git a/xen/include/xen/lib.h b/xen/include/xen/lib.h
index b1b0fb2..b90d582 100644
--- a/xen/include/xen/lib.h
+++ b/xen/include/xen/lib.h
@@ -153,4 +153,7 @@ void dump_execstate(struct cpu_user_regs *);

 void init_constructors(void);

+void *bsearch(const void *key, const void *base, size_t num, size_t size,
+  int (*cmp)(const void *key, const void *elt))
+
 #endif /* __LIB_H__ */



--
Julien Grall

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

[Xen-devel] [PATCH v2 0/3] xen-scsiback: Fine-tuning for scsiback_device_action()

[SF Markus Elfring]

From: Markus Elfring 
Date: Wed, 20 Jul 2016 13:20:04 +0200

Further update suggestions were taken into account
after a patch was applied from static source code analysis.

Markus Elfring (3):
  Delete an unnecessary check before the function call "kfree"
  Rename jump labels in scsiback_device_action()
  Pass a failure indication as a constant

 drivers/xen/xen-scsiback.c | 19 +--
 1 file changed, 9 insertions(+), 10 deletions(-)

-- 
2.9.2


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

[Xen-devel] [PATCH v2 1/3] xen-scsiback: Delete an unnecessary check before the function call "kfree"

[SF Markus Elfring]

From: Markus Elfring 
Date: Tue, 19 Jul 2016 15:42:19 +0200

The kfree() function tests whether its argument is NULL and then
returns immediately. Thus the test around the call is not needed.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
v2: Rebased on source files from "Linux next-20160719"

 drivers/xen/xen-scsiback.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/xen/xen-scsiback.c b/drivers/xen/xen-scsiback.c
index d6950e0..4a48c06 100644
--- a/drivers/xen/xen-scsiback.c
+++ b/drivers/xen/xen-scsiback.c
@@ -627,8 +627,7 @@ static void scsiback_device_action(struct vscsibk_pend 
*pending_req,
transport_generic_free_cmd(&pending_req->se_cmd, 1);
return;
 err:
-   if (tmr)
-   kfree(tmr);
+   kfree(tmr);
scsiback_do_resp_with_sense(NULL, err, 0, pending_req);
 }
 
-- 
2.9.2


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

Re: [Xen-devel] [PATCH V2 2/4] xen: Add generic implementation of binary search

[Julien Grall]

On 20/07/16 12:25, Julien Grall wrote:

Hi Shanker,

On 18/07/16 00:26, Shanker Donthineni wrote:

This patch adds the generic implementation of binary search algorithm
whcih is copied from Linux kernel v4.7-rc7. No functional changes.


NIT: ws/whcih/which/



Signed-off-by: Shanker Donthineni 
Reviewed-by: Andrew Cooper 


FWIW:

Reviewed-by: Julien Grall 


Please ignore this, see why below...


diff --git a/xen/include/xen/lib.h b/xen/include/xen/lib.h
index b1b0fb2..b90d582 100644
--- a/xen/include/xen/lib.h
+++ b/xen/include/xen/lib.h
@@ -153,4 +153,7 @@ void dump_execstate(struct cpu_user_regs *);

 void init_constructors(void);

+void *bsearch(const void *key, const void *base, size_t num, size_t
size,
+  int (*cmp)(const void *key, const void *elt))


Actually, there is a missing ';' which lead to a compilation failure. 
Please try to compile and test this series.


I will wait before reviewing the rest of this series.


+
 #endif /* __LIB_H__ */





--
Julien Grall

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

[Xen-devel] [PATCH v2 2/3] xen-scsiback: Rename jump labels in scsiback_device_action()

[SF Markus Elfring]

From: Markus Elfring 
Date: Wed, 20 Jul 2016 13:03:16 +0200

* Adjust jump targets according to the Linux coding style convention.

* A bit of refactoring for the control flow

Suggested-by: Jürgen Groß 
Signed-off-by: Markus Elfring 
---
v2: Rebased on source files from "Linux next-20160719"
Changes from a bit of code review

 drivers/xen/xen-scsiback.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/xen/xen-scsiback.c b/drivers/xen/xen-scsiback.c
index 4a48c06..eb274df 100644
--- a/drivers/xen/xen-scsiback.c
+++ b/drivers/xen/xen-scsiback.c
@@ -604,10 +604,8 @@ static void scsiback_device_action(struct vscsibk_pend 
*pending_req,
int rc, err = FAILED;
 
tmr = kzalloc(sizeof(struct scsiback_tmr), GFP_KERNEL);
-   if (!tmr) {
-   target_put_sess_cmd(se_cmd);
-   goto err;
-   }
+   if (!tmr)
+   goto put_cmd;
 
init_waitqueue_head(&tmr->tmr_wait);
 
@@ -616,7 +614,7 @@ static void scsiback_device_action(struct vscsibk_pend 
*pending_req,
   unpacked_lun, tmr, act, GFP_KERNEL,
   tag, TARGET_SCF_ACK_KREF);
if (rc)
-   goto err;
+   goto free_tmr;
 
wait_event(tmr->tmr_wait, atomic_read(&tmr->tmr_complete));
 
@@ -626,7 +624,9 @@ static void scsiback_device_action(struct vscsibk_pend 
*pending_req,
scsiback_do_resp_with_sense(NULL, err, 0, pending_req);
transport_generic_free_cmd(&pending_req->se_cmd, 1);
return;
-err:
+put_cmd:
+   target_put_sess_cmd(se_cmd);
+free_tmr:
kfree(tmr);
scsiback_do_resp_with_sense(NULL, err, 0, pending_req);
 }
-- 
2.9.2


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

[Xen-devel] [PATCH v2 3/3] xen-scsiback: Pass a failure indication as a constant

[SF Markus Elfring]

From: Markus Elfring 
Date: Wed, 20 Jul 2016 13:12:33 +0200

Pass the constant "FAILED" in a function call directly instead of
using an intialisation for a local variable.

Signed-off-by: Markus Elfring 
---
v2: Rebased on source files from "Linux next-20160719"

 drivers/xen/xen-scsiback.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/xen-scsiback.c b/drivers/xen/xen-scsiback.c
index eb274df..fa08ec6 100644
--- a/drivers/xen/xen-scsiback.c
+++ b/drivers/xen/xen-scsiback.c
@@ -601,7 +601,7 @@ static void scsiback_device_action(struct vscsibk_pend 
*pending_req,
struct se_cmd *se_cmd = &pending_req->se_cmd;
struct scsiback_tmr *tmr;
u64 unpacked_lun = pending_req->v2p->lun;
-   int rc, err = FAILED;
+   int rc, err;
 
tmr = kzalloc(sizeof(struct scsiback_tmr), GFP_KERNEL);
if (!tmr)
@@ -628,7 +628,7 @@ put_cmd:
target_put_sess_cmd(se_cmd);
 free_tmr:
kfree(tmr);
-   scsiback_do_resp_with_sense(NULL, err, 0, pending_req);
+   scsiback_do_resp_with_sense(NULL, FAILED, 0, pending_req);
 }
 
 /*
-- 
2.9.2


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

Re: [Xen-devel] [PATCH] xen/domctl: Add DOMINFO_hap to xen_domctl_getdomaininfo

[Julien Grall]

Hi Andrew,

On 15/07/16 17:57, Andrew Cooper wrote:

diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
index f61f98a..afa16d8 100644
--- a/xen/arch/arm/domctl.c
+++ b/xen/arch/arm/domctl.c
@@ -14,6 +14,12 @@
 #include 
 #include 

+void arch_get_domain_info(const struct domain *d,
+  struct xen_domctl_getdomaininfo *info)
+{
+info->flags |= XEN_DOMINF_hap;
+}
+


The ARM change looks good to me. I have just one request, would be it 
possible to add a comment in the code explaining why hap is 
unconditionally set? (I.e domains are always using hap on ARM).


With that:

Reviewed-by: Julien Grall 


 long arch_do_domctl(struct xen_domctl *domctl, struct domain *d,
 XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
 {


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 3/3] xen-scsiback: Pass a failure indication as a constant

[Juergen Gross]

On 20/07/16 13:36, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Wed, 20 Jul 2016 13:12:33 +0200
> 
> Pass the constant "FAILED" in a function call directly instead of
> using an intialisation for a local variable.
> 
> Signed-off-by: Markus Elfring 

Even if already given, here it is again:

Reviewed-by: Juergen Gross 


Juergen

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

Re: [Xen-devel] [PATCH v2 1/3] xen-scsiback: Delete an unnecessary check before the function call "kfree"

[Juergen Gross]

On 20/07/16 13:30, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Tue, 19 Jul 2016 15:42:19 +0200
> 
> The kfree() function tests whether its argument is NULL and then
> returns immediately. Thus the test around the call is not needed.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 

Even if already given, here it is again:

Reviewed-by: Juergen Gross 


Juergen

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

Re: [Xen-devel] [PATCH v2 2/3] xen-scsiback: Rename jump labels in scsiback_device_action()

[Juergen Gross]

On 20/07/16 13:34, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Wed, 20 Jul 2016 13:03:16 +0200
> 
> * Adjust jump targets according to the Linux coding style convention.
> 
> * A bit of refactoring for the control flow
> 
> Suggested-by: Jürgen Groß 
> Signed-off-by: Markus Elfring 

Reviewed-by: Juergen Gross 


Juergen

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

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

[Geert Uytterhoeven]

Hi Julien,

On Wed, Jul 20, 2016 at 1:01 PM, Julien Grall  wrote:
> On 20/07/16 10:43, Geert Uytterhoeven wrote:
>> On Tue, Jul 12, 2016 at 9:46 AM, Dirk Behme 
>> wrote:
>>>
>>> Clocks described by this property are reserved for use by Xen, and the OS
>>> must not alter their state any way, such as disabling or gating a clock,
>>> or modifying its rate. Ensuring this may impose constraints on parent
>>> clocks or other resources used by the clock tree.
>>>
>>> This property is used to proxy clocks for devices Xen has taken ownership
>>> of, such as UARTs, for which the associated clock controller(s) remain
>>> under the control of Dom0.
>>
>>
>> I'm not familiar with using XEN at all, but I'm a bit puzzled...
>>
>> Can't you just add a clocks property to the (virtual) serial device node
>> in DT?
>> Then the (virtual) serial device driver can get and enable the clock?
>
> There is no DT node for the Xen console (hvc). The UART used by Xen will be
> completely removed from the Device tree.

Why is it removed?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

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

[Xen-devel] [PATCH XTF] build: introduce a dist target

[Wei Liu]

The install target doesn't honour $PREFIX. Introduce a dist target to
make it easier to package the artifacts.

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

diff --git a/Makefile b/Makefile
index 1a8099d..d625b90 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,7 @@
 MAKEFLAGS += -r
 ROOT := $(abspath $(CURDIR))
 DESTDIR ?= $(ROOT)/dist
+DISTDIR ?= $(ROOT)/dist
 PREFIX ?= $(ROOT)
 
 .PHONY: all
@@ -10,6 +11,10 @@ all:
$(MAKE) -C $$D build; \
done
 
+.PHONY: dist
+dist: DESTDIR=$(DISTDIR)$(PREFIX)
+dist: install
+
 .PHONY: install
 install:
@mkdir -p $(DESTDIR)
-- 
2.1.4


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

Re: [Xen-devel] [PATCH 1/2] tools: remove systemd xenstore socket definitions

[Juergen Gross]

On 20/07/16 13:21, Andrew Cooper wrote:
> On 20/07/16 12:12, Juergen Gross wrote:
>> On 20/07/16 12:52, George Dunlap wrote:
>>> On Wed, Jul 20, 2016 at 10:58 AM, Juergen Gross  wrote:
 On 20/07/16 11:02, Ross Lagerwall wrote:
> On 06/29/2016 02:44 PM, Juergen Gross wrote:
>> On 29/06/16 15:31, Ross Lagerwall wrote:
>>> On 06/29/2016 02:00 PM, Juergen Gross wrote:
 On 29/06/16 14:52, Andrew Cooper wrote:
> On 29/06/16 13:44, Juergen Gross wrote:
>> @@ -2068,13 +1964,6 @@ int main(int argc, char *argv[])
>>  /* Tell the kernel we're up and running. */
>>  xenbus_notify_running();
>>
>> -#if defined(XEN_SYSTEMD_ENABLED)
>> -if (systemd) {
>> -sd_notify(1, "READY=1");
>> -fprintf(stderr, SD_NOTICE "xenstored is ready\n");
>> -}
>> -#endif
> Getting rid of the socket configuration for systemd is ok, but we
> should
> keep the sd_notify() calls for when the daemon is started by systemd.
>
> Socket activiation and sd_notify() are orthogonal, and sd_notify() is
> still required if we don't want systemd to treat xenstored as a legacy
> unix daemon.
 So what is the downside of xenstored being treated as a legacy daemon?
 This question is especially interesting for the case of patch 2 being
 considered: xenstored is no longer started by systemd, but by a wrapper
 script which might decide to start the xenstore domain instead.

 Another problem: today xenstored decides whether to call sd_notify()
 by testing the xenstore sockets being specified via systemd. This will
 no longer work. So how to do it now?


>>> One problem with the patch as it currently is implemented is that the
>>> service type is not correct for when xenstored is a daemon. This makes
>>> it difficult to manage with systemd and difficult for other services to
>>> depend on it in a sensible fashion. The end result is subtle races and
>>> occasional failures.
>> Could you please educate me what's wrong? I'm no systemd expert.
> Sorry for the late response.
>
> With Type=oneshot, systemd considers the service to be "started" as soon
> as the ExecStart command completes. After re-reading the patches, I
> realize that timeout_xenstore() should ensure that xenstored is actually
> ready before systemd starts dependent services. This should prevent the
> races I was mentioned previously.
>
> Nevertheless, I feel that this patch series makes the implementation
> worse for users of xenstored as a daemon:
>
> - Because Type=oneshot is not intended to be used for daemon processes,
> systemctl status does not show the service as "running", instead it
> shows "exited". This is surprising, at the very least. I haven't tested,
> but I believe it would also prevent us someday using the systemd service
> management features like Restart=on-failure
>
> - Removes socket activation. Services would have to explicitly depend on
> xenstored.service rather than having an implicit dependency on simply by
> using xenstored.socket. This means configuring explicit ordering, etc.,
> which is easier to get wrong. Socket activation is also generally the
> most efficient way of starting a service.
 So you are not taking xenstore domain into account at all.

 There is no socket for xenstore domain so wanting to rely on socket
 activation is the wrong way.

> - Uses a poll loop to determine whether the daemon is ready or not
> rather than explicit notification from the daemon itself.
 How to do this in the domain case?

> - Uses a shell script wrapper...
 That's on purpose: this enables me to switch between both setups
 (daemon or domain) by modifying only _one_ configuration file.
>>> FWIW I'm pretty sure using a shell script wrapper also clobbers the
>>> SELinux context.  (I forget whether this means xenstore doesn't run or
>>> xenstore runs completely unrestricted.)
>> Okay, this would need to be corrected. I assume it is possible to
>> address such an issue in a script?
>>
>>> (Ross, does XenServer use SELinux?  Any ideas here?)
> 
> XenServer does not use any SELinux.
> 
> 
>>>
> I would suggest asking on the systemd-devel mailing list or the #systemd
> IRC channel on freenode. They should be able to suggest the best way of
> solving this.
 I'm sure I could tweak the whole setup more in direction of systemd.
 I'm not sure the final picture would be the preferred one.
>>> But as Ross said, there are advantages to using the systemd-specific
>>> functionality; and it's likely that the majority of our users will be
>>> running xenstored in dom0.  Doesn't it make sense to at least see if
>>> there are sensible options for how we can

Re: [Xen-devel] [PATCH 1/2] tools: remove systemd xenstore socket definitions

[Ian Jackson]

Andrew Cooper writes ("Re: [Xen-devel] [PATCH 1/2] tools: remove systemd 
xenstore socket definitions"):
> On 20/07/16 12:12, Juergen Gross wrote:
> > To be clear: I don't want to avoid systemd by any means. I just don't
> > want to have a complex and ugly solution with no gain just because
> > doing it the systemd way.
> 
> Given the introduction of this new choice, I agree that socket
> activation isn't sensible.  In the grand scheme of things it doesn't buy
> you much, as xenstored does not match the intended use for socket
> activation (on-demand launch of services when something tries to use its
> socket), as it is a start of day service that runs forever.

xenstore in its own domain is not a `new choice' which is being
`introduced'.  It has been supported by Xen upstream for a long time.
AFAICT from what Juergen is saying it seems that it was broken on
systemd systems by systemd-specific configuration.

> However, socket activation and sd_notify() are entirely orthogonal, and
> the removal of socket activation should not remove sd_notify().

I don't have a clear opinion opinion about this but it seems likely to
me that retaining some kind of systemd `ready now' call is desirable
or even necessary.

Ian.

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

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

[Julien Grall]

On 20/07/16 12:49, Geert Uytterhoeven wrote:

Hi Julien,

On Wed, Jul 20, 2016 at 1:01 PM, Julien Grall  wrote:

On 20/07/16 10:43, Geert Uytterhoeven wrote:

On Tue, Jul 12, 2016 at 9:46 AM, Dirk Behme 
wrote:


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

This property is used to proxy clocks for devices Xen has taken ownership
of, such as UARTs, for which the associated clock controller(s) remain
under the control of Dom0.



I'm not familiar with using XEN at all, but I'm a bit puzzled...

Can't you just add a clocks property to the (virtual) serial device node
in DT?
Then the (virtual) serial device driver can get and enable the clock?


There is no DT node for the Xen console (hvc). The UART used by Xen will be
completely removed from the Device tree.


Why is it removed?


Because the device is used exclusively by Xen and DOM0 should not touch 
it at all (IRQs and MMIOs are not mapped).


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 1/2] tools: remove systemd xenstore socket definitions

[Ian Jackson]

Ross Lagerwall writes ("Re: [Xen-devel] [PATCH 1/2] tools: remove systemd 
xenstore socket definitions"):
> Nevertheless, I feel that this patch series makes the implementation 
> worse for users of xenstored as a daemon:
> 
> - Because Type=oneshot is not intended to be used for daemon processes, 
> systemctl status does not show the service as "running", instead it 
> shows "exited". This is surprising, at the very least. I haven't tested, 
> but I believe it would also prevent us someday using the systemd service 
> management features like Restart=on-failure

This sounds undesirable.  I would like to see this rectified.

> - Removes socket activation. Services would have to explicitly depend on 
> xenstored.service rather than having an implicit dependency on simply by 
> using xenstored.socket. This means configuring explicit ordering, etc., 
> which is easier to get wrong. Socket activation is also generally the 
> most efficient way of starting a service.

Socket activation is a means to and end, not an objective in itself.

> - Uses a poll loop to determine whether the daemon is ready or not 
> rather than explicit notification from the daemon itself.

I agree that polling is rather poor.

> - Uses a shell script wrapper...

I'm afraid that ISTM likeloy that however we do this a shell script
wrapper is going to be needed.

One reason is that there should be _one_ place in the source tree
which reads the relevant config snippets etc. about how the whole Xen
system should be started.

Ian.

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

Re: [Xen-devel] [PATCH] xl: rename variable pause to pause_after_migration

[Ian Jackson]

Wei Liu writes ("[PATCH] xl: rename variable pause to pause_after_migration"):
> Gcc 4.4.4 complained that the "pause" variable introduced in 22b430e0
> ("xl: add option to leave domain paused after migration") shadowed
> pause(2) declaration in unistd.h.
> 
> Rename "pause" to "pause_after_migration" to fix this issue.

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH 1/2] tools: remove systemd xenstore socket definitions

[Juergen Gross]

On 20/07/16 14:08, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [Xen-devel] [PATCH 1/2] tools: remove systemd 
> xenstore socket definitions"):
>> On 20/07/16 12:12, Juergen Gross wrote:
>>> To be clear: I don't want to avoid systemd by any means. I just don't
>>> want to have a complex and ugly solution with no gain just because
>>> doing it the systemd way.
>>
>> Given the introduction of this new choice, I agree that socket
>> activation isn't sensible.  In the grand scheme of things it doesn't buy
>> you much, as xenstored does not match the intended use for socket
>> activation (on-demand launch of services when something tries to use its
>> socket), as it is a start of day service that runs forever.
> 
> xenstore in its own domain is not a `new choice' which is being
> `introduced'.  It has been supported by Xen upstream for a long time.
> AFAICT from what Juergen is saying it seems that it was broken on
> systemd systems by systemd-specific configuration.
> 
>> However, socket activation and sd_notify() are entirely orthogonal, and
>> the removal of socket activation should not remove sd_notify().
> 
> I don't have a clear opinion opinion about this but it seems likely to
> me that retaining some kind of systemd `ready now' call is desirable
> or even necessary.

To be precise: the call might be desirable, but it is not necessary.
With a systemd service type "onehot" systemd will start follow-up units
only after the process started by systemd has exited. So the 'ready now'
indication would probably speed up the boot process by a few msecs.


Juergen


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

Re: [Xen-devel] [PATCH 1/2] arm/traps: fix bug in dump_guest_s1_walk L1 page table offset computation

[Julien Grall]

Hi Jonathan,

Thank you for sending the bug fix.

On 19/07/16 18:15, Jonathan Daugherty wrote:

The dump_guest_s1_walk function was incorrectly using the top 10 bits of
the virtual address to select the L1 page table index.  The correct
amount is 12 bits, resulting in a shift of 20 bits rather than 22.

For more details, see the ARMv7-A ARM, section B3.5, "Short-descriptor


NIT: Could you specify the version of the spec (i.e something similar to 
ARM DDI 0406C.c)?



translation table format."

Signed-off-by: Jonathan Daugherty 


With the suggestion above:

Reviewed-by: Julien Grall 

Regards,


---
 xen/arch/arm/traps.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index a2eb1da..0c10c4d 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2346,7 +2346,7 @@ void dump_guest_s1_walk(struct domain *d, vaddr_t addr)
 }
 first = map_domain_page(mfn);

-offset = addr >> (12+10);
+offset = addr >> (12+8);
 printk("1ST[0x%"PRIx32"] (0x%"PRIpaddr") = 0x%08"PRIx32"\n",
offset, pfn_to_paddr(mfn_x(mfn)), first[offset]);
 if ( !(first[offset] & 0x1) ||



--
Julien Grall

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

Re: [Xen-devel] [PATCH 2/2] arm/traps: fix bug in dump_guest_s1_walk handling of level 2 page tables

[Julien Grall]

On 19/07/16 18:15, Jonathan Daugherty wrote:

dump_guest_s1_walk intends to walk to level 2 page table entries but
was failing to do so because of a check that caused level 2 page table
descriptors to be ignored. This change fixes the check so that level 2
page table walks occur as intended by ignoring descriptors unless their
low two bits match the expected sequence [0,1].

For more information, see the ARMv7-A ARM, section B3.5.


NIT: Could you specify the version of the spec (i.e something similar to 
ARM DDI 0406C.c)?


Also, to be precise the section would be B3.5.1.



Signed-off-by: Jonathan Daugherty 


Reviewed-by: Julien Grall 

Regards,


---
 xen/arch/arm/traps.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 0c10c4d..dfb1949 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2350,7 +2350,7 @@ void dump_guest_s1_walk(struct domain *d, vaddr_t addr)
 printk("1ST[0x%"PRIx32"] (0x%"PRIpaddr") = 0x%08"PRIx32"\n",
offset, pfn_to_paddr(mfn_x(mfn)), first[offset]);
 if ( !(first[offset] & 0x1) ||
- !(first[offset] & 0x2) )
+  (first[offset] & 0x2) )
 goto done;

 mfn = p2m_lookup(d, _gfn(paddr_to_pfn(first[offset])), NULL);



--
Julien Grall

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

Re: [Xen-devel] [PATCH 1/2] tools: remove systemd xenstore socket definitions

[Andrew Cooper]

On 20/07/16 13:08, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [Xen-devel] [PATCH 1/2] tools: remove systemd 
> xenstore socket definitions"):
>> On 20/07/16 12:12, Juergen Gross wrote:
>>> To be clear: I don't want to avoid systemd by any means. I just don't
>>> want to have a complex and ugly solution with no gain just because
>>> doing it the systemd way.
>> Given the introduction of this new choice, I agree that socket
>> activation isn't sensible.  In the grand scheme of things it doesn't buy
>> you much, as xenstored does not match the intended use for socket
>> activation (on-demand launch of services when something tries to use its
>> socket), as it is a start of day service that runs forever.
> xenstore in its own domain is not a `new choice' which is being
> `introduced'.  It has been supported by Xen upstream for a long time.
> AFAICT from what Juergen is saying it seems that it was broken on
> systemd systems by systemd-specific configuration.

I know that the concept of a xenstored stubdomain isn't new, but
sensible configuration and integration into the $INITSYSTEM_OF_CHOICE
definitely is new.

For the record, I fully support the general direction being taken.
Juergen is doing a stellar job improving the status quo, and this will
be great for the Xen community moving forwards.


However, calling what previously exists WRT xenstored stubdomains as
"supported" is laughable.  The lack of integration meant that anyone
trying to use it had to make intrusive modifications to make it start
properly, and the lack of MiniOS ballooning shows that inadequate
consideration was given to production usecases.  It is disingenuous
pretend that stub-xenstored is anywhere beyond "demo" in terms of
real-world usage at the moment.

~Andrew

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

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

[Julien Grall]

Hi,

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

On Wed, 13 Jul 2016, Julien Grall wrote:

Hello,

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

On 07/12/2016 12:10 PM, Julien Grall wrote:

On 12/07/2016 16:08, Boris Ostrovsky wrote:

On 07/12/2016 10:57 AM, Shannon Zhao wrote:

It will affect some others part of the guest if we don't increment the
"maxmem" requested by the user. For ARM the ACPI blob will be exposed
at a specific address that is outside of the guest RAM (see the guest
memory layout in public/arch-arm.h).

We chose this solution over putting in the RAM because the ACPI tables
are not easily relocatable (compare to the device tree, initrd and
kernel) so we could not take advantage of superpage in both stage-2
(hypervisor) and stage-1 (kernel) page table.


Maybe this is something ARM-specific then. For x86 we will want to keep
maxmem unchanged.


I don't think what I described in my previous mail is ARM-specific. The
pressure will be more important on the TLBs, if Xen does not use superpage in
the stage 2 page tables (i.e EPT for x86) no matter the architecture.

IHMO, this seems to be a bigger drawback compare to add few more kilobytes to
maxmem in the toolstack for the ACPI blob. You will loose them when creating
the intermediate page table in any case.


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

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

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


Looking at the x86 code, 1 gigabyte pages seems to be supported.

Boris, do you have any opinions on this?

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 6/9] xen/multicall: Rework arch multicall handling

[Julien Grall]

Hi Andrew,

On 18/07/16 10:51, Andrew Cooper wrote:

The x86 multicall handling was previously some very hairy inline assembly, and
is hard to follow and maintain.

Replace the existing do_multicall_call() with arch_do_multicall_call().  The
x86 side needs to handle both compat and non-compat calls, so pass the full
multicall state, rather than just the multicall_entry sub-structure.

On the ARM side, alter the prototype to match, but there is no resulting
functional change.  On the x86 side, the implementation is now in plain C.

This allows the removal of both asm/multicall.h header files.

Signed-off-by: Andrew Cooper 


For the ARM bits:

Acked-by: Julien Grall 

Regards,

--
Julien Grall

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
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-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-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:
 qemuu5d3217340adcb6c4f0e4af5d2b865331eb2ff63d
baseline version:
 qemuu4f4a9ca4a4386c137301b3662faba076455ff15a

Last test of basis96791  2016-07-08 12:20:07 Z   12 days
Failing since 97271  2016-07-13 13:44:26 Z6 days   11 attempts
Testing same since97665  2016-07-19 17:09:39 Z0 days1 attempts


People who touched revisions under test:
  Alberto Garcia 
  Alex Bennée 
  Alex Williamson 
  Alexander Yarygin 
  Andrew Jones 
  Anthony PERARD 
  Antonio Borneo 
  Ashok Raj 
  Benjamin Herrenschmidt 
  Bharata B Rao 
  Cao jin 
  Cornelia Huck 
  Cédric Le Goater 
  Daniel P. Berrange 
  David Gibson 
  David Hildenbrand 
  Denis V. Lunev 
  Dmitry Osipenko 
  Eduardo Habkost 
  Eric Blake 
  Eugene (jno) Dvurechenski 
  Evgeny Yakovlev 
  Fam Zheng 
  Gerd Hoffmann 
  Gonglei 
  Greg Kurz 
  Haibin Wang 
  Haozhong Zhang 
  He Rongguang 
  Herongguang (Stephen) 
  Igor Mammedov 
  James Hogan 
  Jarkko Lavinen 
  Jason Wang 
  Jeff Cody 
  Jing Liu 
  Jiri Pirko 
  John Snow 
  Juergen Gross 
  Kevin Wolf 
  Laszlo Ersek 
  Leon Alrae 
  Lin Ma 
  Lluís Vilanova 
  Marc Marí 
  Marc-André Lureau 
  Marcin Krzeminski 
  Mark Cave-Ayland 
  Markus Armbruster 
  Max Filippov 
  Max Reitz 
  Md Haris Iqbal 
  Paolo Bonzini 
  Paul Burton 
  Peter Lieven 
  Peter Maydell 
  Pierre Morel 
  Pranith Kumar 
  Reda Sallahi 
  Richard Henderson 
  Richard W.M. Jones 
  Roman Pen 
  Samuel Damashek 
  Sascha Silbe 
  Scott Feldman 
  Sean Bruno 
  Sergey Fedorov 
  Sergey Fedorov 
  Sergey Sorokin 
  Stanislav Shmarov 
  Stefan Hajnoczi 
  Suresh 
  Thomas Huth 
  Vijay 
  Vijaya Kumar K 
  Vladimir 

Re: [Xen-devel] [PATCH 1/2] tools: remove systemd xenstore socket definitions

[Juergen Gross]

On 20/07/16 14:11, Ian Jackson wrote:
> Ross Lagerwall writes ("Re: [Xen-devel] [PATCH 1/2] tools: remove systemd 
> xenstore socket definitions"):
>> Nevertheless, I feel that this patch series makes the implementation 
>> worse for users of xenstored as a daemon:
>>
>> - Because Type=oneshot is not intended to be used for daemon processes, 
>> systemctl status does not show the service as "running", instead it 
>> shows "exited". This is surprising, at the very least. I haven't tested, 

With "RemainAfterExit" specified it is still "active (running)" on my
system.

>> but I believe it would also prevent us someday using the systemd service 
>> management features like Restart=on-failure
> 
> This sounds undesirable.  I would like to see this rectified.

What are you speaking about: a failure during service start or in the
running system?

And how would you want to handle the failure of a xenstore domain?

I think introducing restart capability to xenstored (d being daemon or
domain) will need some more work than just rely on systemd. It should
not be completely daemon specific!

>> - Removes socket activation. Services would have to explicitly depend on 
>> xenstored.service rather than having an implicit dependency on simply by 
>> using xenstored.socket. This means configuring explicit ordering, etc., 
>> which is easier to get wrong. Socket activation is also generally the 
>> most efficient way of starting a service.
> 
> Socket activation is a means to and end, not an objective in itself.
> 
>> - Uses a poll loop to determine whether the daemon is ready or not 
>> rather than explicit notification from the daemon itself.
> 
> I agree that polling is rather poor.

I can remove the polling by adding appropriate code to xenstore daemon:
the non-daemon process should exit only after the daemon is ready to
work.

For the xenstore domain init-xenstore-domain will exit only after the
xenstore is up as the program itself is writing some xenstore entries.

>> - Uses a shell script wrapper...
> 
> I'm afraid that ISTM likeloy that however we do this a shell script
> wrapper is going to be needed.
> 
> One reason is that there should be _one_ place in the source tree
> which reads the relevant config snippets etc. about how the whole Xen
> system should be started.

+1


Juergen

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

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

[Julien Grall]

Hi Konrad,

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

On Wed, 22 Jun 2016, Julien Grall wrote:

Workarounds may require to execute a different path when the platform
is affected by the associated erratum. Furthermore, this may need to
be called in the common code.

To avoid too much intrusion/overhead, the workaround helpers need to
be a nop on architecture which will never have the workaround and have
to be quick to check whether the platform requires it.

The alternative framework is used to transform the check in a single
instruction. When the framework is not available, the helper will have
~6 instructions including 1 instruction load.

The macro will create a handler called check_workaround_x with
 the erratum number.

For instance, the line bellow will create a workaround helper for
erratum #424242 which is enabled when the capability
ARM64_WORKAROUND_424242 is set and only available for ARM64:

CHECK_WORKAROUND_HELPER(424242, ARM64_WORKAROUND_42424242, CONFIG_ARM64)

Signed-off-by: Julien Grall 


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


Do you have any opinions on this patch?

Cheers,





 xen/include/asm-arm/cpuerrata.h | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/xen/include/asm-arm/cpuerrata.h b/xen/include/asm-arm/cpuerrata.h
index fe93beb..b9d8dfc 100644
--- a/xen/include/asm-arm/cpuerrata.h
+++ b/xen/include/asm-arm/cpuerrata.h
@@ -1,8 +1,47 @@
 #ifndef __ARM_CPUERRATA_H
 #define __ARM_CPUERRATA_H

+#include 
+#include 
+#include 
+
 void check_local_cpu_errata(void);

+#ifdef CONFIG_ALTERNATIVE
+
+#define CHECK_WORKAROUND_HELPER(erratum, feature, arch) \
+static inline bool_t check_workaround_##erratum(void)   \
+{   \
+if ( !IS_ENABLED(arch) )\
+return 0;   \
+else\
+{   \
+bool_t ret; \
+\
+asm volatile (ALTERNATIVE("mov %0, #0", \
+  "mov %0, #1", \
+  feature)  \
+  : "=r" (ret));\
+\
+return unlikely(ret);   \
+}   \
+}
+
+#else /* CONFIG_ALTERNATIVE */
+
+#define CHECK_WORKAROUND_HELPER(erratum, feature, arch) \
+static inline bool_t check_workaround_##erratum(void)   \
+{   \
+if ( !IS_ENABLED(arch) )\
+return 0;   \
+else\
+return unlikely(cpus_have_cap(feature));\
+}
+
+#endif
+
+#undef CHECK_WORKAROUND_HELPER
+
 #endif /* __ARM_CPUERRATA_H */
 /*
  * Local variables:
--
1.9.1





--
Julien Grall

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

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

[Geert Uytterhoeven]

Hi Julien,

On Wed, Jul 20, 2016 at 2:10 PM, Julien Grall  wrote:
> On 20/07/16 12:49, Geert Uytterhoeven wrote:
>> On Wed, Jul 20, 2016 at 1:01 PM, Julien Grall 
>> wrote:
>>> On 20/07/16 10:43, Geert Uytterhoeven wrote:
 On Tue, Jul 12, 2016 at 9:46 AM, Dirk Behme 
 wrote:
> Clocks described by this property are reserved for use by Xen, and the
> OS
> must not alter their state any way, such as disabling or gating a
> clock,
> or modifying its rate. Ensuring this may impose constraints on parent
> clocks or other resources used by the clock tree.
>
> This property is used to proxy clocks for devices Xen has taken
> ownership
> of, such as UARTs, for which the associated clock controller(s) remain
> under the control of Dom0.

 I'm not familiar with using XEN at all, but I'm a bit puzzled...

 Can't you just add a clocks property to the (virtual) serial device node
 in DT?
 Then the (virtual) serial device driver can get and enable the clock?
>>>
>>> There is no DT node for the Xen console (hvc). The UART used by Xen will
>>> be
>>> completely removed from the Device tree.
>>
>> Why is it removed?
>
> Because the device is used exclusively by Xen and DOM0 should not touch it
> at all (IRQs and MMIOs are not mapped).

IMHO then it's Xen's responsability to make sure not to disable the clock(s).

Who removes the device node from the DT? If Xen, can't it just remember
which clocks were present in removed device nodes?

What to do on SoCs where the serial device is part of a power area (e.g.
Renesas SH/R-Mobile)? Who will make sure it is not powered down?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

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

Re: [Xen-devel] [PATCH XTF] build: introduce a dist target

[Andrew Cooper]

On 20/07/16 12:55, Wei Liu wrote:
> The install target doesn't honour $PREFIX. Introduce a dist target to
> make it easier to package the artifacts.
>
> Signed-off-by: Wei Liu 
> ---
>  Makefile | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/Makefile b/Makefile
> index 1a8099d..d625b90 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1,6 +1,7 @@
>  MAKEFLAGS += -r
>  ROOT := $(abspath $(CURDIR))
>  DESTDIR ?= $(ROOT)/dist
> +DISTDIR ?= $(ROOT)/dist
>  PREFIX ?= $(ROOT)
>  
>  .PHONY: all
> @@ -10,6 +11,10 @@ all:
>   $(MAKE) -C $$D build; \
>   done
>  
> +.PHONY: dist
> +dist: DESTDIR=$(DISTDIR)$(PREFIX)
> +dist: install

Thusfar, I have been following GNU coding standards.

I don't see any references to DISTDIR, and this usage if `make dist` is
incompatible with the standard expectation.

FWIW, `make dist` seems incompatible with XTF at the moment, because of
the embedded absolute paths needed in the written xl configuration files.



For XenServer, my RPM configuration is:

%{__make} %{?_smp_mflags} install DESTDIR=%{buildroot}/opt/%{name}
PREFIX=/opt/%{name}

to get `make install` to put the content sensibly in the build root, and
to generate files with correct absolute paths.

How are you intending to make use of this new `make dist` target?

~Andrew

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

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

[Dirk Behme]

On 20.07.2016 14:46, Geert Uytterhoeven wrote:

Hi Julien,

On Wed, Jul 20, 2016 at 2:10 PM, Julien Grall  wrote:

On 20/07/16 12:49, Geert Uytterhoeven wrote:

On Wed, Jul 20, 2016 at 1:01 PM, Julien Grall 
wrote:

On 20/07/16 10:43, Geert Uytterhoeven wrote:

On Tue, Jul 12, 2016 at 9:46 AM, Dirk Behme 
wrote:

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

This property is used to proxy clocks for devices Xen has taken
ownership
of, such as UARTs, for which the associated clock controller(s) remain
under the control of Dom0.


I'm not familiar with using XEN at all, but I'm a bit puzzled...

Can't you just add a clocks property to the (virtual) serial device node
in DT?
Then the (virtual) serial device driver can get and enable the clock?


There is no DT node for the Xen console (hvc). The UART used by Xen will
be
completely removed from the Device tree.


Why is it removed?


Because the device is used exclusively by Xen and DOM0 should not touch it
at all (IRQs and MMIOs are not mapped).


IMHO then it's Xen's responsability to make sure not to disable the clock(s).

Who removes the device node from the DT? If Xen, can't it just remember
which clocks were present in removed device nodes?



Yes, we are trying this with "moving" the clocks of the removed nodes to 
the Xen hypervisor node:


https://lists.xen.org/archives/html/xen-devel/2016-06/msg02605.html

The question discussed here is how to deal with these clocks properly in 
Linux, then.


Best regards

Dirk

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

Re: [Xen-devel] [PATCH 1/2] tools: remove systemd xenstore socket definitions

[Juergen Gross]

On 20/07/16 14:32, Andrew Cooper wrote:
> On 20/07/16 13:08, Ian Jackson wrote:
>> Andrew Cooper writes ("Re: [Xen-devel] [PATCH 1/2] tools: remove systemd 
>> xenstore socket definitions"):
>>> On 20/07/16 12:12, Juergen Gross wrote:
 To be clear: I don't want to avoid systemd by any means. I just don't
 want to have a complex and ugly solution with no gain just because
 doing it the systemd way.
>>> Given the introduction of this new choice, I agree that socket
>>> activation isn't sensible.  In the grand scheme of things it doesn't buy
>>> you much, as xenstored does not match the intended use for socket
>>> activation (on-demand launch of services when something tries to use its
>>> socket), as it is a start of day service that runs forever.
>> xenstore in its own domain is not a `new choice' which is being
>> `introduced'.  It has been supported by Xen upstream for a long time.
>> AFAICT from what Juergen is saying it seems that it was broken on
>> systemd systems by systemd-specific configuration.
> 
> I know that the concept of a xenstored stubdomain isn't new, but
> sensible configuration and integration into the $INITSYSTEM_OF_CHOICE
> definitely is new.

Sure. And I appreciate all the discussions taking place.

> For the record, I fully support the general direction being taken.
> Juergen is doing a stellar job improving the status quo, and this will
> be great for the Xen community moving forwards.

Thanks.

> However, calling what previously exists WRT xenstored stubdomains as
> "supported" is laughable.  The lack of integration meant that anyone
> trying to use it had to make intrusive modifications to make it start
> properly, and the lack of MiniOS ballooning shows that inadequate
> consideration was given to production usecases.  It is disingenuous
> pretend that stub-xenstored is anywhere beyond "demo" in terms of
> real-world usage at the moment.

Just trying to change this. :-D


Juergen

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

Re: [Xen-devel] [PATCH XTF] build: introduce a dist target

[Wei Liu]

On Wed, Jul 20, 2016 at 01:52:43PM +0100, Andrew Cooper wrote:
> On 20/07/16 12:55, Wei Liu wrote:
> > The install target doesn't honour $PREFIX. Introduce a dist target to
> > make it easier to package the artifacts.
> >
> > Signed-off-by: Wei Liu 
> > ---
> >  Makefile | 5 +
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/Makefile b/Makefile
> > index 1a8099d..d625b90 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -1,6 +1,7 @@
> >  MAKEFLAGS += -r
> >  ROOT := $(abspath $(CURDIR))
> >  DESTDIR ?= $(ROOT)/dist
> > +DISTDIR ?= $(ROOT)/dist
> >  PREFIX ?= $(ROOT)
> >  
> >  .PHONY: all
> > @@ -10,6 +11,10 @@ all:
> > $(MAKE) -C $$D build; \
> > done
> >  
> > +.PHONY: dist
> > +dist: DESTDIR=$(DISTDIR)$(PREFIX)
> > +dist: install
> 
> Thusfar, I have been following GNU coding standards.
> 
> I don't see any references to DISTDIR, and this usage if `make dist` is
> incompatible with the standard expectation.
> 

There is dist target in GNU standard. I regard DISTDIR an internal
variable. It's fine that the user doesn't set it.

> FWIW, `make dist` seems incompatible with XTF at the moment, because of
> the embedded absolute paths needed in the written xl configuration files.
> 

Exactly. There is hardcoded paths in guest config files.

> 
> 
> For XenServer, my RPM configuration is:
> 
> %{__make} %{?_smp_mflags} install DESTDIR=%{buildroot}/opt/%{name}
> PREFIX=/opt/%{name}

/opt/%{name} appeared twice here and the DESTDIR and PREFIX need to be
kept in sync.

I'm fine with this too. Don't feel I want to argue one way or another.

> 
> to get `make install` to put the content sensibly in the build root, and
> to generate files with correct absolute paths.
> 
> How are you intending to make use of this new `make dist` target?

More or less like what you do for XenServer -- I suppose you just
package buildroot and send that to the test host and install the
artifacts.

Wei.

> 
> ~Andrew

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  b5b5876619bd8ec2e3b8eb4d6a11acee71592eae
baseline version:
 xen  22b430e0e3c5f3d071cb8e2713d7ea33ee8624ec

Last test of basis97661  2016-07-19 15:03:13 Z0 days
Testing same since97707  2016-07-20 11:09:56 Z0 days1 attempts


People who touched revisions under test:
  Dario Faggioli 
  George Dunlap 

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



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

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

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

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


Pushing revision :

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

Re: [Xen-devel] [PATCH XTF] build: introduce a dist target

[Andrew Cooper]

On 20/07/16 14:10, Wei Liu wrote:
> On Wed, Jul 20, 2016 at 01:52:43PM +0100, Andrew Cooper wrote:
>> On 20/07/16 12:55, Wei Liu wrote:
>>> The install target doesn't honour $PREFIX. Introduce a dist target to
>>> make it easier to package the artifacts.
>>>
>>> Signed-off-by: Wei Liu 
>>> ---
>>>  Makefile | 5 +
>>>  1 file changed, 5 insertions(+)
>>>
>>> diff --git a/Makefile b/Makefile
>>> index 1a8099d..d625b90 100644
>>> --- a/Makefile
>>> +++ b/Makefile
>>> @@ -1,6 +1,7 @@
>>>  MAKEFLAGS += -r
>>>  ROOT := $(abspath $(CURDIR))
>>>  DESTDIR ?= $(ROOT)/dist
>>> +DISTDIR ?= $(ROOT)/dist
>>>  PREFIX ?= $(ROOT)
>>>  
>>>  .PHONY: all
>>> @@ -10,6 +11,10 @@ all:
>>> $(MAKE) -C $$D build; \
>>> done
>>>  
>>> +.PHONY: dist
>>> +dist: DESTDIR=$(DISTDIR)$(PREFIX)
>>> +dist: install
>> Thusfar, I have been following GNU coding standards.
>>
>> I don't see any references to DISTDIR, and this usage if `make dist` is
>> incompatible with the standard expectation.
>>
> There is dist target in GNU standard. I regard DISTDIR an internal
> variable. It's fine that the user doesn't set it.
>
>> FWIW, `make dist` seems incompatible with XTF at the moment, because of
>> the embedded absolute paths needed in the written xl configuration files.
>>
> Exactly. There is hardcoded paths in guest config files.
>
>>
>> For XenServer, my RPM configuration is:
>>
>> %{__make} %{?_smp_mflags} install DESTDIR=%{buildroot}/opt/%{name}
>> PREFIX=/opt/%{name}
> /opt/%{name} appeared twice here and the DESTDIR and PREFIX need to be
> kept in sync.
>
> I'm fine with this too. Don't feel I want to argue one way or another.

Hmm, re-reading
https://www.gnu.org/prep/standards/html_node/DESTDIR.html I may have got
the usage of DESTDIR wrong.

It looks like DESTDIR is supposed to be what you are using DISTDIR for.

~Andrew

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

[Xen-devel] [OSSTEST PATCH 3/5] cr-ensure-disk-space: Break out check_space

[Ian Jackson]

Break out the df check into its own subroutine.  iteration_proceed now
becomes iteration_continue and doesn't return a booleanish.

No functional change.

Signed-off-by: Ian Jackson 
---
 cr-ensure-disk-space | 33 +
 1 file changed, 17 insertions(+), 16 deletions(-)

diff --git a/cr-ensure-disk-space b/cr-ensure-disk-space
index a1f838f..63e92f4 100755
--- a/cr-ensure-disk-space
+++ b/cr-ensure-disk-space
@@ -49,7 +49,20 @@ csreadconfig();
 
 logs_select $cfgbase or exit 0;
 
-open LOCK, "> $c{GlobalLockDir}/publish-lock" or die $!;
+sub check_space () {
+open P, "-|", onloghost "df --block-size=1M -P $logdir" or die $!;
+$_= ;
+m/^filesystem/i or die "$_ ?";
+$_= ;
+m,^\S+\s+\d+\s+\d+\s+(\d+)\s+, or die "$_ ?";
+$!=0; $?=0; close P or die "$! $?";
+my $space= $1;
+printf "space: %8d, wanted: %8d ", $space, logcfg('MinSpaceMby');
+return $space >= logcfg('MinSpaceMby');
+}
+
+my $lock = "$c{GlobalLockDir}/publish-lock";
+open LOCK, "> $lock" or die "$lock $!";
 flock LOCK, LOCK_EX or die $!;
 
 $|=1;
@@ -67,17 +80,7 @@ END
 our @flights;
 our %latestref;
 
-sub iteration_continue () {
-open P, "-|", onloghost "df --block-size=1M -P $logdir" or die $!;
-$_= ;
-m/^filesystem/i or die "$_ ?";
-$_= ;
-m,^\S+\s+\d+\s+\d+\s+(\d+)\s+, or die "$_ ?";
-$!=0; $?=0; close P or die "$! $?";
-my $space= $1;
-printf "space: %8d, wanted: %8d ", $space, logcfg('MinSpaceMby');
-return 0 if $space >= logcfg('MinSpaceMby');
-
+sub iteration_proceed () {
 if (!@flights) {
%latestref = ();
open P, "-|", onloghost "ls -1 $logdir" or die $!;
@@ -141,15 +144,13 @@ sub iteration_continue () {
 END
 
 printf "done.\n";
-
-return 1;
 }
 
 db_retry($dbh_tests,[], sub {
 @flights = ();
 for (;;) {
-   iteration_continue()
-   or last;
+   last if check_space();
+   iteration_continue();
 }
 });
 
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 4/5] cr-ensure-disk-space: Run check_space before taking lock

[Ian Jackson]

This allows cr-ensure-disk-space to be a noop if there is enough
space, even if run on a host which doesn't have access to the relevant
lock directory.

Signed-off-by: Ian Jackson 
---
 cr-ensure-disk-space | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/cr-ensure-disk-space b/cr-ensure-disk-space
index 63e92f4..2d299dd 100755
--- a/cr-ensure-disk-space
+++ b/cr-ensure-disk-space
@@ -61,6 +61,8 @@ sub check_space () {
 return $space >= logcfg('MinSpaceMby');
 }
 
+exit 0 if check_space;
+
 my $lock = "$c{GlobalLockDir}/publish-lock";
 open LOCK, "> $lock" or die "$lock $!";
 flock LOCK, LOCK_EX or die $!;
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 2/5] mfi-common: Do not set di_version runvar to empty string in build jobs

[Ian Jackson]

2601498df77c "mfi-common: Do not set di_version runvar to empty string"
fixed the test jobs but not the build jobs, because the setting of
hostos_runvars was (it seems) cloned-and-hacked, and it fixed only one
instance.

Now that we have set_hostos_runvars, use it in create_build_jobs too.

Signed-off-by: Ian Jackson 
---
 mfi-common | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mfi-common b/mfi-common
index 93cc3da..971ded3 100644
--- a/mfi-common
+++ b/mfi-common
@@ -134,7 +134,7 @@ create_build_jobs () {
 *) suite=$defsuite; di_version=$defdi_version;;
 esac
 
-hostos_runvars="all_host_suite=$suite all_host_di_version=$di_version"
+set_hostos_runvars
 
 # In 4.4 onwards xend is off by default. If necessary we build a
 # separate set of binaries with xend enabled in order to run those
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 5/5] mg-list-all-branches: Do not match ${BRANCHES+= ... }

[Ian Jackson]

This is not valid shell syntax and should not appear.  The confusion
seems to have arisen because of the need for to match BRANCHES+=...
(without the surrounding { }).

This results in no change to the output.  (I seem to have collected
this patch some time ago as part of some fixes to mg-list-all-branches
which have by now been applied, but not managed to write up and post
this specific change.)

Signed-off-by: Ian Jackson 
---
 mg-list-all-branches | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mg-list-all-branches b/mg-list-all-branches
index 62d3ff1..989b5ae 100755
--- a/mg-list-all-branches
+++ b/mg-list-all-branches
@@ -14,7 +14,7 @@ foreach my $f (qw(cr-for-branches crontab)) {
 open C, $f or die $!;
 while () {
 next unless
-   m/\$\{$branchvar_re[:+]?=()($branchchr_re+)\b/ ||
+   m/\$\{$branchvar_re:=()($branchchr_re+)\b/ ||
m/$branchvar_re[:+]?=('?)($branchchr_re+?)\1\s/;
 $branches{$_}=1 foreach split /\s+/, $2;
 }
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 1/5] mfi-common: Break out set_hostos_runvars

[Ian Jackson]

We are going to want to reuse this.

No functional change.  (NB shell `local' variables have dynamic rather
than lexical scope.)

Signed-off-by: Ian Jackson 
---
 mfi-common | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/mfi-common b/mfi-common
index ca1e0dd..93cc3da 100644
--- a/mfi-common
+++ b/mfi-common
@@ -76,6 +76,17 @@ job_create_build () {
   ./cs-job-create $flight $job $recipe $global_runvars "$@"
 }
 
+set_hostos_runvars () {
+  # caller should have done
+  #local hostos_runvars
+  #suite=
+  #di_version=   # perhaps
+  hostos_runvars="all_host_suite=$suite"
+  case "$di_version" in
+?*) hostos_runvars+=" all_host_di_version=$di_version"
+  esac
+}
+
 create_build_jobs () {
 
   local arch
@@ -414,10 +425,7 @@ test_matrix_iterate () {
;;
 esac
 
-hostos_runvars="all_host_suite=$suite"
-case "$di_version" in
-  ?*) hostos_runvars+=" all_host_di_version=$di_version"
-esac
+set_hostos_runvars
 
 for kern in ''; do
 
-- 
2.1.4


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

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

[Julien Grall]

On 20/07/2016 13:46, Geert Uytterhoeven wrote:

Hi Julien,


Hello Geert,


On Wed, Jul 20, 2016 at 2:10 PM, Julien Grall  wrote:

On 20/07/16 12:49, Geert Uytterhoeven wrote:

On Wed, Jul 20, 2016 at 1:01 PM, Julien Grall 
wrote:

On 20/07/16 10:43, Geert Uytterhoeven wrote:

On Tue, Jul 12, 2016 at 9:46 AM, Dirk Behme 
wrote:

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

This property is used to proxy clocks for devices Xen has taken
ownership
of, such as UARTs, for which the associated clock controller(s) remain
under the control of Dom0.


I'm not familiar with using XEN at all, but I'm a bit puzzled...

Can't you just add a clocks property to the (virtual) serial device node
in DT?
Then the (virtual) serial device driver can get and enable the clock?


There is no DT node for the Xen console (hvc). The UART used by Xen will
be
completely removed from the Device tree.


Why is it removed?


Because the device is used exclusively by Xen and DOM0 should not touch it
at all (IRQs and MMIOs are not mapped).


IMHO then it's Xen's responsability to make sure not to disable the clock(s).


Xen does not disable the clock(s). The problem is Linux thinks the clock 
is not used and therefore will disable the clock.


Actually Xen does not have any knowledge how to handle clocks (i.e 
setting rate, enabling/disabling). I would recommend you to read the 
binding description in the patch and not the implementation which is 
IHMO misleading.




Who removes the device node from the DT? If Xen, can't it just remember
which clocks were present in removed device nodes?


Xen is removing the node from the DT. Not removing the node will not 
change the problem. Linux is disabling the clock because there is no 
driver which used those clocks.


As the clock subsystem will disable any unused clocks (from Linux point 
of view), the UART will get disabled and the console will be lost.


What we want to achieve with this patch is to let Linux knows that this 
clock is in use by someone else (hypervisor or guest) and:

* If the clock is not shared: don't disable it
* If the clock is shared: don't change the rate



What to do on SoCs where the serial device is part of a power area (e.g.
Renesas SH/R-Mobile)? Who will make sure it is not powered down?


I don't have any knowledge on the Renesas SH/R-Mobile. However, we 
expect some cooperation between DOM0 and Xen to handle the power.


For instance managing the clocks in Xen would require to implement clock 
driver for each SOC because it does not seem to have a generic way to do it.


Given that Linux already knows a lot about the clock, we want to hand 
over the clock control to the hardware domain (i.e dom0). This means 
that we have to find a way to cooperate with it to keep enable clocks 
that we care about.


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 1/2] tools: remove systemd xenstore socket definitions

[George Dunlap]

On 20/07/16 14:23, Ian Jackson wrote:
> But I think you need to be more careful with your use of language.
> `Disingenuous' implies dishonesty.

The way I've heard it used implies a level of pretense, not necessarily
dishonesty -- i.e., pretending that stubdom xenstored was a usable
option when it wasn't actually usable in practice.

I don't think I would disagree with Andy's choice of words here or his
main point (although one should certainly be aware that there may be
other usages that may give offence).

 -George

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

Re: [Xen-devel] [PATCH 1/2] tools: remove systemd xenstore socket definitions

[Ian Jackson]

Andrew Cooper writes ("Re: [Xen-devel] [PATCH 1/2] tools: remove systemd 
xenstore socket definitions"):
> However, calling what previously exists WRT xenstored stubdomains as
> "supported" is laughable.  The lack of integration meant that anyone
> trying to use it had to make intrusive modifications to make it start
> properly, and the lack of MiniOS ballooning shows that inadequate
> consideration was given to production usecases.  It is disingenuous
> pretend that stub-xenstored is anywhere beyond "demo" in terms of
> real-world usage at the moment.

Well, I may well be wrong about how well it was supported before.  I
don't remember these problems but it's been a long time since I have
actually seen reports of stub xenstored in use.

I'm glad to see that you support improvements.

But I think you need to be more careful with your use of language.
`Disingenuous' implies dishonesty.

thanks,
Ian.

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

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

[Boris Ostrovsky]

On 07/20/2016 08:33 AM, Julien Grall wrote:
> Hi,
>
> On 14/07/16 14:37, Stefano Stabellini wrote:
>> On Wed, 13 Jul 2016, Julien Grall wrote:
>>> Hello,
>>>
>>> On 12/07/2016 17:58, Boris Ostrovsky wrote:
 On 07/12/2016 12:10 PM, Julien Grall wrote:
> On 12/07/2016 16:08, Boris Ostrovsky wrote:
>> On 07/12/2016 10:57 AM, Shannon Zhao wrote:
> It will affect some others part of the guest if we don't increment
> the
> "maxmem" requested by the user. For ARM the ACPI blob will be exposed
> at a specific address that is outside of the guest RAM (see the guest
> memory layout in public/arch-arm.h).
>
> We chose this solution over putting in the RAM because the ACPI
> tables
> are not easily relocatable (compare to the device tree, initrd and
> kernel) so we could not take advantage of superpage in both stage-2
> (hypervisor) and stage-1 (kernel) page table.

 Maybe this is something ARM-specific then. For x86 we will want to
 keep
 maxmem unchanged.
>>>
>>> I don't think what I described in my previous mail is ARM-specific. The
>>> pressure will be more important on the TLBs, if Xen does not use
>>> superpage in
>>> the stage 2 page tables (i.e EPT for x86) no matter the architecture.
>>>
>>> IHMO, this seems to be a bigger drawback compare to add few more
>>> kilobytes to
>>> maxmem in the toolstack for the ACPI blob. You will loose them when
>>> creating
>>> the intermediate page table in any case.
>>
>> I agree with Julien. On ARM we have to increase maxmem because I don't
>> think that shattering a superpage is acceptable for just a few KBs. In
>> fact, it's not much about increasing maxmem, but it's about keeping the
>> allocation of guest memory to the value passed by the user in "memory",
>> so that it can be done in the most efficient way possible. (I am
>> assuming users are going to allocate VMs of 2048MB, rather than 2049MB.)
>>
>> I wouldn't want to end up adding to the performance tuning page on the
>> wiki "Make sure to add 1 more MB to the memory of your VM to get the
>> most out of the system."
>>
>> I know that the location of the ACPI blob on x86 is different in guest
>> memory space, but it seems to me that the problem would be the same. Do
>> you have 1 gigabyte pages in stage-2 on x86? If so, I would think twice
>> about this. Otherwise, if you only have 4K and 2MB allocations, then it
>> might not make that much of a difference.
>
> Looking at the x86 code, 1 gigabyte pages seems to be supported.
>
> Boris, do you have any opinions on this?


I don't think I understand the superpage shattering argument.  In x86
the tables live in regular RAM and a guest is free to use those
addresses as regular memory.

This apparently is different from how ARM manages the tables (you said
in an earlier message that they are not part of RAM) so I can see that
taking memory from RAM allocation to store the tables may affect how
mapping is done, potentially causing GB pages to be broken.

In fact (and I am totally speculating here) padding memory for x86 may
actually *cause* shattering because we will have (for example) 2049MB of
RAM to deal with.

If we were talking about large code difference (and if I am wrong about
what I said above) I'd agree that adding a few KB for x86 is OK. But
given that we are talking about a couple of lines of code ifdef'd by
'ARM' (and maybe a comment explaining why) I'd prefer not adding
anything for x86.

-boris


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

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

[Julien Grall]

On 20/07/2016 14:33, Boris Ostrovsky wrote:

On 07/20/2016 08:33 AM, Julien Grall wrote:

Hi,

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

On Wed, 13 Jul 2016, Julien Grall wrote:

Hello,

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

On 07/12/2016 12:10 PM, Julien Grall wrote:

On 12/07/2016 16:08, Boris Ostrovsky wrote:

On 07/12/2016 10:57 AM, Shannon Zhao wrote:

It will affect some others part of the guest if we don't increment
the
"maxmem" requested by the user. For ARM the ACPI blob will be exposed
at a specific address that is outside of the guest RAM (see the guest
memory layout in public/arch-arm.h).

We chose this solution over putting in the RAM because the ACPI
tables
are not easily relocatable (compare to the device tree, initrd and
kernel) so we could not take advantage of superpage in both stage-2
(hypervisor) and stage-1 (kernel) page table.


Maybe this is something ARM-specific then. For x86 we will want to
keep
maxmem unchanged.


I don't think what I described in my previous mail is ARM-specific. The
pressure will be more important on the TLBs, if Xen does not use
superpage in
the stage 2 page tables (i.e EPT for x86) no matter the architecture.

IHMO, this seems to be a bigger drawback compare to add few more
kilobytes to
maxmem in the toolstack for the ACPI blob. You will loose them when
creating
the intermediate page table in any case.


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

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

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


Looking at the x86 code, 1 gigabyte pages seems to be supported.

Boris, do you have any opinions on this?



I don't think I understand the superpage shattering argument.  In x86
the tables live in regular RAM and a guest is free to use those
addresses as regular memory.

This apparently is different from how ARM manages the tables (you said
in an earlier message that they are not part of RAM) so I can see that
taking memory from RAM allocation to store the tables may affect how
mapping is done, potentially causing GB pages to be broken.

In fact (and I am totally speculating here) padding memory for x86 may
actually *cause* shattering because we will have (for example) 2049MB of
RAM to deal with.


Correct me if I am wrong. On your series you are populating the page at 
a specific address for the ACPI tables separately to the RAM allocation. 
So you will shatter GB pages if the user provides 2048MB because the 
ACPI tables is accounted in the 2048MB.


The plan is to call setmaxmem with the size of the RAM + size of the 
ACPI tales. The RAM will still be 2048MB and therefore GB pages may be used.


--
Julien Grall

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

[Xen-devel] [PATCH V3 0/4] Change fixed mmio handlers to a variable number

[Shanker Donthineni]

The maximum number of mmio handlers that are allowed is limited to
a macro MAX_IO_HANDLER(16), which is not enough for supporting per CPU
Redistributor regions. We need at least MAX_IO_HANDLER+CONFIG_NR_CPUS
mmio handlers in order to support ACPI based XEN boot.

This patchset uses the dynamic allocation strategy to allocate memory
resource dynamically depends on the number of Redistributor regions
that are described in the APCI MADT table.

Shanker Donthineni (4):
  arm/io: Use separate memory allocation for mmio handlers
  xen: Add generic implementation of binary search
  xen/arm: io: Use binary search for mmio handler lookup
  arm/vgic: Change fixed number of mmio handlers to variable number

 xen/arch/arm/domain.c  | 12 +++
 xen/arch/arm/io.c  | 52 +++---
 xen/arch/arm/vgic-v2.c |  3 ++-
 xen/arch/arm/vgic-v3.c |  5 -
 xen/arch/arm/vgic.c| 10 +++--
 xen/common/Makefile|  1 +
 xen/common/bsearch.c   | 51 +
 xen/include/asm-arm/mmio.h |  7 +--
 xen/include/asm-arm/vgic.h |  5 +++--
 xen/include/xen/lib.h  |  3 +++
 10 files changed, 115 insertions(+), 34 deletions(-)
 create mode 100644 xen/common/bsearch.c

-- 
Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm Technologies, 
Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.


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

[Xen-devel] [PATCH V3 3/4] xen/arm: io: Use binary search for mmio handler lookup

[Shanker Donthineni]

As the number of I/O handlers increase, the overhead associated with
linear lookup also increases. The system might have maximum of 144
(assuming CONFIG_NR_CPUS=128) mmio handlers. In worst case scenario,
it would require 144 iterations for finding a matching handler. Now
it is time for us to change from linear (complexity O(n)) to a binary
search (complexity O(log n) for reducing mmio handler lookup overhead.

Signed-off-by: Shanker Donthineni 
---
 xen/arch/arm/io.c | 39 ---
 1 file changed, 24 insertions(+), 15 deletions(-)

diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
index 40330f0..e8aa7fa 100644
--- a/xen/arch/arm/io.c
+++ b/xen/arch/arm/io.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -70,27 +71,31 @@ static int handle_write(const struct mmio_handler *handler, 
struct vcpu *v,
handler->priv);
 }
 
-static const struct mmio_handler *find_mmio_handler(struct domain *d,
-paddr_t gpa)
+/* This function assumes that mmio regions are not overlapped */
+static int cmp_mmio_handler(const void *key, const void *elem)
 {
-const struct mmio_handler *handler;
-unsigned int i;
-struct vmmio *vmmio = &d->arch.vmmio;
+const struct mmio_handler *handler0 = key;
+const struct mmio_handler *handler1 = elem;
 
-read_lock(&vmmio->lock);
+if ( handler0->addr < handler1->addr )
+return -1;
 
-for ( i = 0; i < vmmio->num_entries; i++ )
-{
-handler = &vmmio->handlers[i];
+if ( handler0->addr > (handler1->addr + handler1->size) )
+return 1;
 
-if ( (gpa >= handler->addr) &&
- (gpa < (handler->addr + handler->size)) )
-break;
-}
+return 0;
+}
 
-if ( i == vmmio->num_entries )
-handler = NULL;
+static const struct mmio_handler *find_mmio_handler(struct domain *d,
+paddr_t gpa)
+{
+struct vmmio *vmmio = &d->arch.vmmio;
+struct mmio_handler key = {.addr = gpa};
+const struct mmio_handler *handler;
 
+read_lock(&vmmio->lock);
+handler = bsearch(&key, vmmio->handlers, vmmio->num_entries,
+  sizeof(*handler), cmp_mmio_handler);
 read_unlock(&vmmio->lock);
 
 return handler;
@@ -131,6 +136,10 @@ void register_mmio_handler(struct domain *d,
 
 vmmio->num_entries++;
 
+/* Sort mmio handlers in ascending order based on base address */
+sort(vmmio->handlers, vmmio->num_entries, sizeof(struct mmio_handler),
+ cmp_mmio_handler, NULL);
+
 write_unlock(&vmmio->lock);
 }
 
-- 
Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm Technologies, 
Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.


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

[Xen-devel] [PATCH V3 1/4] arm/io: Use separate memory allocation for mmio handlers

[Shanker Donthineni]

The number of mmio handlers are limited to a compile time macro
MAX_IO_HANDLER which is 16. This number is not at all sufficient
to support per CPU distributor regions. Either it needs to be
increased to a bigger number, at least CONFIG_NR_CPUS+16, or
allocate a separate memory for mmio handlers dynamically during
domain build.

This patch uses the dynamic allocation strategy to reduce memory
footprint for 'struct domain' instead of static allocation.

Signed-off-by: Shanker Donthineni 
Acked-by: Julien Grall 
---
 xen/arch/arm/domain.c  |  6 --
 xen/arch/arm/io.c  | 13 +++--
 xen/include/asm-arm/mmio.h |  7 +--
 3 files changed, 20 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 61fc08e..0170cee 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -546,7 +546,7 @@ void vcpu_destroy(struct vcpu *v)
 int arch_domain_create(struct domain *d, unsigned int domcr_flags,
struct xen_arch_domainconfig *config)
 {
-int rc;
+int rc, count;
 
 d->arch.relmem = RELMEM_not_started;
 
@@ -569,7 +569,8 @@ int arch_domain_create(struct domain *d, unsigned int 
domcr_flags,
 share_xen_page_with_guest(
 virt_to_page(d->shared_info), d, XENSHARE_writable);
 
-if ( (rc = domain_io_init(d)) != 0 )
+count = MAX_IO_HANDLER;
+if ( (rc = domain_io_init(d, count)) != 0 )
 goto fail;
 
 if ( (rc = p2m_alloc_table(d)) != 0 )
@@ -663,6 +664,7 @@ void arch_domain_destroy(struct domain *d)
 free_xenheap_pages(d->arch.efi_acpi_table,
get_order_from_bytes(d->arch.efi_acpi_len));
 #endif
+domain_io_free(d);
 }
 
 void arch_domain_shutdown(struct domain *d)
diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
index 5a96836..40330f0 100644
--- a/xen/arch/arm/io.c
+++ b/xen/arch/arm/io.c
@@ -118,7 +118,7 @@ void register_mmio_handler(struct domain *d,
 struct vmmio *vmmio = &d->arch.vmmio;
 struct mmio_handler *handler;
 
-BUG_ON(vmmio->num_entries >= MAX_IO_HANDLER);
+BUG_ON(vmmio->num_entries >= vmmio->max_num_entries);
 
 write_lock(&vmmio->lock);
 
@@ -134,14 +134,23 @@ void register_mmio_handler(struct domain *d,
 write_unlock(&vmmio->lock);
 }
 
-int domain_io_init(struct domain *d)
+int domain_io_init(struct domain *d, int max_count)
 {
 rwlock_init(&d->arch.vmmio.lock);
 d->arch.vmmio.num_entries = 0;
+d->arch.vmmio.max_num_entries = max_count;
+d->arch.vmmio.handlers = xzalloc_array(struct mmio_handler, max_count);
+if ( !d->arch.vmmio.handlers )
+return -ENOMEM;
 
 return 0;
 }
 
+void domain_io_free(struct domain *d)
+{
+xfree(d->arch.vmmio.handlers);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/asm-arm/mmio.h b/xen/include/asm-arm/mmio.h
index 32f10f2..c620eed 100644
--- a/xen/include/asm-arm/mmio.h
+++ b/xen/include/asm-arm/mmio.h
@@ -52,15 +52,18 @@ struct mmio_handler {
 
 struct vmmio {
 int num_entries;
+int max_num_entries;
 rwlock_t lock;
-struct mmio_handler handlers[MAX_IO_HANDLER];
+struct mmio_handler *handlers;
 };
 
 extern int handle_mmio(mmio_info_t *info);
 void register_mmio_handler(struct domain *d,
const struct mmio_handler_ops *ops,
paddr_t addr, paddr_t size, void *priv);
-int domain_io_init(struct domain *d);
+int domain_io_init(struct domain *d, int max_count);
+void domain_io_free(struct domain *d);
+
 
 #endif  /* __ASM_ARM_MMIO_H__ */
 
-- 
Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm Technologies, 
Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.


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

[Xen-devel] [PATCH V3 2/4] xen: Add generic implementation of binary search

[Shanker Donthineni]

This patch adds the generic implementation of binary search algorithm
which is copied from Linux kernel v4.7-rc7. No functional changes.

Signed-off-by: Shanker Donthineni 
Reviewed-by: Andrew Cooper 
Reviewed-by: Julien Grall 
---
Changes since v2:
 Fixed the compilation issue due to a missing ';'.
 Fixed typo.

Changes since v1:
 Removed the header file xen/include/xen/bsearch.h.
 Defined function bsearch() prototype in the header file xen/lib.h.

 xen/common/Makefile   |  1 +
 xen/common/bsearch.c  | 51 +++
 xen/include/xen/lib.h |  3 +++
 3 files changed, 55 insertions(+)
 create mode 100644 xen/common/bsearch.c

diff --git a/xen/common/Makefile b/xen/common/Makefile
index dbf00c6..f8123c2 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -43,6 +43,7 @@ obj-y += schedule.o
 obj-y += shutdown.o
 obj-y += softirq.o
 obj-y += sort.o
+obj-y += bsearch.o
 obj-y += smp.o
 obj-y += spinlock.o
 obj-y += stop_machine.o
diff --git a/xen/common/bsearch.c b/xen/common/bsearch.c
new file mode 100644
index 000..7090930
--- /dev/null
+++ b/xen/common/bsearch.c
@@ -0,0 +1,51 @@
+/*
+ * A generic implementation of binary search for the Linux kernel
+ *
+ * Copyright (C) 2008-2009 Ksplice, Inc.
+ * Author: Tim Abbott 
+ *
+ * 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; version 2.
+ */
+
+#include 
+
+/*
+ * bsearch - binary search an array of elements
+ * @key: pointer to item being searched for
+ * @base: pointer to first element to search
+ * @num: number of elements
+ * @size: size of each element
+ * @cmp: pointer to comparison function
+ *
+ * This function does a binary search on the given array.  The
+ * contents of the array should already be in ascending sorted order
+ * under the provided comparison function.
+ *
+ * Note that the key need not have the same type as the elements in
+ * the array, e.g. key could be a string and the comparison function
+ * could compare the string with the struct's name field.  However, if
+ * the key and elements in the array are of the same type, you can use
+ * the same comparison function for both sort() and bsearch().
+ */
+void *bsearch(const void *key, const void *base, size_t num, size_t size,
+ int (*cmp)(const void *key, const void *elt))
+{
+   size_t start = 0, end = num;
+   int result;
+
+   while (start < end) {
+   size_t mid = start + (end - start) / 2;
+
+   result = cmp(key, base + mid * size);
+   if (result < 0)
+   end = mid;
+   else if (result > 0)
+   start = mid + 1;
+   else
+   return (void *)base + mid * size;
+   }
+
+   return NULL;
+}
diff --git a/xen/include/xen/lib.h b/xen/include/xen/lib.h
index b1b0fb2..b90d582 100644
--- a/xen/include/xen/lib.h
+++ b/xen/include/xen/lib.h
@@ -153,4 +153,7 @@ void dump_execstate(struct cpu_user_regs *);
 
 void init_constructors(void);
 
+void *bsearch(const void *key, const void *base, size_t num, size_t size,
+  int (*cmp)(const void *key, const void *elt));
+
 #endif /* __LIB_H__ */
-- 
Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm Technologies, 
Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.


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

[Xen-devel] [PATCH V3 4/4] arm/vgic: Change fixed number of mmio handlers to variable number

[Shanker Donthineni]

Compute the number of mmio handlers that are required for vGICv3 and
vGICv2 emulation drivers in vgic_v3_init()/vgic_v2_init(). Augment
this variable number of mmio handers to a fixed number MAX_IO_HANDLER
and pass it to domain_io_init() to allocate enough memory.

New code path:
 domain_vgic_register(&count)
   domain_io_init(count + MAX_IO_HANDLER)
 domain_vgic_init()

Signed-off-by: Shanker Donthineni 
---
 xen/arch/arm/domain.c  | 12 +++-
 xen/arch/arm/vgic-v2.c |  3 ++-
 xen/arch/arm/vgic-v3.c |  5 -
 xen/arch/arm/vgic.c| 10 +++---
 xen/include/asm-arm/vgic.h |  5 +++--
 5 files changed, 19 insertions(+), 16 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 0170cee..4e5259b 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -546,7 +546,7 @@ void vcpu_destroy(struct vcpu *v)
 int arch_domain_create(struct domain *d, unsigned int domcr_flags,
struct xen_arch_domainconfig *config)
 {
-int rc, count;
+int rc, count = 0;
 
 d->arch.relmem = RELMEM_not_started;
 
@@ -569,10 +569,6 @@ int arch_domain_create(struct domain *d, unsigned int 
domcr_flags,
 share_xen_page_with_guest(
 virt_to_page(d->shared_info), d, XENSHARE_writable);
 
-count = MAX_IO_HANDLER;
-if ( (rc = domain_io_init(d, count)) != 0 )
-goto fail;
-
 if ( (rc = p2m_alloc_table(d)) != 0 )
 goto fail;
 
@@ -609,6 +605,12 @@ int arch_domain_create(struct domain *d, unsigned int 
domcr_flags,
 goto fail;
 }
 
+if ( (rc = domain_vgic_register(d, &count)) != 0 )
+goto fail;
+
+if ( (rc = domain_io_init(d, count + MAX_IO_HANDLER)) != 0 )
+goto fail;
+
 if ( (rc = domain_vgic_init(d, config->nr_spis)) != 0 )
 goto fail;
 
diff --git a/xen/arch/arm/vgic-v2.c b/xen/arch/arm/vgic-v2.c
index 6a5e67b..c6d280e 100644
--- a/xen/arch/arm/vgic-v2.c
+++ b/xen/arch/arm/vgic-v2.c
@@ -711,7 +711,7 @@ static const struct vgic_ops vgic_v2_ops = {
 .max_vcpus = 8,
 };
 
-int vgic_v2_init(struct domain *d)
+int vgic_v2_init(struct domain *d, int *mmio_count)
 {
 if ( !vgic_v2_hw.enabled )
 {
@@ -721,6 +721,7 @@ int vgic_v2_init(struct domain *d)
 return -ENODEV;
 }
 
+*mmio_count = 1; /* Only GICD region */
 register_vgic_ops(d, &vgic_v2_ops);
 
 return 0;
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index be9a9a3..ec038a3 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -1499,7 +1499,7 @@ static const struct vgic_ops v3_ops = {
 .max_vcpus = 4096,
 };
 
-int vgic_v3_init(struct domain *d)
+int vgic_v3_init(struct domain *d, int *mmio_count)
 {
 if ( !vgic_v3_hw.enabled )
 {
@@ -1509,6 +1509,9 @@ int vgic_v3_init(struct domain *d)
 return -ENODEV;
 }
 
+/* GICD region + number of Redistributors */
+*mmio_count = vgic_v3_rdist_count(d) + 1;
+
 register_vgic_ops(d, &v3_ops);
 
 return 0;
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index a7ccfe7..768cb91 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -88,18 +88,18 @@ static void vgic_rank_init(struct vgic_irq_rank *rank, 
uint8_t index,
 rank->vcpu[i] = vcpu;
 }
 
-static int domain_vgic_register(struct domain *d)
+int domain_vgic_register(struct domain *d, int *mmio_count)
 {
 switch ( d->arch.vgic.version )
 {
 #ifdef CONFIG_HAS_GICV3
 case GIC_V3:
-if ( vgic_v3_init(d) )
+if ( vgic_v3_init(d, mmio_count) )
return -ENODEV;
 break;
 #endif
 case GIC_V2:
-if ( vgic_v2_init(d) )
+if ( vgic_v2_init(d, mmio_count) )
 return -ENODEV;
 break;
 default:
@@ -124,10 +124,6 @@ int domain_vgic_init(struct domain *d, unsigned int 
nr_spis)
 
 d->arch.vgic.nr_spis = nr_spis;
 
-ret = domain_vgic_register(d);
-if ( ret < 0 )
-return ret;
-
 spin_lock_init(&d->arch.vgic.lock);
 
 d->arch.vgic.shared_irqs =
diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
index c3cc4f6..300f461 100644
--- a/xen/include/asm-arm/vgic.h
+++ b/xen/include/asm-arm/vgic.h
@@ -304,9 +304,10 @@ extern int vgic_emulate(struct cpu_user_regs *regs, union 
hsr hsr);
 extern void vgic_disable_irqs(struct vcpu *v, uint32_t r, int n);
 extern void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n);
 extern void register_vgic_ops(struct domain *d, const struct vgic_ops *ops);
-int vgic_v2_init(struct domain *d);
-int vgic_v3_init(struct domain *d);
+int vgic_v2_init(struct domain *d, int *mmio_count);
+int vgic_v3_init(struct domain *d, int *mmio_count);
 
+extern int domain_vgic_register(struct domain *d, int *mmio_count);
 extern int vcpu_vgic_free(struct vcpu *v);
 extern int vgic_to_sgi(struct vcpu *v, register_t sgir,
enum gic_sgi_mode irqmode, int virq,
-- 
Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm Technologies, 
Inc.
Qualcomm Te

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

[Boris Ostrovsky]

On 07/20/2016 09:41 AM, Julien Grall wrote:
>
>
> On 20/07/2016 14:33, Boris Ostrovsky wrote:
>> On 07/20/2016 08:33 AM, Julien Grall wrote:
>>> Hi,
>>>
>>> On 14/07/16 14:37, Stefano Stabellini wrote:
 On Wed, 13 Jul 2016, Julien Grall wrote:
> Hello,
>
> On 12/07/2016 17:58, Boris Ostrovsky wrote:
>> On 07/12/2016 12:10 PM, Julien Grall wrote:
>>> On 12/07/2016 16:08, Boris Ostrovsky wrote:
 On 07/12/2016 10:57 AM, Shannon Zhao wrote:
>>> It will affect some others part of the guest if we don't increment
>>> the
>>> "maxmem" requested by the user. For ARM the ACPI blob will be
>>> exposed
>>> at a specific address that is outside of the guest RAM (see the
>>> guest
>>> memory layout in public/arch-arm.h).
>>>
>>> We chose this solution over putting in the RAM because the ACPI
>>> tables
>>> are not easily relocatable (compare to the device tree, initrd and
>>> kernel) so we could not take advantage of superpage in both stage-2
>>> (hypervisor) and stage-1 (kernel) page table.
>>
>> Maybe this is something ARM-specific then. For x86 we will want to
>> keep
>> maxmem unchanged.
>
> I don't think what I described in my previous mail is
> ARM-specific. The
> pressure will be more important on the TLBs, if Xen does not use
> superpage in
> the stage 2 page tables (i.e EPT for x86) no matter the architecture.
>
> IHMO, this seems to be a bigger drawback compare to add few more
> kilobytes to
> maxmem in the toolstack for the ACPI blob. You will loose them when
> creating
> the intermediate page table in any case.

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

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

 I know that the location of the ACPI blob on x86 is different in guest
 memory space, but it seems to me that the problem would be the
 same. Do
 you have 1 gigabyte pages in stage-2 on x86? If so, I would think
 twice
 about this. Otherwise, if you only have 4K and 2MB allocations,
 then it
 might not make that much of a difference.
>>>
>>> Looking at the x86 code, 1 gigabyte pages seems to be supported.
>>>
>>> Boris, do you have any opinions on this?
>>
>>
>> I don't think I understand the superpage shattering argument.  In x86
>> the tables live in regular RAM and a guest is free to use those
>> addresses as regular memory.
>>
>> This apparently is different from how ARM manages the tables (you said
>> in an earlier message that they are not part of RAM) so I can see that
>> taking memory from RAM allocation to store the tables may affect how
>> mapping is done, potentially causing GB pages to be broken.
>>
>> In fact (and I am totally speculating here) padding memory for x86 may
>> actually *cause* shattering because we will have (for example) 2049MB of
>> RAM to deal with.
>
> Correct me if I am wrong. On your series you are populating the page
> at a specific address for the ACPI tables separately to the RAM
> allocation. So you will shatter GB pages if the user provides 2048MB
> because the ACPI tables is accounted in the 2048MB.

And to be honest I am not convinced this was a well selected address
(0xfc00). I am actually thinking about moving it down (this may
require changing dsdt.asl). I don't know whether I will actually do it
in this version but it is certainly a possibility.

-boris

>
> The plan is to call setmaxmem with the size of the RAM + size of the
> ACPI tales. The RAM will still be 2048MB and therefore GB pages may be
> used.
>



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

[Xen-devel] [PATCH 0/2] Two coverity inspired patches for xenstored

[Wei Liu]

Wei Liu (2):
  xenstore: send error earlier in do_mkdir
  xenstore: add assertion in database dumping code

 tools/xenstore/xenstored_core.c | 7 +++
 1 file changed, 7 insertions(+)

-- 
2.1.4


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

[Xen-devel] [PATCH 1/2] xenstore: send error earlier in do_mkdir

[Wei Liu]

XenServer's coverity instance complains that a few lines below
create_node dereferences NULL if name == NULL. It however fails to
figure out that if node is NULL, errno won't be ENOENT, so do_mkdir
should have bailed before create_node.

That said, it would be good if we don't need to go through the hops.  We
can bail earlier if name is NULL.

Signed-off-by: Wei Liu 
---
Cc: Ian Jackson 
---
 tools/xenstore/xenstored_core.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index ffc0634..5b2a49b 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -981,6 +981,12 @@ static void do_mkdir(struct connection *conn, struct 
buffered_data *in)
struct node *node;
const char *name = onearg(in);
 
+   if (!name) {
+   errno = EINVAL;
+   send_error(conn, errno);
+   return;
+   }
+
name = canonicalize(conn, name);
node = get_node(conn, in, name, XS_PERM_WRITE);
 
-- 
2.1.4


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

Re: [Xen-devel] [PATCH 1/2] tools: remove systemd xenstore socket definitions

[Andrew Cooper]

On 20/07/16 14:29, George Dunlap wrote:
> On 20/07/16 14:23, Ian Jackson wrote:
>> But I think you need to be more careful with your use of language.
>> `Disingenuous' implies dishonesty.
> The way I've heard it used implies a level of pretense, not necessarily
> dishonesty -- i.e., pretending that stubdom xenstored was a usable
> option when it wasn't actually usable in practice.

This was my intended meaning.  My apologies if it came across anyhow else.

~Andrew

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

[Xen-devel] [PATCH 2/2] xenstore: add assertion in database dumping code

[Ian Jackson]

Wei Liu writes ("[PATCH 2/2] xenstore: add assertion in database dumping code"):
> If memfile is NULL, the signal handler won't be installed, hence fopen
> won't dereference NULL. Coverity is not smart enough to figure that out
> unfortunately.

Acked-by: Ian Jackson 

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

[Xen-devel] [PATCH 1/2] xenstore: send error earlier in do_mkdir

[Ian Jackson]

Wei Liu writes ("[PATCH 1/2] xenstore: send error earlier in do_mkdir"):
> XenServer's coverity instance complains that a few lines below
> create_node dereferences NULL if name == NULL. It however fails to
> figure out that if node is NULL, errno won't be ENOENT, so do_mkdir
> should have bailed before create_node.
> 
> That said, it would be good if we don't need to go through the hops.  We
> can bail earlier if name is NULL.

Acked-by: Ian Jackson 

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

[Xen-devel] [PATCH 2/2] xenstore: add assertion in database dumping code

[Wei Liu]

If memfile is NULL, the signal handler won't be installed, hence fopen
won't dereference NULL. Coverity is not smart enough to figure that out
unfortunately.

Add an assertion to prevent coverity from complaining.

Signed-off-by: Wei Liu 
---
Cc: Ian Jackson 
---
 tools/xenstore/xenstored_core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 5b2a49b..693d47d 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -2135,6 +2135,7 @@ int main(int argc, char *argv[])
if (trigger_talloc_report) {
FILE *out;
 
+   assert(memfile);
trigger_talloc_report = false;
out = fopen(memfile, "a");
if (out) {
-- 
2.1.4


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

Re: [Xen-devel] [PATCH v2 2/7] tools/helper: honour XEN_RUN_DIR in init-xenstore-domain.c

[Ian Jackson]

Wei Liu writes ("[PATCH v2 2/7] tools/helper: honour XEN_RUN_DIR in 
init-xenstore-domain.c"):
> Place the PID file under XEN_RUN_DIR. Note that this change the default
> location from /var/run to /var/run/xen.
> 
> Generate a _paths.h as that is required to make this change work.

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH v2 1/7] xenconsoled: honour XEN_RUN_DIR

[Ian Jackson]

Wei Liu writes ("[PATCH v2 1/7] xenconsoled: honour XEN_RUN_DIR"):
> Place the PID file under XEN_RUN_DIR by default. Note this change the
> default location from /var/run to /var/run/xen.
> 
> Signed-off-by: Wei Liu 

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH v2 6/7] libxenstat: honour XEN_RUN_DIR

[Ian Jackson]

Wei Liu writes ("[PATCH v2 6/7] libxenstat: honour XEN_RUN_DIR"):
> This is because libxl uses XEN_RUN_DIR to generate the socket path for
> libxenstat while libxenstat itself uses hard-coded path, which is not
> necessarily the same path as XEN_RUN_DIR.  The default configuration
> happened to work because XEN_RUN_DIR defaulted to /var/run/xen, which
> matched the hard-coded path.
> 
> We should make libxenstat use XEN_RUN_DIR so that it works with
> non-default configuration.
> 
> Generate a _paths.h because it is required to make this change work.

Acked-by: Ian Jackson 

> Backport candidate.

Thanks.  Can you let me know when it's applied to staging ?

Thanks,
Ian.

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

Re: [Xen-devel] [PATCH v2 6/7] libxenstat: honour XEN_RUN_DIR

[Wei Liu]

On Wed, Jul 20, 2016 at 03:40:56PM +0100, Ian Jackson wrote:
> Wei Liu writes ("[PATCH v2 6/7] libxenstat: honour XEN_RUN_DIR"):
> > This is because libxl uses XEN_RUN_DIR to generate the socket path for
> > libxenstat while libxenstat itself uses hard-coded path, which is not
> > necessarily the same path as XEN_RUN_DIR.  The default configuration
> > happened to work because XEN_RUN_DIR defaulted to /var/run/xen, which
> > matched the hard-coded path.
> > 
> > We should make libxenstat use XEN_RUN_DIR so that it works with
> > non-default configuration.
> > 
> > Generate a _paths.h because it is required to make this change work.
> 
> Acked-by: Ian Jackson 
> 
> > Backport candidate.
> 
> Thanks.  Can you let me know when it's applied to staging ?
> 

$ git describe --contains eb141d23a00a349dc1474bb982e7812fc091f845
4.6.0-rc1~844

So backport to 4.6 and 4.7.

Wei.

> Thanks,
> Ian.

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

[Xen-devel] [PATCH LIVEPATCH-BUILD-TOOLS 2/2] Prevent spurious rebuilding

[Ross Lagerwall]

Don't change the timestamp of arch/x86/Makefile when editing it since it
forces much of the Xen tree to be rebuilt and then requires many
invocations of create-diff-tool.

This is safe since the Makefile change only changes the final link rule,
and xen will be relinked anyway.
---
 livepatch-build | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/livepatch-build b/livepatch-build
index d9d9da3..c057fa1 100755
--- a/livepatch-build
+++ b/livepatch-build
@@ -98,10 +98,13 @@ function build_special()
 # Build with special GCC flags
 cd "${SRCDIR}/xen" || die
 sed -i 's/CFLAGS += -nostdinc/CFLAGS += -nostdinc -ffunction-sections 
-fdata-sections/' Rules.mk
+cp -p arch/x86/Makefile arch/x86/Makefile.bak
 sed -i 's/--section-alignment=0x20/--section-alignment=0x1000/' 
arch/x86/Makefile
+# Restore timestamps to prevent spurious rebuilding
+touch --reference=arch/x86/Makefile.bak arch/x86/Makefile
 make "-j$CPUS" $XEN_DEBUG &> "${OUTPUT}/build_${name}_compile.log" || die
 sed -i 's/CFLAGS += -nostdinc -ffunction-sections -fdata-sections/CFLAGS 
+= -nostdinc/' Rules.mk
-sed -i 's/--section-alignment=0x1000/--section-alignment=0x20/' 
arch/x86/Makefile
+mv -f arch/x86/Makefile.bak arch/x86/Makefile
 
 unset LIVEPATCH_BUILD_DIR
 unset LIVEPATCH_CAPTURE_DIR
-- 
2.7.4


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

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

[osstest service owner]

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

Regressions :-(

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

version targeted for testing:
 ovmf 9ba25c7db7e918c3c911dd20641ba54ce721e872
baseline version:
 ovmf dc99315b8732b6e3032d01319d3f534d440b43d0

Last test of basis94748  2016-05-24 22:43:25 Z   56 days
Failing since 94750  2016-05-25 03:43:08 Z   56 days  120 attempts
Testing same since97653  2016-07-19 09:40:21 Z1 days2 attempts


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

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



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

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

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

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


Not pushing.

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

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

[Xen-devel] [PATCH LIVEPATCH-BUILD-TOOLS 1/2] Fix getopt parsing of long options

[Ross Lagerwall]

---
 livepatch-build | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/livepatch-build b/livepatch-build
index 7395b49..d9d9da3 100755
--- a/livepatch-build
+++ b/livepatch-build
@@ -185,7 +185,7 @@ usage() {
 
 find_tools || die "can't find supporting tools"
 
-options=$(getopt -o hs:p:c:o:j:k:d -l 
"help,srcdir:patch:config:output:cpus:,skip:,debug,xen-debug,xen-syms:,depends:,prelink"
 -- "$@") || die "getopt failed"
+options=$(getopt -o hs:p:c:o:j:k:d -l 
"help,srcdir:,patch:,config:,output:,cpus:,skip:,debug,xen-debug,xen-syms:,depends:,prelink"
 -- "$@") || die "getopt failed"
 
 eval set -- "$options"
 
-- 
2.7.4


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

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

[osstest service owner]

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

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. 97638

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

version targeted for testing:
 libvirt  8ee6a99e7c2b31e7f3cdeabf59e211854da26f5d
baseline version:
 libvirt  c62e9d4199afb0e6cff1b6818330b115417addc1

Last test of basis97638  2016-07-19 04:22:58 Z1 days
Testing same since97688  2016-07-20 04:21:45 Z0 days1 attempts


People who touched revisions under test:
  Cédric Bosdonnat 
  Erik Skultety 
  John Ferlan 
  Julio Faracco 

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



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

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

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

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


Not pushing.


commit 8ee6a99e7c2b31e7f3cdeabf59e211854da26f5d
Author: Cédric Bosdonnat 
Date:   Tue Jul 19 16:23:25 2016 +0200

lxc: errors after the handshake won't be reported

Any error happening after the hand shake in the lxc controller
will not result in a failure as errors are checked during the handshake.
Move the handshake after the last possible error.

commit cedd2ab28262db62976b351dbf2a0f8d9f88ca9e
Author: Cédric Bosdonnat 
Date:   Mon Jan 18 11:22:32 2016 +0100

virt-aa-helper: better write denials handling

Better fix replacing c726af2d: introducing an 'R' permission to
add read rule, but no explicit deny write rule.

commit da86c6c22674ccc14722

Re: [Xen-devel] [PATCH 0/2] Two coverity inspired patches for xenstored

[Wei Liu]

Pushed.

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

Re: [Xen-devel] [PATCH v2 0/7] Remove hard-coded /var/run in tools

[Wei Liu]

Series pushed to staging.

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

Re: [Xen-devel] [PATCH] xl: rename variable pause to pause_after_migration

[Wei Liu]

Pushed.

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

[Xen-devel] [PATCH v5 4/7] xen/arm: Document the errata implemented in Xen

[Julien Grall]

The new document will help to keep track of each erratum Xen is able to
handle.

The text is based on the Linux doc in Documents/arm64/silicon-errata.txt.

Also list the current errata that Xen is aware of.

Signed-off-by: Julien Grall 
Acked-by: Stefano Stabellini 

---
Changes in v4:
- Fix grammar in the document : s/by ARM64/on ARM64/
- Add Stefano's acked-by

Changes in v3:
- Fix grammar in the commit message
- s/Linux/Xen/
- Mention that runtime patching is only supported by ARM64
---
 docs/misc/arm/silicon-errata.txt | 45 
 1 file changed, 45 insertions(+)
 create mode 100644 docs/misc/arm/silicon-errata.txt

diff --git a/docs/misc/arm/silicon-errata.txt b/docs/misc/arm/silicon-errata.txt
new file mode 100644
index 000..5d54694
--- /dev/null
+++ b/docs/misc/arm/silicon-errata.txt
@@ -0,0 +1,45 @@
+Silicon Errata and Software Workarounds
+===
+
+It is an unfortunate fact of life that hardware is often produced with
+so-called "errata", which can cause it to deviate from the architecture
+under specific circumstances.  For hardware produced by ARM, these
+errata are broadly classified into the following categories:
+
+  Category A: A critical error without a viable workaround.
+  Category B: A significant or critical error with an acceptable
+  workaround.
+  Category C: A minor error that is not expected to occur under normal
+  operation.
+
+For more information, consult one of the "Software Developers Errata
+Notice" documents available on infocenter.arm.com (registration
+required).
+
+As far as Xen is concerned, Category B errata may require some special
+treatment in the hypervisor. For example, avoiding a particular sequence
+of code, or configuring the processor in a particular way. A less common
+situation may require similar actions in order to declassify a Category A
+erratum into a Category C erratum. These are collectively known as
+"software workarounds" and are only required in the minority of cases
+(e.g. those cases that both require a non-secure workaround *and* can
+be triggered by Xen).
+
+For software workarounds that may adversely impact systems unaffected by
+the erratum in question, a Kconfig entry is added under "ARM errata
+workarounds via the alternatives framework". These are enabled by default
+and patched in at runtime when an affected CPU is detected. Note that
+runtime patching is only supported on ARM64. For less-intrusive workarounds,
+a Kconfig option is not available and the code is structured (preferably
+with a comment) in such a way that the erratum will not be hit.
+
+This approach can make it slightly onerous to determine exactly which
+errata are worked around in an arbitrary hypervisor source tree, so this
+file acts as a registry of software workarounds in the Xen hypervisor and
+will be updated when new workarounds are committed and backported to
+stable hypervisors.
+
+| Implementor| Component   | Erratum ID  | Kconfig 
|
+++-+-+-+
+| ARM| Cortex-A15  | #766422 | N/A 
|
+| ARM| Cortex-A57  | #852523 | N/A 
|
-- 
1.9.1


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

[Xen-devel] [PATCH v5 5/7] xen/arm: arm64: Add Cortex-A53 cache errata workaround

[Julien Grall]

The ARM errata 819472, 827319 and 824069 define the same workaround for
these hardware issues in certain Cortex-A53 parts.

The cache instructions "dc cvac" and "dc cvau" need to be upgraded to
"dc civac".

Use the alternative framework to replace those instructions only on
affected cores.

Whilst the errata affect cache instructions issued at any exception
level, it is not necessary to trap EL1/EL0 data cache instructions
access in order to upgrade them. Indeed the data cache corruption would
always be at the address used by the data cache instructions. Note that
this address could point to a shared memory between guests and the
hypervisors, however all the information present in it are be validated
before any use.

Therefore a malicious guest could only hurt itself. Note that all the
guests should implement/enable the workaround for the affected cores.

Signed-off-by: Julien Grall 
Acked-by: Stefano Stabellini 

---
Changes in v4:
- Add Stefano's acked-by

Changes in v3:
- Remove conflict introduced whilst rebasing this series
---
 docs/misc/arm/silicon-errata.txt |  3 ++
 xen/arch/arm/Kconfig | 71 
 xen/arch/arm/arm64/cache.S   |  2 ++
 xen/arch/arm/cpuerrata.c | 17 ++
 xen/include/asm-arm/arm64/page.h |  7 +++-
 xen/include/asm-arm/cpufeature.h |  4 ++-
 xen/include/asm-arm/processor.h  |  6 
 7 files changed, 108 insertions(+), 2 deletions(-)

diff --git a/docs/misc/arm/silicon-errata.txt b/docs/misc/arm/silicon-errata.txt
index 5d54694..546ccd7 100644
--- a/docs/misc/arm/silicon-errata.txt
+++ b/docs/misc/arm/silicon-errata.txt
@@ -42,4 +42,7 @@ stable hypervisors.
 | Implementor| Component   | Erratum ID  | Kconfig 
|
 
++-+-+-+
 | ARM| Cortex-A15  | #766422 | N/A 
|
+| ARM| Cortex-A53  | #827319 | ARM64_ERRATUM_827319
|
+| ARM| Cortex-A53  | #824069 | ARM64_ERRATUM_824069
|
+| ARM| Cortex-A53  | #819472 | ARM64_ERRATUM_819472
|
 | ARM| Cortex-A57  | #852523 | N/A 
|
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 0141bd9..a473d9c 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -53,6 +53,77 @@ config ALTERNATIVE
 
 endmenu
 
+menu "ARM errata workaround via the alternative framework"
+   depends on ALTERNATIVE
+
+config ARM64_ERRATUM_827319
+   bool "Cortex-A53: 827319: Data cache clean instructions might cause 
overlapping transactions to the interconnect"
+   default y
+   depends on ARM_64
+   help
+ This option adds an alternative code sequence to work around ARM
+ erratum 827319 on Cortex-A53 parts up to r0p2 with an AMBA 5 CHI
+ master interface and an L2 cache.
+
+ Under certain conditions this erratum can cause a clean line eviction
+ to occur at the same time as another transaction to the same address
+ on the AMBA 5 CHI interface, which can cause data corruption if the
+ interconnect reorders the two transactions.
+
+ The workaround promotes data cache clean instructions to
+ data cache clean-and-invalidate.
+ Please note that this does not necessarily enable the workaround,
+ as it depends on the alternative framework, which will only patch
+ the kernel if an affected CPU is detected.
+
+ If unsure, say Y.
+
+config ARM64_ERRATUM_824069
+   bool "Cortex-A53: 824069: Cache line might not be marked as clean after 
a CleanShared snoop"
+   default y
+   depends on ARM_64
+   help
+ This option adds an alternative code sequence to work around ARM
+ erratum 824069 on Cortex-A53 parts up to r0p2 when it is connected
+ to a coherent interconnect.
+
+ If a Cortex-A53 processor is executing a store or prefetch for
+ write instruction at the same time as a processor in another
+ cluster is executing a cache maintenance operation to the same
+ address, then this erratum might cause a clean cache line to be
+ incorrectly marked as dirty.
+
+ The workaround promotes data cache clean instructions to
+ data cache clean-and-invalidate.
+ Please note that this option does not necessarily enable the
+ workaround, as it depends on the alternative framework, which will
+ only patch the kernel if an affected CPU is detected.
+
+ If unsure, say Y.
+
+config ARM64_ERRATUM_819472
+   bool "Cortex-A53: 819472: Store exclusive instructions might cause data 
corruption"
+   default y
+   depends on ARM_64
+   help
+ This option adds an alternative code sequence to work around ARM
+ erratum 819472 on Cortex-A53 parts up to r0p1 with an L2 cac

[Xen-devel] [PATCH v5 6/7] xen/arm: arm64: Add cortex-A57 erratum 832075 workaround

[Julien Grall]

The ARM erratum 832075 applies to certain revisions of Cortex-A57, one
of the workarounds is to change device loads into using load-acquire
semantics.

Use the alternative framework to enable the workaround only on affected
cores.

Whilst a guest could trigger the deadlock, it can be broken when the
processor is receiving an interrupt. As the Xen scheduler will always setup
a timer (firing to every 1ms to 300ms depending on the running time
slice) on each processor, the deadlock would last only few milliseconds
and only affects the guest time slice.

Therefore a malicious guest could only hurt itself. Note that all the
guests should implement/enable the workaround for the affected cores.

Signed-off-by: Julien Grall 
Acked-by: Stefano Stabellini 

---
Changes in v4:
- Add Stefano's acked-by

Changes in v2:
- Update the commit message to explain why it is not necessary
to take care of possible deadlock from the guest.
---
 docs/misc/arm/silicon-errata.txt |  1 +
 xen/arch/arm/Kconfig | 20 
 xen/arch/arm/cpuerrata.c |  9 +
 xen/include/asm-arm/arm64/io.h   | 21 +
 xen/include/asm-arm/cpufeature.h |  3 ++-
 xen/include/asm-arm/processor.h  |  2 ++
 6 files changed, 51 insertions(+), 5 deletions(-)

diff --git a/docs/misc/arm/silicon-errata.txt b/docs/misc/arm/silicon-errata.txt
index 546ccd7..220f724 100644
--- a/docs/misc/arm/silicon-errata.txt
+++ b/docs/misc/arm/silicon-errata.txt
@@ -46,3 +46,4 @@ stable hypervisors.
 | ARM| Cortex-A53  | #824069 | ARM64_ERRATUM_824069
|
 | ARM| Cortex-A53  | #819472 | ARM64_ERRATUM_819472
|
 | ARM| Cortex-A57  | #852523 | N/A 
|
+| ARM| Cortex-A57  | #832075 | ARM64_ERRATUM_832075
|
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index a473d9c..e26c4c8 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -122,6 +122,26 @@ config ARM64_ERRATUM_819472
  the kernel if an affected CPU is detected.
 
  If unsure, say Y.
+
+config ARM64_ERRATUM_832075
+   bool "Cortex-A57: 832075: possible deadlock on mixing exclusive memory 
accesses with device loads"
+   default y
+   depends on ARM_64
+   help
+ This option adds an alternative code sequence to work around ARM
+ erratum 832075 on Cortex-A57 parts up to r1p2.
+
+ Affected Cortex-A57 parts might deadlock when exclusive load/store
+ instructions to Write-Back memory are mixed with Device loads.
+
+ The workaround is to promote device loads to use Load-Acquire
+ semantics.
+ Please note that this does not necessarily enable the workaround,
+ as it depends on the alternative framework, which will only patch
+ the kernel if an affected CPU is detected.
+
+ If unsure, say Y.
+
 endmenu
 
 source "common/Kconfig"
diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index 121788d..3ac97b3 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -34,6 +34,15 @@ static const struct arm_cpu_capabilities arm_errata[] = {
 MIDR_RANGE(MIDR_CORTEX_A53, 0x00, 0x01),
 },
 #endif
+#ifdef CONFIG_ARM64_ERRATUM_832075
+{
+/* Cortex-A57 r0p0 - r1p2 */
+.desc = "ARM erratum 832075",
+.capability = ARM64_WORKAROUND_DEVICE_LOAD_ACQUIRE,
+MIDR_RANGE(MIDR_CORTEX_A57, 0x00,
+   (1 << MIDR_VARIANT_SHIFT) | 2),
+},
+#endif
 {},
 };
 
diff --git a/xen/include/asm-arm/arm64/io.h b/xen/include/asm-arm/arm64/io.h
index f80156f..30bfc78 100644
--- a/xen/include/asm-arm/arm64/io.h
+++ b/xen/include/asm-arm/arm64/io.h
@@ -22,6 +22,7 @@
 
 #include 
 #include 
+#include 
 
 /*
  * Generic IO read/write.  These perform native-endian accesses.
@@ -49,28 +50,40 @@ static inline void __raw_writeq(u64 val, volatile void 
__iomem *addr)
 static inline u8 __raw_readb(const volatile void __iomem *addr)
 {
 u8 val;
-asm volatile("ldrb %w0, [%1]" : "=r" (val) : "r" (addr));
+asm volatile(ALTERNATIVE("ldrb %w0, [%1]",
+ "ldarb %w0, [%1]",
+ ARM64_WORKAROUND_DEVICE_LOAD_ACQUIRE)
+ : "=r" (val) : "r" (addr));
 return val;
 }
 
 static inline u16 __raw_readw(const volatile void __iomem *addr)
 {
 u16 val;
-asm volatile("ldrh %w0, [%1]" : "=r" (val) : "r" (addr));
+asm volatile(ALTERNATIVE("ldrh %w0, [%1]",
+ "ldarh %w0, [%1]",
+ ARM64_WORKAROUND_DEVICE_LOAD_ACQUIRE)
+ : "=r" (val) : "r" (addr));
 return val;
 }
 
 static inline u32 __raw_readl(const volatile void __iomem *addr)
 {
 u32 val;
-asm volatile("ldr %w0, [%1]" : "=r" (val) : "r" (addr));
+asm volatile(ALTERNATIVE("

[Xen-devel] [PATCH v5 3/7] xen/arm: Detect silicon revision and set cap bits accordingly

[Julien Grall]

After each CPU has been started, we iterate through a list of CPU
errata to detect CPUs which need from hypervisor code patches.

For each bug there is a function which check if that a particular CPU is
affected. This needs to be done on every CPUs to cover heterogenous
system properly.

If a certain erratum has been detected, the capability bit will be set.
In the case the erratum requires code patching, this will be triggered
by the call to apply_alternatives.

The code is based on the file arch/arm64/kernel/cpu_errata.c in Linux
v4.6-rc3.

Signed-off-by: Julien Grall 
Acked-by: Stefano Stabellini 

---
Changes in v4:
- Add missing emacs magic blocks
- Add Stefano's acked-by

Changes in v3:
- Move update_cpu_capabilities in a separate patch
- Update the commit message to mention that workaround may
not require code patching.

Changes in v2:
- Use XENLOG_INFO for the loglevel of the message
---
 xen/arch/arm/Makefile|  1 +
 xen/arch/arm/cpuerrata.c | 34 ++
 xen/arch/arm/setup.c |  3 +++
 xen/arch/arm/smpboot.c   |  3 +++
 xen/include/asm-arm/cpuerrata.h  | 14 ++
 xen/include/asm-arm/cpufeature.h |  6 ++
 6 files changed, 61 insertions(+)
 create mode 100644 xen/arch/arm/cpuerrata.c
 create mode 100644 xen/include/asm-arm/cpuerrata.h

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 74bd7b8..23aaf52 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -7,6 +7,7 @@ subdir-$(CONFIG_ACPI) += acpi
 obj-$(CONFIG_ALTERNATIVE) += alternative.o
 obj-y += bootfdt.o
 obj-y += cpu.o
+obj-y += cpuerrata.o
 obj-y += cpufeature.o
 obj-y += decode.o
 obj-y += device.o
diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
new file mode 100644
index 000..03ae7b4
--- /dev/null
+++ b/xen/arch/arm/cpuerrata.c
@@ -0,0 +1,34 @@
+#include 
+#include 
+#include 
+
+#define MIDR_RANGE(model, min, max) \
+.matches = is_affected_midr_range,  \
+.midr_model = model,\
+.midr_range_min = min,  \
+.midr_range_max = max
+
+static bool_t __maybe_unused
+is_affected_midr_range(const struct arm_cpu_capabilities *entry)
+{
+return MIDR_IS_CPU_MODEL_RANGE(boot_cpu_data.midr.bits, entry->midr_model,
+   entry->midr_range_min,
+   entry->midr_range_max);
+}
+
+static const struct arm_cpu_capabilities arm_errata[] = {
+{},
+};
+
+void check_local_cpu_errata(void)
+{
+update_cpu_capabilities(arm_errata, "enabled workaround for");
+}
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 97b3214..38eb888 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -171,6 +172,8 @@ static void __init processor_id(void)
 }
 
 processor_setup();
+
+check_local_cpu_errata();
 }
 
 void dt_unreserved_regions(paddr_t s, paddr_t e,
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index 3a962f7..d56b91d 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -316,6 +317,8 @@ void start_secondary(unsigned long boot_phys_offset,
 local_irq_enable();
 local_abort_enable();
 
+check_local_cpu_errata();
+
 printk(XENLOG_DEBUG "CPU %u booted.\n", smp_processor_id());
 
 startup_cpu_idle_loop();
diff --git a/xen/include/asm-arm/cpuerrata.h b/xen/include/asm-arm/cpuerrata.h
new file mode 100644
index 000..fe93beb
--- /dev/null
+++ b/xen/include/asm-arm/cpuerrata.h
@@ -0,0 +1,14 @@
+#ifndef __ARM_CPUERRATA_H
+#define __ARM_CPUERRATA_H
+
+void check_local_cpu_errata(void);
+
+#endif /* __ARM_CPUERRATA_H */
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/cpufeature.h b/xen/include/asm-arm/cpufeature.h
index be2414c..fb57295 100644
--- a/xen/include/asm-arm/cpufeature.h
+++ b/xen/include/asm-arm/cpufeature.h
@@ -66,6 +66,12 @@ struct arm_cpu_capabilities {
 const char *desc;
 u16 capability;
 bool_t (*matches)(const struct arm_cpu_capabilities *);
+union {
+struct {/* To be used for eratum handling only */
+u32 midr_model;
+u32 midr_range_min, midr_range_max;
+};
+};
 };
 
 void update_cpu_capabilities(const struct arm_cpu_capabilities *caps,
-- 
1.9.1


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

[Xen-devel] [PATCH v5 0/7] xen/arm: Introduce alternative runtime patching for ARM64

[Julien Grall]

Hello,

Some of the processor errata will require to modify code sequence. As those
modifications may impact the performance, they should only be enabled on
affected cores. Furthermore, Xen may also want to take advantage of
new hardware features coming up with v8.1 and v8.2.

The first part of the series adds the alternative infrastructure, most of
the code is based on Linux v4.6-rc3. The rest of the series implements
errata for Cortex-A57 and Cortex-A53.

A branch with all the patches can be found here:

git://xenbits.xen.org/people/julieng/xen-unstable.git branch alternative-v5

For all the changes, see in each patch.

Yours sincerely,

Julien Grall (7):
  xen/arm: Introduce alternative runtime patching
  xen/arm: cpufeature: Provide an helper to check if a capability is
supported
  xen/arm: Detect silicon revision and set cap bits accordingly
  xen/arm: Document the errata implemented in Xen
  xen/arm: arm64: Add Cortex-A53 cache errata workaround
  xen/arm: arm64: Add cortex-A57 erratum 832075 workaround
  xen/arm: traps: Don't inject a fault if the translation VA -> IPA
fails

 docs/misc/arm/silicon-errata.txt  |  49 +
 xen/arch/arm/Kconfig  |  96 +
 xen/arch/arm/Makefile |   2 +
 xen/arch/arm/alternative.c| 221 ++
 xen/arch/arm/arm64/cache.S|   2 +
 xen/arch/arm/cpuerrata.c  |  60 +++
 xen/arch/arm/cpufeature.c |  16 +++
 xen/arch/arm/setup.c  |  10 ++
 xen/arch/arm/smpboot.c|   3 +
 xen/arch/arm/traps.c  |   5 +-
 xen/arch/arm/xen.lds.S|   9 ++
 xen/include/asm-arm/alternative.h | 165 
 xen/include/asm-arm/arm64/insn.h  |  16 +++
 xen/include/asm-arm/arm64/io.h|  21 +++-
 xen/include/asm-arm/arm64/page.h  |   7 +-
 xen/include/asm-arm/cpuerrata.h   |  14 +++
 xen/include/asm-arm/cpufeature.h  |  20 +++-
 xen/include/asm-arm/processor.h   |   8 ++
 18 files changed, 715 insertions(+), 9 deletions(-)
 create mode 100644 docs/misc/arm/silicon-errata.txt
 create mode 100644 xen/arch/arm/alternative.c
 create mode 100644 xen/arch/arm/cpuerrata.c
 create mode 100644 xen/include/asm-arm/alternative.h
 create mode 100644 xen/include/asm-arm/cpuerrata.h

-- 
1.9.1


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

[Xen-devel] [PATCH v5 7/7] xen/arm: traps: Don't inject a fault if the translation VA -> IPA fails

[Julien Grall]

Based on ARM ARM (D4.5.3 in ARM DDI 0486A and B3.12.7 in ARM DDI 0406C.c),
a Stage 1 translation error has priority over a Stage 2 translation error.

Therefore gva_to_ipa can only fail if another vCPU is playing with the
page table.

Rather than injecting a custom fault, replay the instruction and let the
processor injecting the correct fault.

This is fine as Xen is handling all the pending softirqs
(see leave_hypervisor_tail) before returning to the guest. One of them
is the scheduler which could rescheduled the vCPU.

Signed-off-by: Julien Grall 
Acked-by: Stefano Stabellini 

---
Changes in v4:
- s/reschuled/rescheduled/ in the commit message

Changes in v3:
- Add Stefano's acked-by

Changes in v2:
- Update commit message to explain why a guest cannot DoS the
hypervisor with it.
---
 xen/arch/arm/traps.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index a2eb1da..d7a3e62 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2412,7 +2412,7 @@ static void do_trap_instr_abort_guest(struct 
cpu_user_regs *regs,
 
 rc = gva_to_ipa(gva, &gpa, GV2M_READ);
 if ( rc == -EFAULT )
-goto bad_insn_abort;
+return; /* Try again */
 }
 
 rc = p2m_mem_access_check(gpa, gva, npfec);
@@ -2424,7 +2424,6 @@ static void do_trap_instr_abort_guest(struct 
cpu_user_regs *regs,
 break;
 }
 
-bad_insn_abort:
 inject_iabt_exception(regs, gva, hsr.len);
 }
 
@@ -2448,7 +2447,7 @@ static void do_trap_data_abort_guest(struct cpu_user_regs 
*regs,
 {
 rc = gva_to_ipa(info.gva, &info.gpa, GV2M_READ);
 if ( rc == -EFAULT )
-goto bad_data_abort;
+return; /* Try again */
 }
 
 switch ( dabt.dfsc & 0x3f )
-- 
1.9.1


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

[Xen-devel] [PATCH v5 1/7] xen/arm: Introduce alternative runtime patching

[Julien Grall]

Some of the processor erratum will require to modify code sequence.
As those modifications may impact the performance, they should only
be enabled on affected cores. Furthermore, Xen may also want to take
advantage of new hardware features coming up with v8.1 and v8.2.

This patch adds an infrastructure to patch Xen during boot time
depending on the "features" available on the platform.

This code is based on the file arch/arm64/kernel/alternative.c in
Linux 4.6-rc3. Any references to arm64 have been dropped to make the
code as generic as possible.

When Xen is creating the page tables, all the executable sections
(.text and .init.text) will be marked read-only and then enforced by
setting SCTLR.WNX.

Whilst it might be possible to mark those entries read-only after
Xen has been patched, we would need extra care to avoid possible
TLBs conflicts (see D4-1732 in ARM DDI 0487A.i) as all
physical CPUs will be running.

All the physical CPUs have to be brought up before patching Xen because
each cores may have different errata/features which require code
patching. The only way to find them is to probe system registers on
each CPU.

To avoid extra complexity, it is possible to create a temporary
writeable mapping with vmap. This mapping will be used to write the
new instructions.

Lastly, runtime patching is currently not necessary for ARM32. So the
code is only enabled for ARM64.

Signed-off-by: Julien Grall 

---
Changes in v5:
- Rebase on the latest staging

Changes in v4:
- Fix build when ALTERNATIVE is not enabled
- Fix typo
- Move .altinstructions in init.data

Changes in v3:
- .altinstr_replacement should live in init.text
- Add a comment to explain when apply_alternatives_all should be
called.

Changes in v2:
- Use hard tabs in Kconfig
- Update the copyright year
- Update the commit message to explain the extra mapping
---
 xen/arch/arm/Kconfig  |   5 +
 xen/arch/arm/Makefile |   1 +
 xen/arch/arm/alternative.c| 221 ++
 xen/arch/arm/setup.c  |   7 ++
 xen/arch/arm/xen.lds.S|   9 ++
 xen/include/asm-arm/alternative.h | 165 
 xen/include/asm-arm/arm64/insn.h  |  16 +++
 7 files changed, 424 insertions(+)
 create mode 100644 xen/arch/arm/alternative.c
 create mode 100644 xen/include/asm-arm/alternative.h

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 6231cd5..0141bd9 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -14,6 +14,7 @@ config ARM_64
def_bool y
depends on 64BIT
select HAS_GICV3
+   select ALTERNATIVE
 
 config ARM
def_bool y
@@ -46,6 +47,10 @@ config ACPI
 config HAS_GICV3
bool
 
+# Select ALTERNATIVE if the architecture supports runtime patching
+config ALTERNATIVE
+   bool
+
 endmenu
 
 source "common/Kconfig"
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index b264ed4..74bd7b8 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -4,6 +4,7 @@ subdir-y += platforms
 subdir-$(CONFIG_ARM_64) += efi
 subdir-$(CONFIG_ACPI) += acpi
 
+obj-$(CONFIG_ALTERNATIVE) += alternative.o
 obj-y += bootfdt.o
 obj-y += cpu.o
 obj-y += cpufeature.o
diff --git a/xen/arch/arm/alternative.c b/xen/arch/arm/alternative.c
new file mode 100644
index 000..d00f98e
--- /dev/null
+++ b/xen/arch/arm/alternative.c
@@ -0,0 +1,221 @@
+/*
+ * alternative runtime patching
+ * inspired by the x86 version
+ *
+ * Copyright (C) 2014-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 version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define __ALT_PTR(a,f)  (u32 *)((void *)&(a)->f + (a)->f)
+#define ALT_ORIG_PTR(a) __ALT_PTR(a, orig_offset)
+#define ALT_REPL_PTR(a) __ALT_PTR(a, alt_offset)
+
+extern const struct alt_instr __alt_instructions[], __alt_instructions_end[];
+
+struct alt_region {
+const struct alt_instr *begin;
+const struct alt_instr *end;
+};
+
+/*
+ * Check if the target PC is within an alternative block.
+ */
+static bool_t branch_insn_requires_update(const struct alt_instr *alt,
+  unsigned long pc)
+{
+unsigned long replptr;
+
+if ( is_active_kernel_text(pc) )
+ret

[Xen-devel] [PATCH v5 2/7] xen/arm: cpufeature: Provide an helper to check if a capability is supported

[Julien Grall]

The CPU capabilities will be set depending on the value found in the CPU
registers. This patch provides a generic to go through a set of capabilities
and find which one should be enabled.

The parameter "info" is used to display the kind of capability updated (e.g
workaround, feature...).

Signed-off-by: Julien Grall 
Acked-by: Stefano Stabellini 

---
Changes in v4:
- Add Stefano's acked-by

Changes in v3:
 - Patch added. The code was previously part of "Detect
 silicon...".
---
 xen/arch/arm/cpufeature.c| 16 
 xen/include/asm-arm/cpufeature.h |  9 +
 2 files changed, 25 insertions(+)

diff --git a/xen/arch/arm/cpufeature.c b/xen/arch/arm/cpufeature.c
index 7a1b56b..088625b 100644
--- a/xen/arch/arm/cpufeature.c
+++ b/xen/arch/arm/cpufeature.c
@@ -24,6 +24,22 @@
 
 DECLARE_BITMAP(cpu_hwcaps, ARM_NCAPS);
 
+void update_cpu_capabilities(const struct arm_cpu_capabilities *caps,
+ const char *info)
+{
+int i;
+
+for ( i = 0; caps[i].matches; i++ )
+{
+if ( !caps[i].matches(&caps[i]) )
+continue;
+
+if ( !cpus_have_cap(caps[i].capability) && caps[i].desc )
+printk(XENLOG_INFO "%s: %s\n", info, caps[i].desc);
+cpus_set_cap(caps[i].capability);
+}
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/asm-arm/cpufeature.h b/xen/include/asm-arm/cpufeature.h
index 2bebad1..be2414c 100644
--- a/xen/include/asm-arm/cpufeature.h
+++ b/xen/include/asm-arm/cpufeature.h
@@ -62,6 +62,15 @@ static inline void cpus_set_cap(unsigned int num)
 __set_bit(num, cpu_hwcaps);
 }
 
+struct arm_cpu_capabilities {
+const char *desc;
+u16 capability;
+bool_t (*matches)(const struct arm_cpu_capabilities *);
+};
+
+void update_cpu_capabilities(const struct arm_cpu_capabilities *caps,
+ const char *info);
+
 #endif /* __ASSEMBLY__ */
 
 #endif
-- 
1.9.1


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