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

[Oleksandr Andrushchenko]

From: Oleksandr Andrushchenko 

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

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

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

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

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

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

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

3. Amount of changes.
fbif only provides XENFB_TYPE_UPDATE and XENFB_TYPE_RESIZE
events, so it looks like it is easier to get fb support into displif
than vice versa. displif at the moment has 6 requests and 1 event,
multiple connector support, etc.

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

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

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

Signed-off-by: Oleksandr Grytsov 
Signed-off-by: Oleksandr Andrushchenko 
---
 xen/include/public/io/displif.h | 778 
 1 file changed, 778 insertions(+)
 create mode 100644 xen/include/public/io/displif.h

diff --git a/xen/include/public/io/displif.h b/xen/include/public/io/displif.h
new file mode 100644
index ..849f27fe5f1d
--- /dev/null
+++ b/xen/include/public/io/displif.h
@@ -0,0 +1,778 @@
+/**
+ * displif.h
+ *
+ * Unified display device I/O interface for Xen guest OSes.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Copyright (C) 2016-2017 EPAM Systems Inc.
+ *
+ * Authors: Oleksandr Andrushchenko 
+ *  Oleksandr Grytsov 
+ */
+
+#ifndef __XEN_PUBLIC_IO_DISPLIF_H__
+#define __XEN_PUBLIC_IO_DISPLIF_H__
+
+#include "ring.h"
+#include "../grant_table.h"
+
+/*
+ **
+ *  Main features provided by the protocol
+ 

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

[Oleksandr Andrushchenko]

From: Oleksandr Andrushchenko 

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

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

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

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

Thank you,
Oleksandr Andrushchenko
Oleksandr Grytsov

Oleksandr Andrushchenko (1):
  displif: add ABI for para-virtual display

 xen/include/public/io/displif.h | 778 
 1 file changed, 778 insertions(+)
 create mode 100644 xen/include/public/io/displif.h

-- 
2.7.4


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

[Xen-devel] [qemu-upstream-unstable test] 105675: regressions - FAIL

[osstest service owner]

flight 105675 qemu-upstream-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105675/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-credit2  18 leak-check/check fail REGR. vs. 104067
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 windows-install fail REGR. vs. 
104067

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

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

version targeted for testing:
 qemuu728e90b41d46c1c1c210ac496204efd51936db75
baseline version:
 qemuu5cd2e1739763915e6b4c247eef71f948dc808bd5

Last test of basis   104067  2017-01-06 23:12:11 Z   34 days
Testing same since   105675  2017-02-09 23:12:05 Z0 days1 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Li Qiang 
  Stefano Stabellini 

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-credit2  14 guest-saverestore fail REGR. vs. 59254
 test-amd64-i386-xl   15 guest-localmigratefail REGR. vs. 59254
 test-amd64-amd64-xl-xsm  16 guest-saverestore.2   fail REGR. vs. 59254
 test-amd64-amd64-xl  17 guest-localmigrate/x10fail REGR. vs. 59254
 test-amd64-amd64-xl-multivcpu 14 guest-saverestorefail REGR. vs. 59254
 test-armhf-armhf-libvirt  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-xsm   17 guest-localmigrate/x10fail REGR. vs. 59254
 test-armhf-armhf-xl   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-credit2   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-libvirt-xsm  6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-arndale   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail REGR. vs. 59254
 test-armhf-armhf-xl-xsm   6 xen-boot  fail REGR. vs. 59254

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

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

version targeted for testing:
 linux99378fd26803328cbab64ae60fa98e1394d07a6d
baseline version:
 linux45820c294fe1b1a9df495d57f40585ef2d069a39

Last test of basis59254  2015-07-09 04:20:48 Z  582 days
Failing since 59348  2015-07-10 04:24:05 Z  581 days  262 attempts
Testing same since   105672  2017-02-09 21:19:17 Z0 days1 attempts


7569 people touched revisions under test,
not listing them all

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail REGR. vs. 104585

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rumprun-i386 16 rumprun-demo-xenstorels/xenstorels.repeat fail 
in 105664 pass in 105673
 test-amd64-amd64-pair20 guest-start/debian fail pass in 105664

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

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

version targeted for testing:
 xen  576f319a804bce8c9a7fb70a042f873f5eaf0151
baseline version:
 xen  09f521a077024d5955d766eef7a040d2af928ec2

Last test of basis   104585  2017-01-22 08:19:51 Z   18 days
Testing same since   105664  2017-02-09 10:14:26 Z0 days2 attempts


People who touched revisions under test:
  George Dunlap 
  Jan Beulich 
  Joao Martins 

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl 15 guest-start/debian.repeat fail REGR. vs. 105629

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

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

version targeted for testing:
 xen  991033fad2cc23c45415fbcd0ab6405250e6b35c
baseline version:
 xen  63e1d01b8fd948b3e0fa3beea494e407668aa43b

Last test of basis   105629  2017-02-08 06:54:04 Z1 days
Failing since105640  2017-02-08 14:19:37 Z1 days4 attempts
Testing same since   105669  2017-02-09 14:49:05 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Baptiste Daroussin 
  Fatih Acar 

Re: [Xen-devel] [RFC XEN PATCH 15/16] tools/libxl: handle return code of libxl__qmp_initializations()

[Haozhong Zhang]

On 02/09/17 10:13 +, Wei Liu wrote:

On Thu, Feb 09, 2017 at 10:47:01AM +0800, Haozhong Zhang wrote:

On 02/08/17 10:31 +, Wei Liu wrote:
> On Wed, Feb 08, 2017 at 02:07:26PM +0800, Haozhong Zhang wrote:
> > On 01/27/17 17:11 -0500, Konrad Rzeszutek Wilk wrote:
> > > On Mon, Oct 10, 2016 at 08:32:34AM +0800, Haozhong Zhang wrote:
> > > > If any error code is returned when creating a domain, stop the domain
> > > > creation.
> > >
> > > This looks like it is a bug-fix that can be spun off from this
> > > patchset?
> > >
> >
> > Yes, if everyone considers it's really a bug and the fix does not
> > cause compatibility problem (e.g. xl w/o this patch does not abort the
> > domain creation if it fails to connect to QEMU VNC port).
> >
>
> I'm two minded here. If the failure to connect is caused by some
> temporary glitches in QEMU and we're sure it will eventually succeed,
> there is no need to abort domain creation. If failure to connect is due
> to permanent glitches, we should abort.
>

Sorry, I should say "*query* QEMU VNC port" instead of *connect*.

libxl__qmp_initializations() currently does following tasks.
1/ Create a QMP socket.

  I think all failures in 1/ should be considered as permanent. It
  does not only fail the following tasks, but also fails the device
  hotplug which needs to cooperate with QEMU.

2/ If 1/ succeeds, query qmp about parameters of serial port and fill
  them in xenstore.
3/ If 1/ and 2/ succeed, set and query qmp about parameters (password,
  address, port) of VNC and fill them in xenstore.

  If we assume Xen always send the correct QMP commands and
  parameters, the QMP failures in 2/ and 3/ will be caused by QMP
  socket errors (see qmp_next()), which are hard to tell whether they
  are permanent or temporal. However, if the missing of serial port
  or VNC is considered as not affecting the execution of guest
  domain, we may ignore failures here.

> OOI how did you discover this issue? That could be the key to understand
> the issue here.

The next patch adds code in libxl__qmp_initialization() to query qmp
about vNVDIMM parameters (e.g. the base gpfn which is calculated by
QEMU) and return error code if it fails. While I was developing that
patch, I found xl didn't stop even if bugs in my QEMU patches failed
the code in my Xen patch.



Right, this should definitely be fatal.


Maybe we could let libxl__qmp_initializations() report whether a
failure can be tolerant. For non-tolerant failures (e.g. those in 1/),
xl should stop. For tolerant failures (e.g. those in 2/ and 3/), xl
can continue, but it needs to warn those failures.



Yes, we can do that. It's an internal function, we can change things as
we see fit.

I would suggest you only make vNVDIMM failure fatal as a start.



I'll send a patch out of this series to implement above w/o NVDIMM
stuffs.

Thanks,
Haozhong

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-xsm5 xen-buildfail REGR. vs. 105279
 build-amd64   5 xen-buildfail REGR. vs. 105279
 build-amd64-xsm   5 xen-buildfail REGR. vs. 105279
 build-i3865 xen-buildfail REGR. vs. 105279
 build-armhf   5 xen-buildfail REGR. vs. 105279
 build-armhf-xsm   5 xen-buildfail REGR. vs. 105279

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd   1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-pvh-intel  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 

Re: [Xen-devel] [DOC v4] Xen transport for 9pfs

[Stefano Stabellini]

On Wed, 8 Feb 2017, Konrad Rzeszutek Wilk wrote:
> > ## Ring Setup
> > 
> > The shared page has the following layout:
> > 
> > typedef uint32_t XEN_9PFS_RING_IDX;
> > 
> > struct xen_9pfs_intf {
> > XEN_9PFS_RING_IDX in_cons, in_prod;
> > uint8_t pad[56];
> > XEN_9PFS_RING_IDX out_cons, out_prod;
> > 
> > uint32_t ring_order;
> > /* this is an array of (1 << ring_order) elements */
> > grant_ref_t ref[1];
> > };
> > 
> > /* not actually C compliant (ring_order changes from ring to ring) */
> > struct ring_data {
> > char in[((1 << ring_order) << PAGE_SHIFT) / 2];
> > char out[((1 << ring_order) << PAGE_SHIFT) / 2];
> > };
> > 
> 
> This is the same comment about the the PV Calls structure.
> 
> Would it make sense to add the 'in_events' and 'out_events'
> as a notification mechanism?

As I wrote in the case of PV Calls, given that it's just an optimization
and increases complexity, what if we add some padding right after

  XEN_9PFS_RING_IDX out_cons, out_prod;

so that if we want to add it in the future, we can just place there,
instead of the first 4 bytes of the padding array?

struct xen_9pfs_intf {
XEN_9PFS_RING_IDX in_cons, in_prod;
uint8_t pad[56];
XEN_9PFS_RING_IDX out_cons, out_prod;
uint8_t pad[56];

uint32_t ring_order;
/* this is an array of (1 << ring_order) elements */
grant_ref_t ref[1];
};


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

Re: [Xen-devel] [DOC v8] PV Calls protocol design

[Stefano Stabellini]

On Tue, 7 Feb 2017, Konrad Rzeszutek Wilk wrote:
> .snip..
> >  Frontend XenBus Nodes
> > 
> > version
> >  Values: 
> > 
> >  Protocol version, chosen among the ones supported by the backend
> >  (see **versions** under [Backend XenBus Nodes]). Currently the
> >  value must be "1".
> > 
> > port
> >  Values: 
> > 
> >  The identifier of the Xen event channel used to signal activity
> >  in the command ring.
> > 
> > ring-ref
> >  Values: 
> > 
> >  The Xen grant reference granting permission for the backend to map
> >  the sole page in a single page sized command ring.
> > 
> >  Backend XenBus Nodes
> > 
> > versions
> >  Values: 
> > 
> >  List of comma separated protocol versions supported by the backend.
> >  For example "1,2,3". Currently the value is just "1", as there is
> >  only one version.
> > 
> > max-page-order
> >  Values: 
> > 
> >  The maximum supported size of a memory allocation in units of
> >  log2n(machine pages), e.g. 0 == 1 page,  1 = 2 pages, 2 == 4 pages,
> >  etc.
> 
> .. for the **data rings** (not to be confused with the command ring).
> 
> > 
> > function-calls
> >  Values: 
> > 
> >  Value "0" means that no calls are supported.
> >  Value "1" means that socket, connect, release, bind, listen, accept
> >  and poll are supported.
> > 
> ..snip..
> > ### Commands Ring
> > 
> > The shared ring is used by the frontend to forward POSIX function calls
> > to the backend. We shall refer to this ring as **commands ring** to
> > distinguish it from other rings which can be created later in the
> > lifecycle of the protocol (see [Indexes Page and Data ring]). The grant
> > reference for shared page for this ring is shared on xenstore (see
> > [Frontend XenBus Nodes]). The ring format is defined using the familiar
> > `DEFINE_RING_TYPES` macro (`xen/include/public/io/ring.h`).  Frontend
> > requests are allocated on the ring using the `RING_GET_REQUEST` macro.
> > The list of commands below is in calling order.
> > 
> > The format is defined as follows:
> > 
> > #define PVCALLS_SOCKET 0
> > #define PVCALLS_CONNECT1
> > #define PVCALLS_RELEASE2
> > #define PVCALLS_BIND   3
> > #define PVCALLS_LISTEN 4
> > #define PVCALLS_ACCEPT 5
> > #define PVCALLS_POLL   6
> > 
> > struct xen_pvcalls_request {
> > uint32_t req_id; /* private to guest, echoed in response */
> > uint32_t cmd;/* command to execute */
> > union {
> > struct xen_pvcalls_socket {
> > uint64_t id;
> > uint32_t domain;
> > uint32_t type;
> > uint32_t protocol;
> > #ifdef CONFIG_X86_32
> > uint8_t pad[4];
> 
> Could that be shifted to the right?

Tabs vs Spaces, sigh. I fixed it.


> > #endif
> > } socket;
> > struct xen_pvcalls_connect {
> > uint64_t id;
> > uint8_t addr[28];
> > uint32_t len;
> > uint32_t flags;
> > grant_ref_t ref;
> > uint32_t evtchn;
> > #ifdef CONFIG_X86_32
> > uint8_t pad[4];
> > #endif
> > } connect;
> > struct xen_pvcalls_release {
> > uint64_t id;
> > uint8_t reuse;
> > #ifdef CONFIG_X86_32
> > uint8_t pad[7];
> 
> Could that be shifted to the right?

yep


> > #endif
> > } release;
> > struct xen_pvcalls_bind {
> > uint64_t id;
> > uint8_t addr[28];
> > uint32_t len;
> > } bind;
> > struct xen_pvcalls_listen {
> > uint64_t id;
> > uint32_t backlog;
> > #ifdef CONFIG_X86_32
> > uint8_t pad[4];
> 
> Could that be shifted to the right?

yep


> > #endif
> > } listen;
> > struct xen_pvcalls_accept {
> > uint64_t id;
> > uint64_t id_new;
> > grant_ref_t ref;
> > uint32_t evtchn;
> > } accept;
> > struct xen_pvcalls_poll {
> > uint64_t id;
> > } poll;
> > /* dummy member to force sizeof(struct 
> > xen_pvcalls_request) to match across archs */
> >

Re: [Xen-devel] [early RFC] ARM PCI Passthrough design document

[Stefano Stabellini]

On Fri, 3 Feb 2017, Edgar E. Iglesias wrote:
> On Thu, Feb 02, 2017 at 03:12:52PM -0800, Stefano Stabellini wrote:
> > On Thu, 2 Feb 2017, Edgar E. Iglesias wrote:
> > > On Wed, Feb 01, 2017 at 07:04:43PM +, Julien Grall wrote:
> > > > Hi Edgar,
> > > > 
> > > > On 31/01/2017 19:06, Edgar E. Iglesias wrote:
> > > > >On Tue, Jan 31, 2017 at 05:09:53PM +, Julien Grall wrote:
> > > > >>On 31/01/17 16:53, Edgar E. Iglesias wrote:
> > > > >>>On Wed, Jan 25, 2017 at 06:53:20PM +, Julien Grall wrote:
> > > > On 24/01/17 20:07, Stefano Stabellini wrote:
> > > > >On Tue, 24 Jan 2017, Julien Grall wrote:
> > > > For generic host bridge, the initialization is inexistent. However 
> > > > some host
> > > > bridge (e.g xgene, xilinx) may require some specific setup and also
> > > > configuring clocks. Given that Xen only requires to access the 
> > > > configuration
> > > > space, I was thinking to let DOM0 initialization the host bridge. 
> > > > This would
> > > > avoid to import a lot of code in Xen, however this means that we 
> > > > need to
> > > > know when the host bridge has been initialized before accessing the
> > > > configuration space.
> > > > >>>
> > > > >>>
> > > > >>>Yes, that's correct.
> > > > >>>There's a sequence on the ZynqMP that involves assiging Gigabit 
> > > > >>>Transceivers
> > > > >>>to PCI (GTs are shared among PCIe, USB, SATA and the Display Port),
> > > > >>>enabling clocks and configuring a few registers to enable ECAM and 
> > > > >>>MSI.
> > > > >>>
> > > > >>>I'm not sure if this could be done prior to starting Xen. Perhaps.
> > > > >>>If so, bootloaders would have to know a head of time what devices
> > > > >>>the GTs are supposed to be configured for.
> > > > >>
> > > > >>I've got further questions regarding the Gigabit Transceivers. You 
> > > > >>mention
> > > > >>they are shared, do you mean that multiple devices can use a GT at 
> > > > >>the same
> > > > >>time? Or the software is deciding at startup which device will use a 
> > > > >>given
> > > > >>GT? If so, how does the software make this decision?
> > > > >
> > > > >Software will decide at startup. AFAIK, the allocation is normally done
> > > > >once but I guess that in theory you could design boards that could 
> > > > >switch
> > > > >at runtime. I'm not sure we need to worry about that use-case though.
> > > > >
> > > > >The details can be found here:
> > > > >https://www.xilinx.com/support/documentation/user_guides/ug1085-zynq-ultrascale-trm.pdf
> > > > >
> > > > >I suggest looking at pages 672 and 733.
> > > > 
> > > > Thank you for the documentation. I am trying to understand if we could 
> > > > move
> > > > initialization in Xen as suggested by Stefano. I looked at the driver in
> > > > Linux and the code looks simple not many dependencies. However, I was 
> > > > not
> > > > able to find where the Gigabit Transceivers are configured. Do you have 
> > > > any
> > > > link to the code for that?
> > > 
> > > Hi Julien,
> > > 
> > > I suspect that this setup has previously been done by the initial 
> > > bootloader
> > > auto-generated from design configuration tools.
> > > 
> > > Now, this is moving into Linux.
> > > There's a specific driver that does that but AFAICS, it has not been 
> > > upstreamed yet.
> > > You can see it here:
> > > https://github.com/Xilinx/linux-xlnx/blob/master/drivers/phy/phy-zynqmp.c
> > > 
> > > DTS nodes that need a PHY can then just refer to it, here's an example 
> > > from SATA:
> > >  {
> > > phy-names = "sata-phy";
> > > phys = < PHY_TYPE_SATA 1 3 15000>;
> > > };
> > > 
> > > I'll see if I can find working examples for PCIe on the ZCU102. Then I'll 
> > > share
> > > DTS, Kernel etc.
> > > 
> > > If you are looking for a platform to get started, an option could be if I 
> > > get you a build of
> > > our QEMU that includes models for the PCIe controller, MSI and SMMU 
> > > connections.
> > > These models are friendly wrt. PHY configs and initialization sequences, 
> > > it will
> > > accept pretty much any sequence and still work. This would allow you to 
> > > focus on
> > > architectural issues rather than exact details of init sequences (which 
> > > we can
> > > deal with later).
> > > 
> > > 
> > > 
> > > > 
> > > > This would also mean that the MSI interrupt controller will be moved in 
> > > > Xen.
> > > > Which I think is a more sensible design (see more below).
> > > > 
> > > > >>
> > > > - For all other host bridges => I don't know if there are host 
> > > >  bridges
> > > > falling under this category. I also don't have any idea how to 
> > > > handle this.
> > > > 
> > > > >
> > > > >Otherwise, if Dom0 is the only one to drive the physical host 
> > > > >bridge,
> > > > >and Xen is the one to provide the emulated host bridge, how are 
> > > > >DomU PCI
> > > > >config reads and writes supposed to work in details?
> > > > 
> > > > 

[Xen-devel] Xen on ARM IRQ latency and scheduler overhead

[Stefano Stabellini]

Hi all,

I have run some IRQ latency measurements on Xen on ARM on a Xilinx
ZynqMP board (four Cortex A53 cores, GICv2).

Dom0 has 1 vcpu pinned to cpu0, DomU has 1 vcpu pinned to cpu2.
Dom0 is Ubuntu. DomU is an ad-hoc baremetal app to measure interrupt
latency: https://github.com/edgarigl/tbm

I modified the app to use the phys_timer instead of the virt_timer.  You
can build it with:

make CFG=configs/xen-guest-irq-latency.cfg 

I modified Xen to export the phys_timer to guests, see the very hacky
patch attached. This way, the phys_timer interrupt should behave like
any conventional device interrupts assigned to a guest.

These are the results, in nanosec:

AVG MIN MAX WARM MAX

NODEBUG no WFI  1890180031702070
NODEBUG WFI 4850481070304980
NODEBUG no WFI credit2  2217209034202650
NODEBUG WFI credit2 8080789010320   8300

DEBUG no WFI2252208033202650
DEBUG WFI   6500614085208130
DEBUG WFI, credit2  8050787010680   8450

DEBUG means Xen DEBUG build.
WARM MAX is the maximum latency, taking out the first few interrupts to
warm the caches.
WFI is the ARM and ARM64 sleeping instruction, trapped and emulated by
Xen by calling vcpu_block.

As you can see, depending on whether the guest issues a WFI or not while
waiting for interrupts, the results change significantly. Interestingly,
credit2 does worse than credit1 in this area.

Trying to figure out where those 3000-4000ns of difference between the
WFI and non-WFI cases come from, I wrote a patch to zero the latency
introduced by xen/arch/arm/domain.c:schedule_tail. That saves about
1000ns. There are no other arch specific context switch functions worth
optimizing.

We are down to 2000-3000ns. Then, I started investigating the scheduler.
I measured how long it takes to run "vcpu_unblock": 1050ns, which is
significant. I don't know what is causing the remaining 1000-2000ns, but
I bet on another scheduler function. Do you have any suggestions on
which one?


Assuming that the problem is indeed the scheduler, one workaround that
we could introduce today would be to avoid calling vcpu_unblock on guest
WFI and call vcpu_yield instead. This change makes things significantly
better:

 AVG MIN MAX WARM MAX
DEBUG WFI (yield, no block)  2900219051305130
DEBUG WFI (yield, no block) credit2  3514228061805430

Is that a reasonable change to make? Would it cause significantly more
power consumption in Xen (because xen/arch/arm/domain.c:idle_loop might
not be called anymore)?


If we wanted to zero the difference between the WFI and non-WFI cases,
would we need a new scheduler? A simple "noop scheduler" that statically
assigns vcpus to pcpus, one by one, until they run out, then return
error? Or do we need more extensive modifications to
xen/common/schedule.c? Any other ideas?


Thanks,

Stefanodiff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 7e43691..f5ff69b 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -663,6 +663,7 @@ void arch_domain_destroy(struct domain *d)
 /* IOMMU page table is shared with P2M, always call
  * iommu_domain_destroy() before p2m_teardown().
  */
+WRITE_SYSREG32(0, CNTP_CTL_EL0);
 iommu_domain_destroy(d);
 p2m_teardown(d);
 domain_vgic_free(d);
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index a5348f2..5c8b621 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -47,7 +47,7 @@ static DEFINE_PER_CPU(uint64_t, lr_mask);
 
 static void gic_update_one_lr(struct vcpu *v, int i);
 
-static const struct gic_hw_operations *gic_hw_ops;
+const struct gic_hw_operations *gic_hw_ops;
 
 void register_gic_ops(const struct gic_hw_operations *ops)
 {
diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index dd62ba6..9a4e50d 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -184,6 +184,7 @@ int request_irq(unsigned int irq, unsigned int irqflags,
 }
 
 /* Dispatch an interrupt */
+extern const struct gic_hw_operations *gic_hw_ops;
 void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, int is_fiq)
 {
 struct irq_desc *desc = irq_to_desc(irq);
@@ -202,6 +203,12 @@ void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, 
int is_fiq)
 irq_enter();
 
 spin_lock(>lock);
+
+if (irq == 30) {
+set_bit(_IRQ_GUEST, >status);
+desc->handler = gic_hw_ops->gic_guest_irq_type;
+}
+
 desc->handler->ack(desc);
 
 if ( !desc->action )
@@ -224,7 +231,23 @@ void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, 
int is_fiq)
  * The irq cannot be a PPI, we only support delivery of SPIs to
  * guests.
 */
-vgic_vcpu_inject_spi(info->d, info->virq);
+if (irq != 30)
+vgic_vcpu_inject_spi(info->d, info->virq);
+else {
+struct domain *d;
+  

Re: [Xen-devel] [PATCH v2 07/10] xen: credit2: always mark a tickled pCPU as... tickled!

[Dario Faggioli]

On Thu, 2017-02-09 at 14:59 +0100, Dario Faggioli wrote:
> In fact, whether or not a pCPU has been tickled, and is
> therefore about to re-schedule, is something we look at
> and base decisions on in various places.
> 
> So, let's make sure that we do that basing on accurate
> information.
> 
> While there, also tweak a little bit smt_idle_mask_clear()
> (used for implementing SMT support), so that it only alter
> the relevant cpumask when there is the actual need for this.
> (This is only for reduced overhead, behavior remains the
> same).
> 
So, while working on other things with this series applied, I noticed
some strange behavior, for which it turned out this patch is
responsible.

More specifically...

> diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
> index addee7b..bfb4891 100644
> @@ -1289,9 +1300,8 @@ runq_tickle(const struct scheduler *ops, struct
> csched2_vcpu *new, s_time_t now)
>  sizeof(d),
>  (unsigned char *));
>  }
> -__cpumask_set_cpu(ipid, >tickled);
> -smt_idle_mask_clear(ipid, >smt_idle);
> -cpu_raise_softirq(ipid, SCHEDULE_SOFTIRQ);
> +
> +tickle_cpu(cpu, rqd);
>  
... this, quite obviously, wants to be:

  tickle_cpu(ipid, rqd);

I'll fix this in v2.

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

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

Re: [Xen-devel] qemu-upstream triggering OOM killer

[Stefano Stabellini]

CC'ing Anthony

On Thu, 9 Feb 2017, Jan Beulich wrote:
> Stefano,
> 
> the recent qemuu update results in the produced binary triggering the
> OOM killer on the first system I tried the updated code on. Is there
> anything known in this area? Are there any hints as to finding out
> what is going wrong?

Hi Jan,

Do you mean QEMU upstream (from qemu.org) or qemu-xen/staging (that
hasn't changed much in the last couple of months)? Do you know if it's
something Xen specific?

In terms of new Xen specific changes in QEMU upstream,
3a6c9172ac5951e6dac2b3f6 has the potential for changing memory
allocations, but shouldn't cause an OOM. If it's easy to reproduce, I
would bisect it.

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

Re: [Xen-devel] kernel BUG at block/bio.c:1786 -- (xen_blkif_schedule on the stack)

[Håkon Alstadheim]

Den 2017-02-09 18:30, skrev Roger Pau Monné:

On Mon, Feb 06, 2017 at 12:31:20AM +0100, Håkon Alstadheim wrote:
I get the BUG below in dom0 when trying to start a windows 10 domu 
(hvm,
with some pv-drivers installed ) . Below is "xl info", then comes 
dmesg

output, and finally domu config attached at end.

This domain is started very rarely, so may have been broken for some
time. All my other domains ar linux. This message is just a data-point
for whoever is interested, with possibly more data if anybody wants to
ask me anything. NOT expecting quick resolution of this :-/ .

The domain boots part of the way, screen resolution gets changed and
then it keeps spinning for ~ 5 seconds before stopping.

[...]

[339809.663061] br0: port 12(vif7.0) entered blocking state
[339809.663063] br0: port 12(vif7.0) entered disabled state
[339809.663123] device vif7.0 entered promiscuous mode
[339809.664885] IPv6: ADDRCONF(NETDEV_UP): vif7.0: link is not ready
[339809.742522] br0: port 13(vif7.0-emu) entered blocking state
[339809.742523] br0: port 13(vif7.0-emu) entered disabled state
[339809.742573] device vif7.0-emu entered promiscuous mode
[339809.744386] br0: port 13(vif7.0-emu) entered blocking state
[339809.744388] br0: port 13(vif7.0-emu) entered forwarding state
[339864.059095] xen-blkback: backend/vbd/7/768: prepare for reconnect
[339864.138002] xen-blkback: backend/vbd/7/768: using 1 queues, 
protocol

1 (x86_64-abi)
[339864.241039] xen-blkback: backend/vbd/7/832: prepare for reconnect
[339864.337997] xen-blkback: backend/vbd/7/832: using 1 queues, 
protocol

1 (x86_64-abi)
[339875.245306] vif vif-7-0 vif7.0: Guest Rx ready
[339875.245345] IPv6: ADDRCONF(NETDEV_CHANGE): vif7.0: link becomes 
ready

[339875.245391] br0: port 12(vif7.0) entered blocking state
[339875.245395] br0: port 12(vif7.0) entered forwarding state
[339894.122151] [ cut here ]
[339894.122169] kernel BUG at block/bio.c:1786!
[339894.122173] invalid opcode:  [#1] SMP
[339894.122176] Modules linked in: xt_physdev iptable_filter ip_tables
x_tables nfsd auth_rpcgss oid_registry nfsv4 dns_resolver nfsv3 
nfs_acl

binfmt_misc intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp
crc32c_intel pcspkr serio_raw i2c_i801 i2c_smbus iTCO_wdt
iTCO_vendor_support amdgpu drm_kms_helper syscopyarea bcache 
input_leds
sysfillrect sysimgblt fb_sys_fops ttm drm uas shpchp ipmi_ssif 
rtc_cmos

acpi_power_meter wmi tun snd_hda_codec_realtek snd_hda_codec_generic
snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm snd_timer 
snd

usbip_host usbip_core pktcdvd tmem lpc_ich xen_wdt nct6775 hwmon_vid
dm_zero dm_thin_pool dm_persistent_data dm_bio_prison dm_service_time
dm_round_robin dm_queue_length dm_multipath dm_log_userspace cn
virtio_pci virtio_scsi virtio_blk virtio_console virtio_balloon
[339894.122233]  xts gf128mul aes_x86_64 cbc sha512_generic
sha256_generic sha1_generic libiscsi scsi_transport_iscsi virtio_net
virtio_ring virtio tg3 libphy e1000 fuse overlay nfs lockd grace 
sunrpc

jfs multipath linear raid10 raid1 raid0 dm_raid raid456
async_raid6_recov async_memcpy async_pq async_xor xor async_tx 
raid6_pq

dm_snapshot dm_bufio dm_crypt dm_mirror dm_region_hash dm_log dm_mod
hid_sunplus hid_sony hid_samsung hid_pl hid_petalynx hid_monterey
hid_microsoft hid_logitech ff_memless hid_gyration hid_ezkey 
hid_cypress

hid_chicony hid_cherry hid_a4tech sl811_hcd xhci_plat_hcd ohci_pci
ohci_hcd uhci_hcd aic94xx lpfc qla2xxx aacraid sx8 DAC960 hpsa cciss
3w_9xxx 3w_ mptsas mptfc scsi_transport_fc mptspi mptscsih mptbase
atp870u dc395x qla1280 imm parport dmx3191d sym53c8xx gdth initio 
BusLogic

[339894.122325]  arcmsr aic7xxx aic79xx sg pdc_adma sata_inic162x
sata_mv sata_qstor sata_vsc sata_uli sata_sis sata_sx4 sata_nv 
sata_via
sata_svw sata_sil24 sata_sil sata_promise pata_sis usbhid led_class 
igb

ptp dca i2c_algo_bit ehci_pci ehci_hcd xhci_pci megaraid_sas xhci_hcd
[339894.122350] CPU: 3 PID: 23514 Comm: 7.hda-0 Tainted: GW
 4.9.8-gentoo #1
[339894.122353] Hardware name: ASUSTeK COMPUTER INC. Z10PE-D8
WS/Z10PE-D8 WS, BIOS 3304 06/22/2016
[339894.122358] task: 880244b55b00 task.stack: c90042fcc000
[339894.122361] RIP: e030:[]  []
bio_split+0x9/0x89
[339894.122370] RSP: e02b:c90042fcfb18  EFLAGS: 00010246
[339894.122373] RAX: 00a8 RBX: 8802433ee900 RCX:
88023f537080
[339894.122377] RDX: 0240 RSI:  RDI:
8801fc8b7890
[339894.122380] RBP: c90042fcfba8 R08:  R09:
52da
[339894.122383] R10: 0002 R11: 0005803f R12:
8801fc8b7890
[339894.122387] R13: 00a8 R14: c90042fcfbb8 R15:

[339894.122394] FS:  () GS:8802498c()
knlGS:8802498c
[339894.122398] CS:  e033 DS:  ES:  CR0: 80050033
[339894.122401] CR2: 7f99b78e3349 CR3: 000216d43000 CR4:
00042660
[339894.122405] Stack:
[339894.122407]  

Re: [Xen-devel] [PATCH v3] xen-netfront: Improve error handling during initialization

[David Miller]

From: Ross Lagerwall 
Date: Wed, 8 Feb 2017 10:57:37 +

> This fixes a crash when running out of grant refs when creating many
> queues across many netdevs.
> 
> * If creating queues fails (i.e. there are no grant refs available),
> call xenbus_dev_fatal() to ensure that the xenbus device is set to the
> closed state.
> * If no queues are created, don't call xennet_disconnect_backend as
> netdev->real_num_tx_queues will not have been set correctly.
> * If setup_netfront() fails, ensure that all the queues created are
> cleaned up, not just those that have been set up.
> * If any queues were set up and an error occurs, call
> xennet_destroy_queues() to clean up the napi context.
> * If any fatal error occurs, unregister and destroy the netdev to avoid
> leaving around a half setup network device.
> 
> Signed-off-by: Ross Lagerwall 

Applied.

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

Re: [Xen-devel] [PATCH] xen-netfront: Rework the fix for Rx stall during OOM and network stress

[David Miller]

From: Vineeth Remanan Pillai 
Date: Tue, 7 Feb 2017 18:59:01 +

> The commit 90c311b0eeea ("xen-netfront: Fix Rx stall during network
> stress and OOM") caused the refill timer to be triggerred almost on
> all invocations of xennet_alloc_rx_buffers for certain workloads.
> This reworks the fix by reverting to the old behaviour and taking into
> consideration the skb allocation failure. Refill timer is now triggered
> on insufficient requests or skb allocation failure.
> 
> Signed-off-by: Vineeth Remanan Pillai 
> Fixes: 90c311b0eeea (xen-netfront: Fix Rx stall during network stress and OOM)
> Reported-by: Boris Ostrovsky 

Applied.

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-xsm5 xen-buildfail REGR. vs. 105279
 build-amd64   5 xen-buildfail REGR. vs. 105279
 build-amd64-xsm   5 xen-buildfail REGR. vs. 105279
 build-i3865 xen-buildfail REGR. vs. 105279
 build-armhf   5 xen-buildfail REGR. vs. 105279
 build-armhf-xsm   5 xen-buildfail REGR. vs. 105279

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd   1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-pvh-intel  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail REGR. vs. 104585

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

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

version targeted for testing:
 xen  576f319a804bce8c9a7fb70a042f873f5eaf0151
baseline version:
 xen  09f521a077024d5955d766eef7a040d2af928ec2

Last test of basis   104585  2017-01-22 08:19:51 Z   18 days
Testing same since   105664  2017-02-09 10:14:26 Z0 days1 attempts


People who touched revisions under test:
  George Dunlap 
  Jan Beulich 
  Joao Martins 

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

[Xen-devel] [linux-linus test] 105663: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-credit2  14 guest-saverestore fail REGR. vs. 59254
 test-amd64-amd64-xl-xsm  17 guest-localmigrate/x10fail REGR. vs. 59254
 test-amd64-i386-xl   17 guest-localmigrate/x10fail REGR. vs. 59254
 test-amd64-amd64-xl-multivcpu 14 guest-saverestorefail REGR. vs. 59254
 test-amd64-amd64-pair  21 guest-migrate/src_host/dst_host fail REGR. vs. 59254
 test-armhf-armhf-xl-credit2   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-libvirt  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-xsm   17 guest-localmigrate/x10fail REGR. vs. 59254
 test-armhf-armhf-xl   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-libvirt-xsm  6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-arndale   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail REGR. vs. 59254
 test-armhf-armhf-xl-xsm   6 xen-boot  fail REGR. vs. 59254

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-raw3 host-install(3)   broken baseline untested
 test-armhf-armhf-xl-rtds  6 xen-boot  fail REGR. vs. 59254
 test-amd64-amd64-xl-rtds  9 debian-installfail REGR. vs. 59254
 test-armhf-armhf-libvirt-raw  4 host-ping-check-native  fail baseline untested
 test-armhf-armhf-xl-vhd   6 xen-bootfail baseline untested
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail baseline 
untested
 test-amd64-amd64-libvirt 15 guest-saverestore.2  fail blocked in 59254
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 59254
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 59254
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 59254

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

version targeted for testing:
 linuxd966564fcdc19e13eb6ba1fbe6b8101070339c3d
baseline version:
 linux45820c294fe1b1a9df495d57f40585ef2d069a39

Last test of basis59254  2015-07-09 04:20:48 Z  581 days
Failing since 59348  2015-07-10 04:24:05 Z  580 days  261 attempts
Testing same since   105663  2017-02-09 10:04:29 Z0 days1 attempts


7569 people touched revisions under test,
not listing them all

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

Re: [Xen-devel] [RFC v2 3/6] xen/arm: Allow platform_hvc to handle guest SMC calls

[Tamas K Lengyel]

On Thu, Feb 9, 2017 at 1:01 PM, Edgar E. Iglesias
 wrote:
> On Thu, Feb 09, 2017 at 12:42:09PM -0700, Tamas K Lengyel wrote:
>> On Thu, Feb 9, 2017 at 11:39 AM, Julien Grall  wrote:
>> > Hi Tamas,
>> >
>> > On 02/09/2017 06:11 PM, Tamas K Lengyel wrote:
>> >>
>> >> On Wed, Feb 8, 2017 at 5:08 PM, Julien Grall  wrote:
>> >>>
>> >>> On 08/02/2017 23:28, Tamas K Lengyel wrote:
>> 
>>  On Wed, Feb 8, 2017 at 3:04 PM, Julien Grall 
>>  wrote:
>> >>>
>> >>> You haven't understood my point. Xen is currently emulating PSCI call for
>> >>> the guest to allow powering up and down the CPUs and other stuff. If you
>> >>> decide to trap all the SMCs, you would have to handle them.
>> >>
>> >>
>> >> Sure, it's more work on the monitor side, but other then that, what's
>> >> the problem?
>> >
>> >
>> > Because you will have to introduce hypercalls to get all the necessary
>> > information from Xen that will not be available from outside.
>>
>> > Given that SMC has been designed to target different services (PSCI, 
>> > Trusted
>> > OS...) it would be normal to have monitor app only monitoring a certain set
>> > of SMC call. You cannot deny a such use case as it would avoid an monitor
>> > app to handle every single call that would be consumed by XEN but not
>> > forwarded to the secure firmware.
>> >
>>
>> I have nothing against introducing a fine-tune option to the SMC
>> monitoring system so the monitor app can determine if it wants all
>> SMCs or only a subset. At the moment I don't know of any usecase that
>> would require this option. I certainly don't need it. If this option
>> gets implemented by someone, I would be happy to take it.
>
> Well, the reason it would be useful is the other way around.
> On for example ZynqMP, enabling the monitor is useless since it will
> turn off the ability to use the vital FW APIs needed for device
> passthrough.
>
> So the monitor only works for PV guests that call SMC APIs to some
> imaginary Firmware.
>
> While a monitor that didn't insist in consuming all SMC calls,
> could very well be useful for monitoring/tracing purposes or
> other stuff even with guests that actually use a "real" FW API.
>
> I don't think we need to implement support for the latter right away,
> we can incrementally add support for these things (I hope).
>

Certainly, as I said I have nothing against adding such a feature. All
I'm saying is that I don't know of any usecase that requires that
option at the moment, so I would be OK with just making the two
exclusive. If someone finds the time to implement such fine-tuning,
I'm all for it.

Tamas

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

Re: [Xen-devel] [RFC v2 3/6] xen/arm: Allow platform_hvc to handle guest SMC calls

[Edgar E. Iglesias]

On Thu, Feb 09, 2017 at 12:42:09PM -0700, Tamas K Lengyel wrote:
> On Thu, Feb 9, 2017 at 11:39 AM, Julien Grall  wrote:
> > Hi Tamas,
> >
> > On 02/09/2017 06:11 PM, Tamas K Lengyel wrote:
> >>
> >> On Wed, Feb 8, 2017 at 5:08 PM, Julien Grall  wrote:
> >>>
> >>> On 08/02/2017 23:28, Tamas K Lengyel wrote:
> 
>  On Wed, Feb 8, 2017 at 3:04 PM, Julien Grall 
>  wrote:
> >>>
> >>> You haven't understood my point. Xen is currently emulating PSCI call for
> >>> the guest to allow powering up and down the CPUs and other stuff. If you
> >>> decide to trap all the SMCs, you would have to handle them.
> >>
> >>
> >> Sure, it's more work on the monitor side, but other then that, what's
> >> the problem?
> >
> >
> > Because you will have to introduce hypercalls to get all the necessary
> > information from Xen that will not be available from outside.
>
> > Given that SMC has been designed to target different services (PSCI, Trusted
> > OS...) it would be normal to have monitor app only monitoring a certain set
> > of SMC call. You cannot deny a such use case as it would avoid an monitor
> > app to handle every single call that would be consumed by XEN but not
> > forwarded to the secure firmware.
> >
> 
> I have nothing against introducing a fine-tune option to the SMC
> monitoring system so the monitor app can determine if it wants all
> SMCs or only a subset. At the moment I don't know of any usecase that
> would require this option. I certainly don't need it. If this option
> gets implemented by someone, I would be happy to take it.

Well, the reason it would be useful is the other way around.
On for example ZynqMP, enabling the monitor is useless since it will
turn off the ability to use the vital FW APIs needed for device
passthrough.

So the monitor only works for PV guests that call SMC APIs to some
imaginary Firmware.

While a monitor that didn't insist in consuming all SMC calls,
could very well be useful for monitoring/tracing purposes or
other stuff even with guests that actually use a "real" FW API.

I don't think we need to implement support for the latter right away,
we can incrementally add support for these things (I hope).

Cheers,
Edgar





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

Re: [Xen-devel] [RFC v2 3/6] xen/arm: Allow platform_hvc to handle guest SMC calls

[Tamas K Lengyel]

On Thu, Feb 9, 2017 at 11:39 AM, Julien Grall  wrote:
> Hi Tamas,
>
> On 02/09/2017 06:11 PM, Tamas K Lengyel wrote:
>>
>> On Wed, Feb 8, 2017 at 5:08 PM, Julien Grall  wrote:
>>>
>>> On 08/02/2017 23:28, Tamas K Lengyel wrote:

 On Wed, Feb 8, 2017 at 3:04 PM, Julien Grall 
 wrote:
>>>
>>> You haven't understood my point. Xen is currently emulating PSCI call for
>>> the guest to allow powering up and down the CPUs and other stuff. If you
>>> decide to trap all the SMCs, you would have to handle them.
>>
>>
>> Sure, it's more work on the monitor side, but other then that, what's
>> the problem?
>
>
> Because you will have to introduce hypercalls to get all the necessary
> information from Xen that will not be available from outside.
>
> Given that SMC has been designed to target different services (PSCI, Trusted
> OS...) it would be normal to have monitor app only monitoring a certain set
> of SMC call. You cannot deny a such use case as it would avoid an monitor
> app to handle every single call that would be consumed by XEN but not
> forwarded to the secure firmware.
>

I have nothing against introducing a fine-tune option to the SMC
monitoring system so the monitor app can determine if it wants all
SMCs or only a subset. At the moment I don't know of any usecase that
would require this option. I certainly don't need it. If this option
gets implemented by someone, I would be happy to take it.

Tamas

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

Re: [Xen-devel] [RFC v2 3/6] xen/arm: Allow platform_hvc to handle guest SMC calls

[Tamas K Lengyel]

On Thu, Feb 9, 2017 at 11:43 AM, Stefano Stabellini
 wrote:
> On Thu, 9 Feb 2017, Tamas K Lengyel wrote:
>> On Thu, Feb 9, 2017 at 11:22 AM, Stefano Stabellini
>>  wrote:
>> > On Thu, 9 Feb 2017, Edgar E. Iglesias wrote:
>> >> On Thu, Feb 09, 2017 at 10:12:41AM +0100, Edgar E. Iglesias wrote:
>> >> > On Wed, Feb 08, 2017 at 05:20:44PM -0800, Stefano Stabellini wrote:
>> >> > > On Thu, 9 Feb 2017, Julien Grall wrote:
>> >> > > > On 08/02/2017 23:28, Tamas K Lengyel wrote:
>> >> > > > > On Wed, Feb 8, 2017 at 3:04 PM, Julien Grall 
>> >> > > > >  wrote:
>> >> > > > > > Hi Tamas,
>> >> > > > > >
>> >> > > > > > Can you please try to configure your e-mail client to use '>' 
>> >> > > > > > rather than
>> >> > > > > > '
>> >> > > > > > '? It makes quite hard to read the e-mail.
>> >> > > > >
>> >> > > > > Hm, not sure why it switched but should be fine now.
>> >> > > > >
>> >> > > > > > On 08/02/2017 20:15, Tamas K Lengyel wrote:
>> >> > > > > > >
>> >> > > > > > >
>> >> > > > > > >
>> >> > > > > > > On Wed, Feb 8, 2017 at 12:40 PM, Edgar E. Iglesias
>> >> > > > > > > > 
>> >> > > > > > > wrote:
>> >> > > > > > > On Wed, Feb 08, 2017 at 06:29:13PM +0100, Edgar E. 
>> >> > > > > > > Iglesias wrote:
>> >> > > > > >
>> >> > > > > >
>> >> > > > > > > If platform_hvc() consumes an SMC, it's considered part 
>> >> > > > > > > of the Xen
>> >> > > > > > > API.
>> >> > > > > > > Visible but not filterable by a monitor.
>> >> > > > > > >
>> >> > > > > > >
>> >> > > > > > > Platforms can then dictate which SMC calls are better 
>> >> > > > > > > handled within
>> >> > > > > > > Xen and
>> >> > > > > > > which ones can be exposed to dom0 user-space.
>> >> > > > > > >
>> >> > > > > > > In addition, there could be a hypercall to disable 
>> >> > > > > > > platform specific
>> >> > > > > > > handling
>> >> > > > > > > in Xen alltogether for a given guest. Then everything 
>> >> > > > > > > goes to dom0
>> >> > > > > > > user-space.
>> >> > > > > > >
>> >> > > > > > > It's a little messy...
>> >> > > > > > >
>> >> > > > > > >
>> >> > > > > > >
>> >> > > > > > > That is messy and I would not want any SMCs reaching the 
>> >> > > > > > > firmware when
>> >> > > > > > > the monitor application is in use. The monitor interface is 
>> >> > > > > > > disabled by
>> >> > > > > > > default and there aren't any known usecases where the SMC has 
>> >> > > > > > > to reach
>> >> > > > > > > both the firmware and the monitor application as well. So I 
>> >> > > > > > > think it is
>> >> > > > > > > safe to just make the two things mutually exclusive.
>> >> > > > > >
>> >> > > > > >
>> >> > > > > > If you look at the SMC Calling Convention [1] both HVC and SMC 
>> >> > > > > > are
>> >> > > > > > considered a conduit for service call to the secure firmware or
>> >> > > > > > hypervisor.
>> >> > > > > > It would be up to the hypervisor deciding what to do.
>> >> > > > > >
>> >> > > > > > Lets imagine the guest is deciding to use HVC to access the 
>> >> > > > > > secure
>> >> > > > > > firmware
>> >> > > > > > (AFAIU this patch series is adding that), are you going to 
>> >> > > > > > monitor all the
>> >> > > > > > HVCs (including hypercall)?
>> >> > > > >
>> >> > > > > There are some fundamental differences between HVC and SMC calls
>> >> > > > > though. An HVC can only land in the hypervisor, so as a 
>> >> > > > > hypercall, I
>> >> > > > > would expect it to be something I can deny via XSM. That is a
>> >> > > > > sufficient option for now to block the path to the firmware. If 
>> >> > > > > we end
>> >> > > > > up needing to support an application that uses that hypercall for
>> >> > > > > something critical, then yes, it would also need to be hooked 
>> >> > > > > into the
>> >> > > > > monitor system. At the moment this is not necessary.
>> >> > > >
>> >> > > > My point is not about what is necessary at the moment. But what is 
>> >> > > > right
>> >> > > > things to do. If you look at the spec, HVC are not only for 
>> >> > > > hypercall, but any
>> >> > > > other kind of services. Why would you deny something that is valid 
>> >> > > > from the
>> >> > > > specification (see 5.2.1)?
>> >> > > >
>> >> > > > "The SMC calling convention, however, does not specify which 
>> >> > > > instruction
>> >> > > > (either SMC or HVC) to use to invoke a
>> >> > > > particular service."
>> >> > >
>> >> > > To have a generic solution, we need a way to specify a set of HVC/SMC
>> >> > > calls that get monitored and a set that get handled in Xen (platform
>> >> > > specific or otherwise). I think it is OK not to do both, at least at 
>> >> > > the
>> >> > > beginning, but we might want to add that feature in the future.
>> >> > >
>> >> > > As much as I would like to see that, in respect to this series, I 
>> >> > > don't
>> >> > > think we should ask Edgar to introduce such a 

Re: [Xen-devel] [RFC v2 3/6] xen/arm: Allow platform_hvc to handle guest SMC calls

[Stefano Stabellini]

On Thu, 9 Feb 2017, Tamas K Lengyel wrote:
> On Thu, Feb 9, 2017 at 11:22 AM, Stefano Stabellini
>  wrote:
> > On Thu, 9 Feb 2017, Edgar E. Iglesias wrote:
> >> On Thu, Feb 09, 2017 at 10:12:41AM +0100, Edgar E. Iglesias wrote:
> >> > On Wed, Feb 08, 2017 at 05:20:44PM -0800, Stefano Stabellini wrote:
> >> > > On Thu, 9 Feb 2017, Julien Grall wrote:
> >> > > > On 08/02/2017 23:28, Tamas K Lengyel wrote:
> >> > > > > On Wed, Feb 8, 2017 at 3:04 PM, Julien Grall 
> >> > > > >  wrote:
> >> > > > > > Hi Tamas,
> >> > > > > >
> >> > > > > > Can you please try to configure your e-mail client to use '>' 
> >> > > > > > rather than
> >> > > > > > '
> >> > > > > > '? It makes quite hard to read the e-mail.
> >> > > > >
> >> > > > > Hm, not sure why it switched but should be fine now.
> >> > > > >
> >> > > > > > On 08/02/2017 20:15, Tamas K Lengyel wrote:
> >> > > > > > >
> >> > > > > > >
> >> > > > > > >
> >> > > > > > > On Wed, Feb 8, 2017 at 12:40 PM, Edgar E. Iglesias
> >> > > > > > > > 
> >> > > > > > > wrote:
> >> > > > > > > On Wed, Feb 08, 2017 at 06:29:13PM +0100, Edgar E. 
> >> > > > > > > Iglesias wrote:
> >> > > > > >
> >> > > > > >
> >> > > > > > > If platform_hvc() consumes an SMC, it's considered part of 
> >> > > > > > > the Xen
> >> > > > > > > API.
> >> > > > > > > Visible but not filterable by a monitor.
> >> > > > > > >
> >> > > > > > >
> >> > > > > > > Platforms can then dictate which SMC calls are better 
> >> > > > > > > handled within
> >> > > > > > > Xen and
> >> > > > > > > which ones can be exposed to dom0 user-space.
> >> > > > > > >
> >> > > > > > > In addition, there could be a hypercall to disable 
> >> > > > > > > platform specific
> >> > > > > > > handling
> >> > > > > > > in Xen alltogether for a given guest. Then everything goes 
> >> > > > > > > to dom0
> >> > > > > > > user-space.
> >> > > > > > >
> >> > > > > > > It's a little messy...
> >> > > > > > >
> >> > > > > > >
> >> > > > > > >
> >> > > > > > > That is messy and I would not want any SMCs reaching the 
> >> > > > > > > firmware when
> >> > > > > > > the monitor application is in use. The monitor interface is 
> >> > > > > > > disabled by
> >> > > > > > > default and there aren't any known usecases where the SMC has 
> >> > > > > > > to reach
> >> > > > > > > both the firmware and the monitor application as well. So I 
> >> > > > > > > think it is
> >> > > > > > > safe to just make the two things mutually exclusive.
> >> > > > > >
> >> > > > > >
> >> > > > > > If you look at the SMC Calling Convention [1] both HVC and SMC 
> >> > > > > > are
> >> > > > > > considered a conduit for service call to the secure firmware or
> >> > > > > > hypervisor.
> >> > > > > > It would be up to the hypervisor deciding what to do.
> >> > > > > >
> >> > > > > > Lets imagine the guest is deciding to use HVC to access the 
> >> > > > > > secure
> >> > > > > > firmware
> >> > > > > > (AFAIU this patch series is adding that), are you going to 
> >> > > > > > monitor all the
> >> > > > > > HVCs (including hypercall)?
> >> > > > >
> >> > > > > There are some fundamental differences between HVC and SMC calls
> >> > > > > though. An HVC can only land in the hypervisor, so as a hypercall, 
> >> > > > > I
> >> > > > > would expect it to be something I can deny via XSM. That is a
> >> > > > > sufficient option for now to block the path to the firmware. If we 
> >> > > > > end
> >> > > > > up needing to support an application that uses that hypercall for
> >> > > > > something critical, then yes, it would also need to be hooked into 
> >> > > > > the
> >> > > > > monitor system. At the moment this is not necessary.
> >> > > >
> >> > > > My point is not about what is necessary at the moment. But what is 
> >> > > > right
> >> > > > things to do. If you look at the spec, HVC are not only for 
> >> > > > hypercall, but any
> >> > > > other kind of services. Why would you deny something that is valid 
> >> > > > from the
> >> > > > specification (see 5.2.1)?
> >> > > >
> >> > > > "The SMC calling convention, however, does not specify which 
> >> > > > instruction
> >> > > > (either SMC or HVC) to use to invoke a
> >> > > > particular service."
> >> > >
> >> > > To have a generic solution, we need a way to specify a set of HVC/SMC
> >> > > calls that get monitored and a set that get handled in Xen (platform
> >> > > specific or otherwise). I think it is OK not to do both, at least at 
> >> > > the
> >> > > beginning, but we might want to add that feature in the future.
> >> > >
> >> > > As much as I would like to see that, in respect to this series, I don't
> >> > > think we should ask Edgar to introduce such a mechanism. However, we do
> >> > > need to decide what Xen should do when platform_hvc is implemented and
> >> > > monitor is also enabled.
> >> > >
> >> > > I think the default should be to only call 

Re: [Xen-devel] [RFC v2 3/6] xen/arm: Allow platform_hvc to handle guest SMC calls

[Julien Grall]

Hi Tamas,

On 02/09/2017 06:11 PM, Tamas K Lengyel wrote:

On Wed, Feb 8, 2017 at 5:08 PM, Julien Grall  wrote:

On 08/02/2017 23:28, Tamas K Lengyel wrote:

On Wed, Feb 8, 2017 at 3:04 PM, Julien Grall  wrote:

You haven't understood my point. Xen is currently emulating PSCI call for
the guest to allow powering up and down the CPUs and other stuff. If you
decide to trap all the SMCs, you would have to handle them.


Sure, it's more work on the monitor side, but other then that, what's
the problem?


Because you will have to introduce hypercalls to get all the necessary 
information from Xen that will not be available from outside.


Given that SMC has been designed to target different services (PSCI, 
Trusted OS...) it would be normal to have monitor app only monitoring a 
certain set of SMC call. You cannot deny a such use case as it would 
avoid an monitor app to handle every single call that would be consumed 
by XEN but not forwarded to the secure firmware.






And yes it is emulation as you don't seem to be willing passing those SMC to
the firmware or even back to Xen. If we expect a VM to emulate a trusted
firmware, then you have a security problem. Some hardware may be only
accessible through the secure world and I doubt some trusted app vendor will
be willing to move cryptography stuff in non secure world. I would highly
recommend to skim through the OP-TEE thread, it will provide you some
insights of the constraints.


The firmware is not hardware, it's just a piece of code that has been
baked into the board in some manner. Emulation in my book is doing in
software what hardware is supposed to do. I don't expect all vendors
to be happy to move their proprietary whatever to a VM. Again, this is
an experimental setup with no real world applications at the moment.
As for certain hardware being only accessible from the TZ, in that
case the monitor application would have to call into the firmware. My
setup doesn't prohibit using the TZ, it just prohibits it being
accessible from untrusted guests directly.


To be honest, I am not here to criticize your project or else. I am just 
trying to explain you there are other potential use cases and we should 
not ignore them.


I am also not expecting none of the person involved in the thread to 
write the code now. However, it is always good to have a full view and 
get a direction how it should go.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [RFC v2 3/6] xen/arm: Allow platform_hvc to handle guest SMC calls

[Tamas K Lengyel]

On Thu, Feb 9, 2017 at 11:22 AM, Stefano Stabellini
 wrote:
> On Thu, 9 Feb 2017, Edgar E. Iglesias wrote:
>> On Thu, Feb 09, 2017 at 10:12:41AM +0100, Edgar E. Iglesias wrote:
>> > On Wed, Feb 08, 2017 at 05:20:44PM -0800, Stefano Stabellini wrote:
>> > > On Thu, 9 Feb 2017, Julien Grall wrote:
>> > > > On 08/02/2017 23:28, Tamas K Lengyel wrote:
>> > > > > On Wed, Feb 8, 2017 at 3:04 PM, Julien Grall  
>> > > > > wrote:
>> > > > > > Hi Tamas,
>> > > > > >
>> > > > > > Can you please try to configure your e-mail client to use '>' 
>> > > > > > rather than
>> > > > > > '
>> > > > > > '? It makes quite hard to read the e-mail.
>> > > > >
>> > > > > Hm, not sure why it switched but should be fine now.
>> > > > >
>> > > > > > On 08/02/2017 20:15, Tamas K Lengyel wrote:
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > On Wed, Feb 8, 2017 at 12:40 PM, Edgar E. Iglesias
>> > > > > > > > 
>> > > > > > > wrote:
>> > > > > > > On Wed, Feb 08, 2017 at 06:29:13PM +0100, Edgar E. Iglesias 
>> > > > > > > wrote:
>> > > > > >
>> > > > > >
>> > > > > > > If platform_hvc() consumes an SMC, it's considered part of 
>> > > > > > > the Xen
>> > > > > > > API.
>> > > > > > > Visible but not filterable by a monitor.
>> > > > > > >
>> > > > > > >
>> > > > > > > Platforms can then dictate which SMC calls are better 
>> > > > > > > handled within
>> > > > > > > Xen and
>> > > > > > > which ones can be exposed to dom0 user-space.
>> > > > > > >
>> > > > > > > In addition, there could be a hypercall to disable platform 
>> > > > > > > specific
>> > > > > > > handling
>> > > > > > > in Xen alltogether for a given guest. Then everything goes 
>> > > > > > > to dom0
>> > > > > > > user-space.
>> > > > > > >
>> > > > > > > It's a little messy...
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > That is messy and I would not want any SMCs reaching the 
>> > > > > > > firmware when
>> > > > > > > the monitor application is in use. The monitor interface is 
>> > > > > > > disabled by
>> > > > > > > default and there aren't any known usecases where the SMC has to 
>> > > > > > > reach
>> > > > > > > both the firmware and the monitor application as well. So I 
>> > > > > > > think it is
>> > > > > > > safe to just make the two things mutually exclusive.
>> > > > > >
>> > > > > >
>> > > > > > If you look at the SMC Calling Convention [1] both HVC and SMC are
>> > > > > > considered a conduit for service call to the secure firmware or
>> > > > > > hypervisor.
>> > > > > > It would be up to the hypervisor deciding what to do.
>> > > > > >
>> > > > > > Lets imagine the guest is deciding to use HVC to access the secure
>> > > > > > firmware
>> > > > > > (AFAIU this patch series is adding that), are you going to monitor 
>> > > > > > all the
>> > > > > > HVCs (including hypercall)?
>> > > > >
>> > > > > There are some fundamental differences between HVC and SMC calls
>> > > > > though. An HVC can only land in the hypervisor, so as a hypercall, I
>> > > > > would expect it to be something I can deny via XSM. That is a
>> > > > > sufficient option for now to block the path to the firmware. If we 
>> > > > > end
>> > > > > up needing to support an application that uses that hypercall for
>> > > > > something critical, then yes, it would also need to be hooked into 
>> > > > > the
>> > > > > monitor system. At the moment this is not necessary.
>> > > >
>> > > > My point is not about what is necessary at the moment. But what is 
>> > > > right
>> > > > things to do. If you look at the spec, HVC are not only for hypercall, 
>> > > > but any
>> > > > other kind of services. Why would you deny something that is valid 
>> > > > from the
>> > > > specification (see 5.2.1)?
>> > > >
>> > > > "The SMC calling convention, however, does not specify which 
>> > > > instruction
>> > > > (either SMC or HVC) to use to invoke a
>> > > > particular service."
>> > >
>> > > To have a generic solution, we need a way to specify a set of HVC/SMC
>> > > calls that get monitored and a set that get handled in Xen (platform
>> > > specific or otherwise). I think it is OK not to do both, at least at the
>> > > beginning, but we might want to add that feature in the future.
>> > >
>> > > As much as I would like to see that, in respect to this series, I don't
>> > > think we should ask Edgar to introduce such a mechanism. However, we do
>> > > need to decide what Xen should do when platform_hvc is implemented and
>> > > monitor is also enabled.
>> > >
>> > > I think the default should be to only call platform_hvc, because there
>> > > are many valid monitoring use-cases which don't require those few
>> > > platform specific SMC/HVC calls to be forwarded to the monitor.
>> > >
>> > > However, if we did that, we would break Tamas' scenario. Thus, I suggest
>> > > we also introduce a simple compile time option or 

Re: [Xen-devel] [RFC v2 3/6] xen/arm: Allow platform_hvc to handle guest SMC calls

[Stefano Stabellini]

On Thu, 9 Feb 2017, Edgar E. Iglesias wrote:
> On Thu, Feb 09, 2017 at 10:12:41AM +0100, Edgar E. Iglesias wrote:
> > On Wed, Feb 08, 2017 at 05:20:44PM -0800, Stefano Stabellini wrote:
> > > On Thu, 9 Feb 2017, Julien Grall wrote:
> > > > On 08/02/2017 23:28, Tamas K Lengyel wrote:
> > > > > On Wed, Feb 8, 2017 at 3:04 PM, Julien Grall  
> > > > > wrote:
> > > > > > Hi Tamas,
> > > > > > 
> > > > > > Can you please try to configure your e-mail client to use '>' 
> > > > > > rather than
> > > > > > '
> > > > > > '? It makes quite hard to read the e-mail.
> > > > > 
> > > > > Hm, not sure why it switched but should be fine now.
> > > > > 
> > > > > > On 08/02/2017 20:15, Tamas K Lengyel wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > On Wed, Feb 8, 2017 at 12:40 PM, Edgar E. Iglesias
> > > > > > > > 
> > > > > > > wrote:
> > > > > > > On Wed, Feb 08, 2017 at 06:29:13PM +0100, Edgar E. Iglesias 
> > > > > > > wrote:
> > > > > > 
> > > > > > 
> > > > > > > If platform_hvc() consumes an SMC, it's considered part of 
> > > > > > > the Xen
> > > > > > > API.
> > > > > > > Visible but not filterable by a monitor.
> > > > > > > 
> > > > > > > 
> > > > > > > Platforms can then dictate which SMC calls are better handled 
> > > > > > > within
> > > > > > > Xen and
> > > > > > > which ones can be exposed to dom0 user-space.
> > > > > > > 
> > > > > > > In addition, there could be a hypercall to disable platform 
> > > > > > > specific
> > > > > > > handling
> > > > > > > in Xen alltogether for a given guest. Then everything goes to 
> > > > > > > dom0
> > > > > > > user-space.
> > > > > > > 
> > > > > > > It's a little messy...
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > That is messy and I would not want any SMCs reaching the firmware 
> > > > > > > when
> > > > > > > the monitor application is in use. The monitor interface is 
> > > > > > > disabled by
> > > > > > > default and there aren't any known usecases where the SMC has to 
> > > > > > > reach
> > > > > > > both the firmware and the monitor application as well. So I think 
> > > > > > > it is
> > > > > > > safe to just make the two things mutually exclusive.
> > > > > > 
> > > > > > 
> > > > > > If you look at the SMC Calling Convention [1] both HVC and SMC are
> > > > > > considered a conduit for service call to the secure firmware or
> > > > > > hypervisor.
> > > > > > It would be up to the hypervisor deciding what to do.
> > > > > > 
> > > > > > Lets imagine the guest is deciding to use HVC to access the secure
> > > > > > firmware
> > > > > > (AFAIU this patch series is adding that), are you going to monitor 
> > > > > > all the
> > > > > > HVCs (including hypercall)?
> > > > > 
> > > > > There are some fundamental differences between HVC and SMC calls
> > > > > though. An HVC can only land in the hypervisor, so as a hypercall, I
> > > > > would expect it to be something I can deny via XSM. That is a
> > > > > sufficient option for now to block the path to the firmware. If we end
> > > > > up needing to support an application that uses that hypercall for
> > > > > something critical, then yes, it would also need to be hooked into the
> > > > > monitor system. At the moment this is not necessary.
> > > > 
> > > > My point is not about what is necessary at the moment. But what is right
> > > > things to do. If you look at the spec, HVC are not only for hypercall, 
> > > > but any
> > > > other kind of services. Why would you deny something that is valid from 
> > > > the
> > > > specification (see 5.2.1)?
> > > > 
> > > > "The SMC calling convention, however, does not specify which instruction
> > > > (either SMC or HVC) to use to invoke a
> > > > particular service."
> > > 
> > > To have a generic solution, we need a way to specify a set of HVC/SMC
> > > calls that get monitored and a set that get handled in Xen (platform
> > > specific or otherwise). I think it is OK not to do both, at least at the
> > > beginning, but we might want to add that feature in the future.
> > > 
> > > As much as I would like to see that, in respect to this series, I don't
> > > think we should ask Edgar to introduce such a mechanism. However, we do
> > > need to decide what Xen should do when platform_hvc is implemented and
> > > monitor is also enabled.
> > > 
> > > I think the default should be to only call platform_hvc, because there
> > > are many valid monitoring use-cases which don't require those few
> > > platform specific SMC/HVC calls to be forwarded to the monitor.
> > > 
> > > However, if we did that, we would break Tamas' scenario. Thus, I suggest
> > > we also introduce a simple compile time option or Xen command line
> > > option to forward all platform_hvc calls to the monitor instead of
> > > implementing them in Xen. Something like "MONITOR_OVERRIDE". In the
> > > future, we can replace it with a more 

Re: [Xen-devel] [RFC v2 3/6] xen/arm: Allow platform_hvc to handle guest SMC calls

[Tamas K Lengyel]

On Wed, Feb 8, 2017 at 5:08 PM, Julien Grall  wrote:
>
>
> On 08/02/2017 23:28, Tamas K Lengyel wrote:
>>
>> On Wed, Feb 8, 2017 at 3:04 PM, Julien Grall  wrote:
>>>
>>> Hi Tamas,
>>>
>>> Can you please try to configure your e-mail client to use '>' rather than
>>> '
>>> '? It makes quite hard to read the e-mail.
>>
>>
>> Hm, not sure why it switched but should be fine now.
>>
>>> On 08/02/2017 20:15, Tamas K Lengyel wrote:




 On Wed, Feb 8, 2017 at 12:40 PM, Edgar E. Iglesias
 > wrote:
 On Wed, Feb 08, 2017 at 06:29:13PM +0100, Edgar E. Iglesias wrote:
>>>
>>>
>>>
 If platform_hvc() consumes an SMC, it's considered part of the Xen
 API.
 Visible but not filterable by a monitor.


 Platforms can then dictate which SMC calls are better handled within
 Xen and
 which ones can be exposed to dom0 user-space.

 In addition, there could be a hypercall to disable platform specific
 handling
 in Xen alltogether for a given guest. Then everything goes to dom0
 user-space.

 It's a little messy...



 That is messy and I would not want any SMCs reaching the firmware when
 the monitor application is in use. The monitor interface is disabled by
 default and there aren't any known usecases where the SMC has to reach
 both the firmware and the monitor application as well. So I think it is
 safe to just make the two things mutually exclusive.
>>>
>>>
>>>
>>> If you look at the SMC Calling Convention [1] both HVC and SMC are
>>> considered a conduit for service call to the secure firmware or
>>> hypervisor.
>>> It would be up to the hypervisor deciding what to do.
>>>
>>> Lets imagine the guest is deciding to use HVC to access the secure
>>> firmware
>>> (AFAIU this patch series is adding that), are you going to monitor all
>>> the
>>> HVCs (including hypercall)?
>>
>>
>> There are some fundamental differences between HVC and SMC calls
>> though. An HVC can only land in the hypervisor, so as a hypercall, I
>> would expect it to be something I can deny via XSM. That is a
>> sufficient option for now to block the path to the firmware. If we end
>> up needing to support an application that uses that hypercall for
>> something critical, then yes, it would also need to be hooked into the
>> monitor system. At the moment this is not necessary.
>
>
> My point is not about what is necessary at the moment. But what is right
> things to do. If you look at the spec, HVC are not only for hypercall, but
> any other kind of services. Why would you deny something that is valid from
> the specification (see 5.2.1)?
>
> "The SMC calling convention, however, does not specify which instruction
> (either SMC or HVC) to use to invoke a
> particular service."
>
>>
>> So if we are landing in do_trap_smc from an HVC call, I think it would
>> be better to introduce a separate function for it rather then just
>> bunching the two together here.
>>
>>>
>>> Similarly, non-modified baremetal app could use SMC to power on/off the
>>> vCPU
>>> (see PSCI spec). Will you emulate that in the monitor app?
>>
>>
>> Yes, the underlying setup requires that everything that is expected
>> from the firmware to be performed either by the monitor app, or have
>> the monitor app further delegate it somewhere that can perform the
>> task. That can be either the firmware itself (if its safe), or an
>> isolated VM if it is possible to perform the task there. I wouldn't
>> call this emulation necessarily btw.
>
>
> You haven't understood my point. Xen is currently emulating PSCI call for
> the guest to allow powering up and down the CPUs and other stuff. If you
> decide to trap all the SMCs, you would have to handle them.

Sure, it's more work on the monitor side, but other then that, what's
the problem?

>
> And yes it is emulation as you don't seem to be willing passing those SMC to
> the firmware or even back to Xen. If we expect a VM to emulate a trusted
> firmware, then you have a security problem. Some hardware may be only
> accessible through the secure world and I doubt some trusted app vendor will
> be willing to move cryptography stuff in non secure world. I would highly
> recommend to skim through the OP-TEE thread, it will provide you some
> insights of the constraints.

The firmware is not hardware, it's just a piece of code that has been
baked into the board in some manner. Emulation in my book is doing in
software what hardware is supposed to do. I don't expect all vendors
to be happy to move their proprietary whatever to a VM. Again, this is
an experimental setup with no real world applications at the moment.
As for certain hardware being only accessible from the TZ, in that
case the monitor application would have to call into the firmware. My
setup doesn't prohibit using the TZ, it just 

Re: [Xen-devel] IOMMU fault with IGD passthrough setup on XEN 4.8.0

[Roger Pau Monné]

On Thu, Feb 09, 2017 at 07:58:56AM -0700, Jan Beulich wrote:
> >>> On 09.02.17 at 15:46,  wrote:
> > BTW -- I think that fix should not be conflicting with your debug change, 
> > right?
> 
> Yes - ideally you'd keep that one in place along with adding Roger's
> patch.

Please use the patch below, the previous one was missing a break, which made it
completely useless, sorry.

Roger.

---8<---
From 27d234b34b95f9b5900dd0760a0f16161459bcdd Mon Sep 17 00:00:00 2001
From: Roger Pau Monne 
Date: Thu, 9 Feb 2017 17:59:32 +
Subject: [PATCH] x86/iommu: add IOMMU entries for p2m_mmio_direct pages
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

There's nothing wrong with allowing the domain to perform DMA transfers to
MMIO areas that it already can access from the CPU, and this allows us to
remove the hack in set_identity_p2m_entry for PVH Dom0.

Signed-off-by: Roger Pau Monné 
---
 xen/arch/x86/mm/p2m-ept.c |  5 +++--
 xen/arch/x86/mm/p2m-pt.c  | 17 ++---
 xen/arch/x86/mm/p2m.c |  9 -
 xen/include/asm-x86/p2m.h |  7 ++-
 4 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index 04878f5..f47f323 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -672,7 +672,7 @@ ept_set_entry(struct p2m_domain *p2m, unsigned long gfn, 
mfn_t mfn,
 uint8_t ipat = 0;
 bool_t need_modify_vtd_table = 1;
 bool_t vtd_pte_present = 0;
-unsigned int iommu_flags = p2m_get_iommu_flags(p2mt);
+unsigned int iommu_flags = p2m_get_iommu_flags(p2mt, mfn);
 bool_t needs_sync = 1;
 ept_entry_t old_entry = { .epte = 0 };
 ept_entry_t new_entry = { .epte = 0 };
@@ -798,7 +798,8 @@ ept_set_entry(struct p2m_domain *p2m, unsigned long gfn, 
mfn_t mfn,
 
 /* Safe to read-then-write because we hold the p2m lock */
 if ( ept_entry->mfn == new_entry.mfn &&
- p2m_get_iommu_flags(ept_entry->sa_p2mt) == iommu_flags )
+ p2m_get_iommu_flags(ept_entry->sa_p2mt, _mfn(ept_entry->mfn)) ==
+ iommu_flags )
 need_modify_vtd_table = 0;
 
 ept_p2m_type_to_flags(p2m, _entry, p2mt, p2ma);
diff --git a/xen/arch/x86/mm/p2m-pt.c b/xen/arch/x86/mm/p2m-pt.c
index 3b025d5..a23d0bd 100644
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -499,7 +499,7 @@ p2m_pt_set_entry(struct p2m_domain *p2m, unsigned long gfn, 
mfn_t mfn,
 l2_pgentry_t l2e_content;
 l3_pgentry_t l3e_content;
 int rc;
-unsigned int iommu_pte_flags = p2m_get_iommu_flags(p2mt);
+unsigned int iommu_pte_flags = p2m_get_iommu_flags(p2mt, mfn);
 /*
  * old_mfn and iommu_old_flags control possible flush/update needs on the
  * IOMMU: We need to flush when MFN or flags (i.e. permissions) change.
@@ -565,9 +565,10 @@ p2m_pt_set_entry(struct p2m_domain *p2m, unsigned long 
gfn, mfn_t mfn,
 {
 if ( flags & _PAGE_PSE )
 {
-iommu_old_flags =
-p2m_get_iommu_flags(p2m_flags_to_type(flags));
 old_mfn = l1e_get_pfn(*p2m_entry);
+iommu_old_flags =
+p2m_get_iommu_flags(p2m_flags_to_type(flags),
+_mfn(old_mfn));
 }
 else
 {
@@ -609,9 +610,10 @@ p2m_pt_set_entry(struct p2m_domain *p2m, unsigned long 
gfn, mfn_t mfn,
 p2m_entry = p2m_find_entry(table, _remainder, gfn,
0, L1_PAGETABLE_ENTRIES);
 ASSERT(p2m_entry);
-iommu_old_flags =
-p2m_get_iommu_flags(p2m_flags_to_type(l1e_get_flags(*p2m_entry)));
 old_mfn = l1e_get_pfn(*p2m_entry);
+iommu_old_flags =
+p2m_get_iommu_flags(p2m_flags_to_type(l1e_get_flags(*p2m_entry)),
+_mfn(old_mfn));
 
 if ( mfn_valid(mfn) || p2m_allows_invalid_mfn(p2mt) )
 entry_content = p2m_l1e_from_pfn(mfn_x(mfn),
@@ -637,9 +639,10 @@ p2m_pt_set_entry(struct p2m_domain *p2m, unsigned long 
gfn, mfn_t mfn,
 {
 if ( flags & _PAGE_PSE )
 {
-iommu_old_flags =
-p2m_get_iommu_flags(p2m_flags_to_type(flags));
 old_mfn = l1e_get_pfn(*p2m_entry);
+iommu_old_flags =
+p2m_get_iommu_flags(p2m_flags_to_type(flags),
+_mfn(old_mfn));
 }
 else
 {
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 6548e9f..bd8ce35 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1053,16 +1053,7 @@ int set_identity_p2m_entry(struct domain *d, unsigned 
long gfn,
 ret = p2m_set_entry(p2m, gfn, _mfn(gfn), PAGE_ORDER_4K,
 p2m_mmio_direct, p2ma);
 else if ( 

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  ac6e7fd7a4826c14b85b9da59fc800a3a1bd3fd0
baseline version:
 xen  991033fad2cc23c45415fbcd0ab6405250e6b35c

Last test of basis   105666  2017-02-09 11:01:37 Z0 days
Testing same since   105670  2017-02-09 16:03:22 Z0 days1 attempts


People who touched revisions under test:
  Roger Pau Monne 
  Roger Pau Monné 

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



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=ac6e7fd7a4826c14b85b9da59fc800a3a1bd3fd0
+ . ./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 
ac6e7fd7a4826c14b85b9da59fc800a3a1bd3fd0
+ branch=xen-unstable-smoke
+ revision=ac6e7fd7a4826c14b85b9da59fc800a3a1bd3fd0
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.8-testing
+ '[' xac6e7fd7a4826c14b85b9da59fc800a3a1bd3fd0 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : 

Re: [Xen-devel] [PATCH] x86/iommu: add missing break

[Andrew Cooper]

On 09/02/17 17:55, Roger Pau Monne wrote:
> Ccing the maintainers...
>
> On Thu, Feb 09, 2017 at 05:53:28PM +, Roger Pau Monne wrote:
>> 50a498 failed to add a break in the p2m_mmio_direct case, so Xen was still 
>> not
>> adding IOMMU entries for p2m_mmio_direct regions.

Spotted by Coverity

>>
>> Reported-by: Andrew Cooper 
>> Signed-off-by: Roger Pau Monné 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH] x86/iommu: add missing break

[Roger Pau Monne]

Ccing the maintainers...

On Thu, Feb 09, 2017 at 05:53:28PM +, Roger Pau Monne wrote:
> 50a498 failed to add a break in the p2m_mmio_direct case, so Xen was still not
> adding IOMMU entries for p2m_mmio_direct regions.
> 
> Reported-by: Andrew Cooper 
> Signed-off-by: Roger Pau Monné 
> ---
> ---
>  xen/include/asm-x86/p2m.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
> index 173a6f8..c68ff58 100644
> --- a/xen/include/asm-x86/p2m.h
> +++ b/xen/include/asm-x86/p2m.h
> @@ -819,6 +819,7 @@ static inline unsigned int p2m_get_iommu_flags(p2m_type_t 
> p2mt, mfn_t mfn)
>  flags = IOMMUF_readable;
>  if ( !rangeset_contains_singleton(mmio_ro_ranges, mfn_x(mfn)) )
>  flags |= IOMMUF_writable;
> +break;
>  default:
>  flags = 0;
>  break;
> -- 
> 2.10.1 (Apple Git-78)
> 

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

[Xen-devel] [PATCH] x86/iommu: add missing break

[Roger Pau Monne]

50a498 failed to add a break in the p2m_mmio_direct case, so Xen was still not
adding IOMMU entries for p2m_mmio_direct regions.

Reported-by: Andrew Cooper 
Signed-off-by: Roger Pau Monné 
---
---
 xen/include/asm-x86/p2m.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
index 173a6f8..c68ff58 100644
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -819,6 +819,7 @@ static inline unsigned int p2m_get_iommu_flags(p2m_type_t 
p2mt, mfn_t mfn)
 flags = IOMMUF_readable;
 if ( !rangeset_contains_singleton(mmio_ro_ranges, mfn_x(mfn)) )
 flags |= IOMMUF_writable;
+break;
 default:
 flags = 0;
 break;
-- 
2.10.1 (Apple Git-78)


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

Re: [Xen-devel] [PATCH V3] common/vm_event: Prevent guest locking with large max_vcpus

[Tamas K Lengyel]

On Thu, Feb 9, 2017 at 10:11 AM, Razvan Cojocaru
 wrote:
> It is currently possible for the guest to lock when subscribing
> to synchronous vm_events if max_vcpus is larger than the
> number of available ring buffer slots. This patch no longer
> blocks already paused VCPUs, fixing the issue for this use
> case, and wakes up as many blocked VCPUs as there are slots
> available in the ring buffer, eliminating the blockage for
> asynchronous events.
>
> Signed-off-by: Razvan Cojocaru 

Acked-by: Tamas K Lengyel 

>
> ---
> Changes since V2:
>  - Fixed typo: re-enabled commented-out code (for testing).
> ---
>  xen/common/vm_event.c | 27 +++
>  1 file changed, 7 insertions(+), 20 deletions(-)
>
> diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
> index 82ce8f1..45046d1 100644
> --- a/xen/common/vm_event.c
> +++ b/xen/common/vm_event.c
> @@ -127,26 +127,11 @@ static unsigned int vm_event_ring_available(struct 
> vm_event_domain *ved)
>  static void vm_event_wake_blocked(struct domain *d, struct vm_event_domain 
> *ved)
>  {
>  struct vcpu *v;
> -int online = d->max_vcpus;
>  unsigned int avail_req = vm_event_ring_available(ved);
>
>  if ( avail_req == 0 || ved->blocked == 0 )
>  return;
>
> -/*
> - * We ensure that we only have vCPUs online if there are enough free 
> slots
> - * for their memory events to be processed.  This will ensure that no
> - * memory events are lost (due to the fact that certain types of events
> - * cannot be replayed, we need to ensure that there is space in the ring
> - * for when they are hit).
> - * See comment below in vm_event_put_request().
> - */
> -for_each_vcpu ( d, v )
> -if ( test_bit(ved->pause_flag, >pause_flags) )
> -online--;
> -
> -ASSERT(online == (d->max_vcpus - ved->blocked));
> -
>  /* We remember which vcpu last woke up to avoid scanning always linearly
>   * from zero and starving higher-numbered vcpus under high load */
>  if ( d->vcpu )
> @@ -160,13 +145,13 @@ static void vm_event_wake_blocked(struct domain *d, 
> struct vm_event_domain *ved)
>  if ( !v )
>  continue;
>
> -if ( !(ved->blocked) || online >= avail_req )
> +if ( !(ved->blocked) || avail_req == 0 )
> break;
>
>  if ( test_and_clear_bit(ved->pause_flag, >pause_flags) )
>  {
>  vcpu_unpause(v);
> -online++;
> +avail_req--;
>  ved->blocked--;
>  ved->last_vcpu_wake_up = k;
>  }
> @@ -280,8 +265,9 @@ void vm_event_put_request(struct domain *d,
>  int free_req;
>  unsigned int avail_req;
>  RING_IDX req_prod;
> +struct vcpu *curr = current;
>
> -if ( current->domain != d )
> +if ( curr->domain != d )
>  {
>  req->flags |= VM_EVENT_FLAG_FOREIGN;
>  #ifndef NDEBUG
> @@ -316,8 +302,9 @@ void vm_event_put_request(struct domain *d,
>   * See the comments above wake_blocked() for more information
>   * on how this mechanism works to avoid waiting. */
>  avail_req = vm_event_ring_available(ved);
> -if( current->domain == d && avail_req < d->max_vcpus )
> -vm_event_mark_and_pause(current, ved);
> +if( curr->domain == d && avail_req < d->max_vcpus &&
> +!atomic_read(>vm_event_pause_count) )
> +vm_event_mark_and_pause(curr, ved);
>
>  vm_event_ring_unlock(ved);
>
> --
> 1.9.1
>
>
> ___
> 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] kernel BUG at block/bio.c:1786 -- (xen_blkif_schedule on the stack)

[Roger Pau Monné]

On Mon, Feb 06, 2017 at 12:31:20AM +0100, Håkon Alstadheim wrote:
> I get the BUG below in dom0 when trying to start a windows 10 domu (hvm,
> with some pv-drivers installed ) . Below is "xl info", then comes dmesg
> output, and finally domu config attached at end.
> 
> This domain is started very rarely, so may have been broken for some
> time. All my other domains ar linux. This message is just a data-point
> for whoever is interested, with possibly more data if anybody wants to
> ask me anything. NOT expecting quick resolution of this :-/ .
> 
> The domain boots part of the way, screen resolution gets changed and
> then it keeps spinning for ~ 5 seconds before stopping.
[...]
> [339809.663061] br0: port 12(vif7.0) entered blocking state
> [339809.663063] br0: port 12(vif7.0) entered disabled state
> [339809.663123] device vif7.0 entered promiscuous mode
> [339809.664885] IPv6: ADDRCONF(NETDEV_UP): vif7.0: link is not ready
> [339809.742522] br0: port 13(vif7.0-emu) entered blocking state
> [339809.742523] br0: port 13(vif7.0-emu) entered disabled state
> [339809.742573] device vif7.0-emu entered promiscuous mode
> [339809.744386] br0: port 13(vif7.0-emu) entered blocking state
> [339809.744388] br0: port 13(vif7.0-emu) entered forwarding state
> [339864.059095] xen-blkback: backend/vbd/7/768: prepare for reconnect
> [339864.138002] xen-blkback: backend/vbd/7/768: using 1 queues, protocol
> 1 (x86_64-abi)
> [339864.241039] xen-blkback: backend/vbd/7/832: prepare for reconnect
> [339864.337997] xen-blkback: backend/vbd/7/832: using 1 queues, protocol
> 1 (x86_64-abi)
> [339875.245306] vif vif-7-0 vif7.0: Guest Rx ready
> [339875.245345] IPv6: ADDRCONF(NETDEV_CHANGE): vif7.0: link becomes ready
> [339875.245391] br0: port 12(vif7.0) entered blocking state
> [339875.245395] br0: port 12(vif7.0) entered forwarding state
> [339894.122151] [ cut here ]
> [339894.122169] kernel BUG at block/bio.c:1786!
> [339894.122173] invalid opcode:  [#1] SMP
> [339894.122176] Modules linked in: xt_physdev iptable_filter ip_tables
> x_tables nfsd auth_rpcgss oid_registry nfsv4 dns_resolver nfsv3 nfs_acl
> binfmt_misc intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp
> crc32c_intel pcspkr serio_raw i2c_i801 i2c_smbus iTCO_wdt
> iTCO_vendor_support amdgpu drm_kms_helper syscopyarea bcache input_leds
> sysfillrect sysimgblt fb_sys_fops ttm drm uas shpchp ipmi_ssif rtc_cmos
> acpi_power_meter wmi tun snd_hda_codec_realtek snd_hda_codec_generic
> snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm snd_timer snd
> usbip_host usbip_core pktcdvd tmem lpc_ich xen_wdt nct6775 hwmon_vid
> dm_zero dm_thin_pool dm_persistent_data dm_bio_prison dm_service_time
> dm_round_robin dm_queue_length dm_multipath dm_log_userspace cn
> virtio_pci virtio_scsi virtio_blk virtio_console virtio_balloon
> [339894.122233]  xts gf128mul aes_x86_64 cbc sha512_generic
> sha256_generic sha1_generic libiscsi scsi_transport_iscsi virtio_net
> virtio_ring virtio tg3 libphy e1000 fuse overlay nfs lockd grace sunrpc
> jfs multipath linear raid10 raid1 raid0 dm_raid raid456
> async_raid6_recov async_memcpy async_pq async_xor xor async_tx raid6_pq
> dm_snapshot dm_bufio dm_crypt dm_mirror dm_region_hash dm_log dm_mod
> hid_sunplus hid_sony hid_samsung hid_pl hid_petalynx hid_monterey
> hid_microsoft hid_logitech ff_memless hid_gyration hid_ezkey hid_cypress
> hid_chicony hid_cherry hid_a4tech sl811_hcd xhci_plat_hcd ohci_pci
> ohci_hcd uhci_hcd aic94xx lpfc qla2xxx aacraid sx8 DAC960 hpsa cciss
> 3w_9xxx 3w_ mptsas mptfc scsi_transport_fc mptspi mptscsih mptbase
> atp870u dc395x qla1280 imm parport dmx3191d sym53c8xx gdth initio BusLogic
> [339894.122325]  arcmsr aic7xxx aic79xx sg pdc_adma sata_inic162x
> sata_mv sata_qstor sata_vsc sata_uli sata_sis sata_sx4 sata_nv sata_via
> sata_svw sata_sil24 sata_sil sata_promise pata_sis usbhid led_class igb
> ptp dca i2c_algo_bit ehci_pci ehci_hcd xhci_pci megaraid_sas xhci_hcd
> [339894.122350] CPU: 3 PID: 23514 Comm: 7.hda-0 Tainted: GW
>  4.9.8-gentoo #1
> [339894.122353] Hardware name: ASUSTeK COMPUTER INC. Z10PE-D8
> WS/Z10PE-D8 WS, BIOS 3304 06/22/2016
> [339894.122358] task: 880244b55b00 task.stack: c90042fcc000
> [339894.122361] RIP: e030:[]  []
> bio_split+0x9/0x89
> [339894.122370] RSP: e02b:c90042fcfb18  EFLAGS: 00010246
> [339894.122373] RAX: 00a8 RBX: 8802433ee900 RCX:
> 88023f537080
> [339894.122377] RDX: 0240 RSI:  RDI:
> 8801fc8b7890
> [339894.122380] RBP: c90042fcfba8 R08:  R09:
> 52da
> [339894.122383] R10: 0002 R11: 0005803f R12:
> 8801fc8b7890
> [339894.122387] R13: 00a8 R14: c90042fcfbb8 R15:
> 
> [339894.122394] FS:  () GS:8802498c()
> knlGS:8802498c
> [339894.122398] CS:  e033 DS:  ES:  CR0: 80050033
> [339894.122401] CR2: 7f99b78e3349 

[Xen-devel] [PATCH V3] common/vm_event: Prevent guest locking with large max_vcpus

[Razvan Cojocaru]

It is currently possible for the guest to lock when subscribing
to synchronous vm_events if max_vcpus is larger than the
number of available ring buffer slots. This patch no longer
blocks already paused VCPUs, fixing the issue for this use
case, and wakes up as many blocked VCPUs as there are slots
available in the ring buffer, eliminating the blockage for
asynchronous events.

Signed-off-by: Razvan Cojocaru 

---
Changes since V2:
 - Fixed typo: re-enabled commented-out code (for testing).
---
 xen/common/vm_event.c | 27 +++
 1 file changed, 7 insertions(+), 20 deletions(-)

diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
index 82ce8f1..45046d1 100644
--- a/xen/common/vm_event.c
+++ b/xen/common/vm_event.c
@@ -127,26 +127,11 @@ static unsigned int vm_event_ring_available(struct 
vm_event_domain *ved)
 static void vm_event_wake_blocked(struct domain *d, struct vm_event_domain 
*ved)
 {
 struct vcpu *v;
-int online = d->max_vcpus;
 unsigned int avail_req = vm_event_ring_available(ved);
 
 if ( avail_req == 0 || ved->blocked == 0 )
 return;
 
-/*
- * We ensure that we only have vCPUs online if there are enough free slots
- * for their memory events to be processed.  This will ensure that no
- * memory events are lost (due to the fact that certain types of events
- * cannot be replayed, we need to ensure that there is space in the ring
- * for when they are hit).
- * See comment below in vm_event_put_request().
- */
-for_each_vcpu ( d, v )
-if ( test_bit(ved->pause_flag, >pause_flags) )
-online--;
-
-ASSERT(online == (d->max_vcpus - ved->blocked));
-
 /* We remember which vcpu last woke up to avoid scanning always linearly
  * from zero and starving higher-numbered vcpus under high load */
 if ( d->vcpu )
@@ -160,13 +145,13 @@ static void vm_event_wake_blocked(struct domain *d, 
struct vm_event_domain *ved)
 if ( !v )
 continue;
 
-if ( !(ved->blocked) || online >= avail_req )
+if ( !(ved->blocked) || avail_req == 0 )
break;
 
 if ( test_and_clear_bit(ved->pause_flag, >pause_flags) )
 {
 vcpu_unpause(v);
-online++;
+avail_req--;
 ved->blocked--;
 ved->last_vcpu_wake_up = k;
 }
@@ -280,8 +265,9 @@ void vm_event_put_request(struct domain *d,
 int free_req;
 unsigned int avail_req;
 RING_IDX req_prod;
+struct vcpu *curr = current;
 
-if ( current->domain != d )
+if ( curr->domain != d )
 {
 req->flags |= VM_EVENT_FLAG_FOREIGN;
 #ifndef NDEBUG
@@ -316,8 +302,9 @@ void vm_event_put_request(struct domain *d,
  * See the comments above wake_blocked() for more information
  * on how this mechanism works to avoid waiting. */
 avail_req = vm_event_ring_available(ved);
-if( current->domain == d && avail_req < d->max_vcpus )
-vm_event_mark_and_pause(current, ved);
+if( curr->domain == d && avail_req < d->max_vcpus &&
+!atomic_read(>vm_event_pause_count) )
+vm_event_mark_and_pause(curr, ved);
 
 vm_event_ring_unlock(ved);
 
-- 
1.9.1


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

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

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

Last test of basis   104751  2017-01-27 09:14:11 Z   13 days
Testing same since   105662  2017-02-09 09:43:18 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Dario Faggioli 
  George Dunlap 
  Jan Beulich 
  Joao Martins 

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

Re: [Xen-devel] [PATCH V2] common/vm_event: Prevent guest locking with large max_vcpus

[Razvan Cojocaru]

On 02/09/2017 06:39 PM, Tamas K Lengyel wrote:
>> @@ -316,8 +302,9 @@ void vm_event_put_request(struct domain *d,
>>   * See the comments above wake_blocked() for more information
>>   * on how this mechanism works to avoid waiting. */
>>  avail_req = vm_event_ring_available(ved);
>> -if( current->domain == d && avail_req < d->max_vcpus )
>> -vm_event_mark_and_pause(current, ved);
>> +if( curr->domain == d && avail_req < d->max_vcpus /* &&
>> +!atomic_read(>vm_event_pause_count) */ )
> 
> Seems like you left the atomic_read in a comment block here (I assume
> while testing if the waking code now works as expected).

Yes, sorry about that. I'll send V3 in a few minutes with that omission
fixed.


Thanks,
Razvan

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

Re: [Xen-devel] [PATCH] build/printf: fix incorrect format specifiers

[Roger Pau Monne]

On Thu, Feb 09, 2017 at 04:42:00PM +, Ian Jackson wrote:
> Roger Pau Monne writes ("[PATCH] build/printf: fix incorrect format 
> specifiers"):
> > The following incorrect format specifiers and incorrect number of parameters
> > passed to printf like functions are reported by clang:
> 
> Do we know why our GCC builds do not detect these bugs ?

In general clang has always been able to detect more of those than gcc, I still
remember my ~20 patch series to use clang, and more from others. But no, I
don't know the exact reason why gcc doesn't detect those.

I've forgot to commit the chunk below, which actually enables this.

---8<---
diff --git a/Config.mk b/Config.mk
index 3a1d960..4739f36 100644
--- a/Config.mk
+++ b/Config.mk
@@ -215,7 +215,7 @@ CFLAGS += -Wall -Wstrict-prototypes
 # Clang complains about macros that expand to 'if ( ( foo == bar ) ) ...'
 # and is over-zealous with the printf format lint
 # and is a bit too fierce about unused return values
-CFLAGS-$(clang) += -Wno-parentheses -Wno-format -Wno-unused-value
+CFLAGS-$(clang) += -Wno-parentheses -Wno-unused-value
 
 $(call cc-option-add,HOSTCFLAGS,HOSTCC,-Wdeclaration-after-statement)
 $(call cc-option-add,CFLAGS,CC,-Wdeclaration-after-statement)


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

Re: [Xen-devel] [RFC PATCH v1 00/21] ARM: Add Xen NUMA support

[Vijay Kilari]

Hi Julien,

On Thu, Feb 9, 2017 at 10:01 PM, Julien Grall  wrote:
> Hi Vijay,
>
> On 02/09/2017 03:56 PM, vijay.kil...@gmail.com wrote:
>>
>> Note: Please use this patch series only for review.
>> For testing, patch to boot allocator is required. Which will
>> be sent outside this series.
>
>
> Can you expand here? Is this patch a NUMA specific?

Yes it is NUMA specific, which I have reported here.
I have workaround for this. Need to prepare a patch. ( I hope till now
there is no
patch from anyone else for this issue)

https://www.mail-archive.com/xen-devel@lists.xen.org/msg92093.html

>
> Also in a previous thread you mentioned issue to boot Xen with NUMA on Xen
> unstable. So how did you test it?

This issue  (panic in page_alloc.c) that I reported is seen when I
boot plain unstable
xen on NUMA board without any NUMA or ITS patches. This issue
is seen only with on NUMA board with DT

I have tested this series with ACPI using unstable version and DT on
4.7 version.
Also, I have prepared a small patch as below (just adhoc way),
where in I called cpu_to_node() for all cpus and print phys_to_nid()
to see if the node id is correct or not.

-
diff --git a/xen/arch/arm/numa.c b/xen/arch/arm/numa.c
index d296523..d28e6bf 100644
--- a/xen/arch/arm/numa.c
+++ b/xen/arch/arm/numa.c
@@ -43,9 +43,11 @@ void __init numa_set_cpu_node(int cpu, unsigned long hwid)
 unsigned node;

 node = hwid >> 16 & 0xf;
+printk("In %s cpu %d node %d\n",__func__, cpu, node);
 if ( !node_isset(node, numa_nodes_parsed) || node == MAX_NUMNODES )
 node = 0;

+printk("In %s cpu %d node %d\n",__func__, cpu, node);
 numa_set_node(cpu, node);
 numa_add_cpu(cpu);
 }
@@ -245,3 +247,52 @@ int __init arch_numa_setup(char *opt)
 {
 return 1;
 }
+
+struct mem_list {
+u64 start;
+u64 end;
+};
+
+void numa_test(void)
+{
+int i;
+
+struct mem_list ml[] =
+{
+{ 0x0140, 0xfffecfff },
+{ 0x0001 , 0x000ff7ff },
+{ 0x000ff800 , 0x000ff801 },
+{ 0x000ff802 , 0x000fffa9cfff },
+{ 0x000fffa9d000 , 0x000f },
+{ 0x0140 , 0x010ff57b2fff },
+{ 0x010ff6618000 , 0x010ff6ff0fff },
+{ 0x010ff6ff1000 , 0x010ff724 },
+{ 0x010ff734b000 , 0x010ff73defff },
+{ 0x010ff73f , 0x010ff73fbfff },
+{ 0x010ff73fc000 , 0x010ff74defff },
+{ 0x010ff74df000 , 0x010ff9718fff },
+{ 0x010ff97a2000 , 0x010ff97acfff },
+{ 0x010ff97ad000 , 0x010ff97b3fff },
+{ 0x010ff97b5000 , 0x010ff9813fff },
+{ 0x010ff9814000 , 0x010ff9819fff },
+{ 0x010ff981a000 , 0x010ff984afff },
+{ 0x010ff984c000 , 0x010ff9851fff },
+{ 0x010ff9935000 , 0x010ffaeb5fff },
+{ 0x010ffaff5000 , 0x010ffb008fff },
+{ 0x010ffb009000 , 0x010fffe28fff },
+{ 0x010fffe29000 , 0x010fffe70fff },
+{ 0x010fffe71000 , 0x010b8fff },
+{ 0x010ff000 , 0x010f },
+};
+
+for ( i = 0; i < 23; i++ )
+{
+printk("NUMA MEM TEST: start 0x%lx in node %d end 0x%lx in node %d\n",
+   ml[i].start, phys_to_nid(ml[i].start), ml[i].end,
phys_to_nid(ml[i].end));
+}
+
+for ( i = 0; i < NR_CPUS; i++)
+{
+   printk("NUMA CPU TEST: cpu %d in node %d\n", i, cpu_to_node(i));
+}
+}
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 5612ba6..0598672 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -698,6 +698,7 @@ void __init setup_cache(void)
 cacheline_bytes = 1U << (4 + (ccsid & 0x7));
 }

+extern void numa_test(void);
 /* C entry point for boot CPU */
 void __init start_xen(unsigned long boot_phys_offset,
   unsigned long fdt_paddr,
@@ -825,6 +826,7 @@ void __init start_xen(unsigned long boot_phys_offset,
 }
 }

+numa_test();
 printk("Brought up %ld CPUs\n", (long)num_online_cpus());
 /* TODO: smp_cpus_done(); */


>
> Cheers,
>
> --
> Julien Grall

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

Re: [Xen-devel] [RFC v2 3/6] xen/arm: Allow platform_hvc to handle guest SMC calls

[Volodymyr Babchuk]

Julien,

You are absolutely right there. I want to add some more concerns about
current state of SMC handling in Xen. After that discussion about
OP-TEE I created small PoC that employs MiniOS to handle SMCs using
monitor mode. Also I did some benchmarking and found that SMC handling
in MiniOS is ten times slower, than handling in XEN. But, still, it is
pretty fast and I don't think this will be a problem. Anyways, I want
to try another approach and handle SMCs in EL0 XEN mode.
Real problem is that dom0 can't have monitor. This is pretty obvious
if you think about it. But this completely ruins OP-TEE use case. As
you remember, idea was to handle all SMCs in one place before they
would reach OP-TEE. Sadly, with current design, you can't handle SMCs
from dom0.

So, as you can see, there are many requirements for proper SMC
handling in hypervisor. Current state is unsatisfactory, there are
different approaches were proposed by me, by Edgar, but looks like
they can't satisfy us all.
Probably, we need completely different approach. Maybe, Xen EL0 apps
can be a good way to offload tasks such as SMC handling, device
emulation, hardware drivers (like cpu freq or thermal management),
etc. Or some framework, where you can register handlers for specific
op types,etc, etc.

Anyways, I feel that we need to gather all requirements to SMC
handling from all interested sides and then we need to develop some
approach, that will satisfy all of us.
I'm going to start new thread on this topic tomorrow, if you don't mind.

On 9 February 2017 at 02:08, Julien Grall  wrote:
>
>
> On 08/02/2017 23:28, Tamas K Lengyel wrote:
>>
>> On Wed, Feb 8, 2017 at 3:04 PM, Julien Grall  wrote:
>>>
>>> Hi Tamas,
>>>
>>> Can you please try to configure your e-mail client to use '>' rather than
>>> '
>>> '? It makes quite hard to read the e-mail.
>>
>>
>> Hm, not sure why it switched but should be fine now.
>>
>>> On 08/02/2017 20:15, Tamas K Lengyel wrote:




 On Wed, Feb 8, 2017 at 12:40 PM, Edgar E. Iglesias
 > wrote:
 On Wed, Feb 08, 2017 at 06:29:13PM +0100, Edgar E. Iglesias wrote:
>>>
>>>
>>>
 If platform_hvc() consumes an SMC, it's considered part of the Xen
 API.
 Visible but not filterable by a monitor.


 Platforms can then dictate which SMC calls are better handled within
 Xen and
 which ones can be exposed to dom0 user-space.

 In addition, there could be a hypercall to disable platform specific
 handling
 in Xen alltogether for a given guest. Then everything goes to dom0
 user-space.

 It's a little messy...



 That is messy and I would not want any SMCs reaching the firmware when
 the monitor application is in use. The monitor interface is disabled by
 default and there aren't any known usecases where the SMC has to reach
 both the firmware and the monitor application as well. So I think it is
 safe to just make the two things mutually exclusive.
>>>
>>>
>>>
>>> If you look at the SMC Calling Convention [1] both HVC and SMC are
>>> considered a conduit for service call to the secure firmware or
>>> hypervisor.
>>> It would be up to the hypervisor deciding what to do.
>>>
>>> Lets imagine the guest is deciding to use HVC to access the secure
>>> firmware
>>> (AFAIU this patch series is adding that), are you going to monitor all
>>> the
>>> HVCs (including hypercall)?
>>
>>
>> There are some fundamental differences between HVC and SMC calls
>> though. An HVC can only land in the hypervisor, so as a hypercall, I
>> would expect it to be something I can deny via XSM. That is a
>> sufficient option for now to block the path to the firmware. If we end
>> up needing to support an application that uses that hypercall for
>> something critical, then yes, it would also need to be hooked into the
>> monitor system. At the moment this is not necessary.
>
>
> My point is not about what is necessary at the moment. But what is right
> things to do. If you look at the spec, HVC are not only for hypercall, but
> any other kind of services. Why would you deny something that is valid from
> the specification (see 5.2.1)?
>
> "The SMC calling convention, however, does not specify which instruction
> (either SMC or HVC) to use to invoke a
> particular service."
>
>>
>> So if we are landing in do_trap_smc from an HVC call, I think it would
>> be better to introduce a separate function for it rather then just
>> bunching the two together here.
>>
>>>
>>> Similarly, non-modified baremetal app could use SMC to power on/off the
>>> vCPU
>>> (see PSCI spec). Will you emulate that in the monitor app?
>>
>>
>> Yes, the underlying setup requires that everything that is expected
>> from the firmware to be performed either by the monitor app, or have
>> the monitor app further delegate it 

Re: [Xen-devel] [PATCH 2/3] xen/privcmd: Add IOCTL_PRIVCMD_DM_OP

[Paul Durrant]

> -Original Message-
> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
> Sent: 09 February 2017 15:50
> To: Paul Durrant ; xen-de...@lists.xenproject.org;
> linux-ker...@vger.kernel.org
> Cc: Juergen Gross 
> Subject: Re: [PATCH 2/3] xen/privcmd: Add IOCTL_PRIVCMD_DM_OP
> 
> 
> 
> On 02/09/2017 09:27 AM, Paul Durrant wrote:
> >> -Original Message-
> >> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> >> Sent: 09 February 2017 14:18
> >> To: xen-de...@lists.xenproject.org; linux-ker...@vger.kernel.org
> >> Cc: Paul Durrant ; Boris Ostrovsky
> >> ; Juergen Gross 
> >> Subject: [PATCH 2/3] xen/privcmd: Add IOCTL_PRIVCMD_DM_OP
> >>
> >> Recently a new dm_op[1] hypercall was added to Xen to provide a
> >> mechanism
> >> for restricting device emulators (such as QEMU) to a limited set of
> >> hypervisor operations, and being able to audit those operations in the
> >> kernel of the domain in which they run.
> >>
> >> This patch adds IOCTL_PRIVCMD_DM_OP as gateway for
> >> __HYPERVISOR_dm_op,
> >> bouncing the callers buffers through kernel memory to allow the address
> >> ranges to be audited (and negating the need to bounce through locked
> >> memory in user-space).
> >
> > Actually, it strikes me (now that I've posted the patch) that I should
> probably just mlock the user buffers rather than bouncing them through
> kernel... Anyway, I'd still appreciate review on other aspects of the patch.
> 
> 
> Are you suggesting that the caller (user) mlocks the buffers?

No, I meant calling get_user_pages() (which AIUI is essentially what the 
internals of sys_mlock does) on the buffers to make sure they don't get paged 
during execution of the (unlocked) ioctl.

  Paul

> 
> -boris


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

[Xen-devel] [PATCH] build/printf: fix incorrect format specifiers

[Roger Pau Monne]

The following incorrect format specifiers and incorrect number of parameters
passed to printf like functions are reported by clang:

grant_table.c:3289:17: error: format specifies type 'unsigned short' but the 
argument has type
  'grant_handle_t' (aka 'unsigned int') [-Werror,-Wformat]
handle, ref, map->flags, map->domid);
^~

grant_table.c:3289:25: error: format specifies type 'unsigned short' but the 
argument has type
  'grant_ref_t' (aka 'unsigned int') [-Werror,-Wformat]
handle, ref, map->flags, map->domid);
^~~

mce.c:601:18: error: data argument not used by format string 
[-Werror,-Wformat-extra-args]
 smp_processor_id());
 ^

xenpm.c:102:23: error: data argument not used by format string 
[-Werror,-Wformat-extra-args]
what, argv[argc > 1]);
  ^

libxl_internal.c:25:69: error: data argument not used by format string
  [-Werror,-Wformat-extra-args]
libxl__log(ctx, XTL_CRITICAL, ENOMEM, 0,0, func, INVALID_DOMID, L);
^
libxl_internal.c:24:17: note: expanded from macro 'L'
  func, (unsigned long)nmemb, (unsigned long)size
^
libxl_internal.c:26:21: error: data argument not used by format string
  [-Werror,-Wformat-extra-args]
fprintf(stderr, L);
^
libxl_internal.c:24:17: note: expanded from macro 'L'
  func, (unsigned long)nmemb, (unsigned long)size
^

This patch contains the fixes for them.

Signed-off-by: Roger Pau Monné 
---
NB: FWIW, there's a way to disable extra arguments checks
(-Wno-format-extra-args), that would prevent us from having to apply some of
the changes here. However, given that there are not that many occurrences, I
would rather leave the full checks of Wformat enabled.

NB2: this has only been tested with a FreeBSD clang build (3.8.0), and only
against the components that build on FreeBSD (ie: no qemu-trad, and certainly
no blktap).
---
Cc: Ian Jackson 
Cc: Wei Liu 
Cc: Christoph Egger 
Cc: Liu Jinsong 
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 tools/libxl/libxl_internal.c  | 21 -
 tools/misc/xenpm.c| 13 -
 xen/arch/x86/cpu/mcheck/mce.c |  4 ++--
 xen/common/grant_table.c  |  2 +-
 4 files changed, 27 insertions(+), 13 deletions(-)

diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index d288215..f492dae 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -20,14 +20,25 @@
 void libxl__alloc_failed(libxl_ctx *ctx, const char *func,
  size_t nmemb, size_t size) {
 #define M "libxl: FATAL ERROR: memory allocation failure"
-#define L (size ? M " (%s, %lu x %lu)\n" : M " (%s)\n"), \
-  func, (unsigned long)nmemb, (unsigned long)size
-libxl__log(ctx, XTL_CRITICAL, ENOMEM, 0,0, func, INVALID_DOMID, L);
-fprintf(stderr, L);
+#define M_SIZE M " (%s, %lu x %lu)\n"
+#define M_NSIZE M " (%s)\n"
+if (size) {
+   libxl__log(ctx, XTL_CRITICAL, ENOMEM, 0, 0, func, INVALID_DOMID,
+  M_SIZE, func, (unsigned long)nmemb, (unsigned long)size);
+   fprintf(stderr, M_SIZE, func, (unsigned long)nmemb,
+   (unsigned long)size);
+} else {
+   libxl__log(ctx, XTL_CRITICAL, ENOMEM, 0, 0, func, INVALID_DOMID,
+  M_NSIZE, func);
+   fprintf(stderr, M_NSIZE, func);
+
+}
+
 fflush(stderr);
 _exit(-1);
+#undef M_NSIZE
+#undef M_SIZE
 #undef M
-#undef L
 }
 
 void libxl__ptr_add(libxl__gc *gc, void *ptr)
diff --git a/tools/misc/xenpm.c b/tools/misc/xenpm.c
index a2edee5..ded40b9 100644
--- a/tools/misc/xenpm.c
+++ b/tools/misc/xenpm.c
@@ -93,13 +93,16 @@ static void parse_cpuid(const char *arg, int *cpuid)
 static void parse_cpuid_and_int(int argc, char *argv[],
 int *cpuid, int *val, const char *what)
 {
-if ( argc > 1 )
-parse_cpuid(argv[0], cpuid);
+if ( argc == 0 )
+{
+ fprintf(stderr, "Missing %s\n", what);
+ exit(EINVAL);
+}
 
-if ( argc == 0 || sscanf(argv[argc > 1], "%d", val) != 1 )
+parse_cpuid(argv[0], cpuid);
+if ( sscanf(argv[1], "%d", val) != 1 )
 {
-fprintf(stderr, argc ? "Invalid %s '%s'\n" : "Missing %s\n",
-what, argv[argc > 1]);
+fprintf(stderr, "Invalid %s '%s'\n", what, argv[1]);
 exit(EINVAL);
 }
 }
diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index 2695b0c..5f40e71 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -596,8 +596,8 @@ int show_mca_info(int inited, struct cpuinfo_x86 *c)
 };
 
 snprintf(prefix, 

Re: [Xen-devel] [RFC PATCH v1 03/21] NUMA: Move arch specific NUMA code as common

[Jan Beulich]

>>> On 09.02.17 at 16:56,  wrote:
> --- a/xen/arch/x86/srat.c
> +++ b/xen/arch/x86/srat.c
> @@ -25,7 +25,7 @@ static struct acpi_table_slit *__read_mostly acpi_slit;
>  
>  static nodemask_t memory_nodes_parsed __initdata;
>  static nodemask_t processor_nodes_parsed __initdata;
> -static struct node nodes[MAX_NUMNODES] __initdata;
> +extern struct node nodes[MAX_NUMNODES] __initdata;

NAK to changes like this. Declarations belong in header files and
shouldn't have __init* annotations. But along the line of what I've
said for patch 2, it would be better if this wasn't made non-static.

> +__init int conflicting_memblks(u64 start, u64 end)

As you're moving code, again please sanitize stuff: Here, the __init
annotation is misplaced (it conventionally goes between type and
name). And of course the name is too generic to be kept as is.

Jan


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

Re: [Xen-devel] [RFC PATCH v1 02/21] x86: NUMA: Refactor NUMA code

[Jan Beulich]

>>> On 09.02.17 at 16:56,  wrote:
> From: Vijaya Kumar K 
> 
> Move common generic NUMA code to xen/common/numa.c from
> xen/arch/x86/numa.c. Also move generic code in header file
> xen/include/asm-x86/numa.h to xen/include/xen/numa.h
> 
> This common code can be re-used later for ARM.
> 
> Signed-off-by: Vijaya Kumar K 

I would have been nice if you Cc-ed the maintainers of the code
you're moving.

> --- /dev/null
> +++ b/xen/common/numa.c
> @@ -0,0 +1,342 @@
> +/*
> + * Common NUMA handling functions for x86 and arm.
> + * Original code extracted from arch/x86/numa.c
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; If not, see .
> + */
> +
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

This last one would better not be included here.

> +struct node_data node_data[MAX_NUMNODES];
> +
> +/* Mapping from pdx to node id */
> +int memnode_shift;
> +unsigned long memnodemapsize;
> +u8 *memnodemap;
> +typeof(*memnodemap) _memnodemap[64];

Careful with removing any "static" please. For the last one in
particular you would need to change the name if it's really necessary
to make non-static. Even better would be though to keep it static
and provide suitable accessors.

Also please sanitize types as you're moving stuff: memnode_shift
looks like it really wants to be unsigned int, and u8 should really
be uint8_t (as we're trying to phase out u8 & Co). This also applies
to code further down.

Jan


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

Re: [Xen-devel] [PATCH 2/3] xen/privcmd: Add IOCTL_PRIVCMD_DM_OP

[Andrew Cooper]

On 09/02/17 16:03, Jan Beulich wrote:
 On 09.02.17 at 16:56,  wrote:
>> On 09/02/17 15:50, Boris Ostrovsky wrote:
>>>
>>> On 02/09/2017 09:27 AM, Paul Durrant wrote:
> -Original Message-
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: 09 February 2017 14:18
> To: xen-de...@lists.xenproject.org; linux-ker...@vger.kernel.org 
> Cc: Paul Durrant ; Boris Ostrovsky
> ; Juergen Gross 
> Subject: [PATCH 2/3] xen/privcmd: Add IOCTL_PRIVCMD_DM_OP
>
> Recently a new dm_op[1] hypercall was added to Xen to provide a
> mechanism
> for restricting device emulators (such as QEMU) to a limited set of
> hypervisor operations, and being able to audit those operations in the
> kernel of the domain in which they run.
>
> This patch adds IOCTL_PRIVCMD_DM_OP as gateway for
> __HYPERVISOR_dm_op,
> bouncing the callers buffers through kernel memory to allow the address
> ranges to be audited (and negating the need to bounce through locked
> memory in user-space).
 Actually, it strikes me (now that I've posted the patch) that I
 should probably just mlock the user buffers rather than bouncing them
 through kernel... Anyway, I'd still appreciate review on other
 aspects of the patch.
>>>
>>> Are you suggesting that the caller (user) mlocks the buffers?
>> Doesn't libxc already use the hypercall buffer API for each of the buffers?
>>
>> The kernel oughtn’t to need to do anything special to the user pointers
>> it has, other than call access_ok() on them.
> And translate 32-bit layout to 64-bit for a compat caller.

Ah yes (although that looks to be done suitably in the patch as presented).

~Andrew

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

Re: [Xen-devel] [PATCH v2 02/12] libxl: make some functions global to prepare splitting up libxl.c

[Juergen Gross]

On 09/02/17 16:44, Wei Liu wrote:
> On Thu, Feb 09, 2017 at 12:42:41PM +0100, Juergen Gross wrote:
>> On 09/02/17 12:36, Ian Jackson wrote:
>>> Juergen Gross writes ("[PATCH v2 02/12] libxl: make some functions global 
>>> to prepare splitting up libxl.c"):
 Splitting up libxl.c will require two functions to be globally visible.
 Add their prototypes to libxl_internal.h.
>>>
>>> Thanks.  However,
>>>
 -static void xcinfo2xlinfo(libxl_ctx *ctx,
 -  const xc_domaininfo_t *xcinfo,
 -  libxl_dominfo *xlinfo)
 +void xcinfo2xlinfo(libxl_ctx *ctx,
 +   const xc_domaininfo_t *xcinfo,
 +   libxl_dominfo *xlinfo)
>>>
>>> This function needs a libxl__ prefix adding to its name.
>>
>> Aah, of course!
>>
>> Will send V3 after waiting for more comments for a while...
>>
> 
> If there are no more significant comments, you can just fold in
> everything and provide a branch. No need to repost.

Okay. Please pull from

https://github.com/jgross1/xen.git libxl-split-v3


Thanks,

Juergen


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

Re: [Xen-devel] [PATCH 2/3] xen/privcmd: Add IOCTL_PRIVCMD_DM_OP

[Jan Beulich]

>>> On 09.02.17 at 16:56,  wrote:
> On 09/02/17 15:50, Boris Ostrovsky wrote:
>>
>>
>> On 02/09/2017 09:27 AM, Paul Durrant wrote:
 -Original Message-
 From: Paul Durrant [mailto:paul.durr...@citrix.com]
 Sent: 09 February 2017 14:18
 To: xen-de...@lists.xenproject.org; linux-ker...@vger.kernel.org 
 Cc: Paul Durrant ; Boris Ostrovsky
 ; Juergen Gross 
 Subject: [PATCH 2/3] xen/privcmd: Add IOCTL_PRIVCMD_DM_OP

 Recently a new dm_op[1] hypercall was added to Xen to provide a
 mechanism
 for restricting device emulators (such as QEMU) to a limited set of
 hypervisor operations, and being able to audit those operations in the
 kernel of the domain in which they run.

 This patch adds IOCTL_PRIVCMD_DM_OP as gateway for
 __HYPERVISOR_dm_op,
 bouncing the callers buffers through kernel memory to allow the address
 ranges to be audited (and negating the need to bounce through locked
 memory in user-space).
>>>
>>> Actually, it strikes me (now that I've posted the patch) that I
>>> should probably just mlock the user buffers rather than bouncing them
>>> through kernel... Anyway, I'd still appreciate review on other
>>> aspects of the patch.
>>
>>
>> Are you suggesting that the caller (user) mlocks the buffers?
> 
> Doesn't libxc already use the hypercall buffer API for each of the buffers?
> 
> The kernel oughtn’t to need to do anything special to the user pointers
> it has, other than call access_ok() on them.

And translate 32-bit layout to 64-bit for a compat caller.

Jan

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

[Xen-devel] [RFC PATCH v1 20/21] ARM: NUMA: Enable CONFIG_NUMA config

[vijay . kilari]

From: Vijaya Kumar K 

Enable CONFIG_NUMA to enable DT NUMA

Signed-off-by: Vijaya Kumar 
---
 xen/arch/arm/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 2e023d1..fbc4f23 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -23,6 +23,7 @@ config ARM
select HAS_PASSTHROUGH
select HAS_PDX
select VIDEO
+   select NUMA
 
 config ARCH_DEFCONFIG
string
-- 
2.7.4


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

[Xen-devel] [RFC PATCH v1 19/21] ARM: NUMA: Initialize ACPI NUMA

[vijay . kilari]

From: Vijaya Kumar K 

Call ACPI NUMA initialization under CONFIG_ACPI_NUMA.

Signed-off-by: Vijaya Kumar 
---
 xen/arch/arm/numa.c | 12 +++-
 xen/common/numa.c   |  6 ++
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/numa.c b/xen/arch/arm/numa.c
index 50c3dea..1d6e16c 100644
--- a/xen/arch/arm/numa.c
+++ b/xen/arch/arm/numa.c
@@ -204,7 +204,17 @@ int __init numa_init(void)
 for ( i = 0; i < MAX_NUMNODES * 2; i++ )
 _node_distance[i] = 0;
 
-ret = dt_numa_init();
+#ifdef CONFIG_ACPI_NUMA
+if ( !acpi_disabled )
+{
+acpi_map_uid_to_mpidr();
+ret = acpi_numa_init();
+if ( ret || srat_disabled() )
+goto no_numa;
+}
+else
+#endif
+ret = dt_numa_init();
 
 if ( !ret )
 ret = numa_initmem_init();
diff --git a/xen/common/numa.c b/xen/common/numa.c
index 2f5266a..4c67d38 100644
--- a/xen/common/numa.c
+++ b/xen/common/numa.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 static int numa_setup(char *s);
@@ -282,6 +283,11 @@ static __init int numa_setup(char *opt)
 numa_off = 1;
 if ( !strncmp(opt,"on",2) )
 numa_off = 0;
+if ( !strncmp(opt,"noacpi",6) )
+{
+numa_off = 0;
+acpi_numa = -1;
+}
 
 return arch_numa_setup(opt);
 }
-- 
2.7.4


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

[Xen-devel] [RFC PATCH v1 21/21] ARM: NUMA: Enable CONFIG_ACPI_NUMA config

[vijay . kilari]

From: Vijaya Kumar K 

Enable CONFIG_ACPI_NUMA to enable ACPI NUMA

Signed-off-by: Vijaya Kumar 
---
 xen/arch/arm/Kconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index fbc4f23..4b74eef 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -43,6 +43,10 @@ config ACPI
  Advanced Configuration and Power Interface (ACPI) support for Xen is
  an alternative to device tree on ARM64.
 
+config ACPI_NUMA
+   def_bool y
+   depends on ACPI
+
 config HAS_GICV3
bool
 
-- 
2.7.4


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

[Xen-devel] [RFC PATCH v1 18/21] ARM: NUMA: update node_distance with ACPI support

[vijay . kilari]

From: Vijaya Kumar K 

Update node_distance() function to handle
ACPI SLIT table information.

Signed-off-by: Vijaya Kumar 
---
 xen/arch/arm/numa.c | 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/numa.c b/xen/arch/arm/numa.c
index 5c49347..50c3dea 100644
--- a/xen/arch/arm/numa.c
+++ b/xen/arch/arm/numa.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -35,6 +36,7 @@ extern struct node nodes[MAX_NUMNODES] __initdata;
 extern int num_node_memblks;
 extern struct node node_memblk_range[NR_NODE_MEMBLKS];
 extern nodeid_t memblk_nodeid[NR_NODE_MEMBLKS];
+extern struct acpi_table_slit *__read_mostly acpi_slit;
 
 void __init numa_set_cpu_node(int cpu, unsigned long hwid)
 {
@@ -50,9 +52,24 @@ void __init numa_set_cpu_node(int cpu, unsigned long hwid)
 
 u8 __node_distance(nodeid_t a, nodeid_t b)
 {
-if ( !node_distance )
+unsigned index;
+u8 slit_val;
+
+if ( !node_distance && !acpi_slit )
 return a == b ? 10 : 20;
 
+if ( acpi_slit )
+{
+index = acpi_slit->locality_count * node_to_pxm(a);
+slit_val = acpi_slit->entry[index + node_to_pxm(b)];
+
+/* ACPI defines 0xff as an unreachable node and 0-9 are undefined */
+if ( (slit_val == 0xff) || (slit_val <= 9) )
+return NUMA_NO_DISTANCE;
+else
+return slit_val;
+}
+
 return _node_distance[a * MAX_NUMNODES + b];
 }
 
@@ -140,6 +157,7 @@ static void __init numa_dummy_init(unsigned long start_pfn,
 nodes_clear(node_online_map);
 node_set_online(0);
 
+acpi_slit = NULL;
 for ( i = 0; i < NR_CPUS; i++ )
 numa_set_node(i, 0);
 
-- 
2.7.4


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

[Xen-devel] [RFC PATCH v1 17/21] ARM: NUMA: Extract memory proximity from SRAT table

[vijay . kilari]

From: Vijaya Kumar K 

Register SRAT entry handler for type
ACPI_SRAT_TYPE_MEMORY_AFFINITY to parse SRAT table
and extract proximity for all memory mappings.

Signed-off-by: Vijaya Kumar 
---
 xen/arch/arm/acpi_numa.c | 80 
 1 file changed, 80 insertions(+)

diff --git a/xen/arch/arm/acpi_numa.c b/xen/arch/arm/acpi_numa.c
index f659275..23cb07b 100644
--- a/xen/arch/arm/acpi_numa.c
+++ b/xen/arch/arm/acpi_numa.c
@@ -30,6 +30,9 @@
 #include 
 #include 
 
+extern int num_node_memblks;
+extern struct node node_memblk_range[NR_NODE_MEMBLKS];
+extern nodeid_t memblk_nodeid[NR_NODE_MEMBLKS];
 extern nodemask_t numa_nodes_parsed;
 struct uid_to_mpidr {
 u32 uid;
@@ -38,6 +41,7 @@ struct uid_to_mpidr {
 
 /* Holds mapping of CPU id to MPIDR read from MADT */
 static struct uid_to_mpidr cpu_uid_to_hwid[NR_CPUS] __read_mostly;
+static __initdata DECLARE_BITMAP(memblk_hotplug, NR_NODE_MEMBLKS);
 
 static __init void bad_srat(void)
 {
@@ -160,6 +164,82 @@ void __init acpi_numa_gicc_affinity_init(const struct 
acpi_srat_gicc_affinity *p
pxm, mpidr, node);
 }
 
+/* Callback for parsing of the Proximity Domain <-> Memory Area mappings */
+void __init
+acpi_numa_memory_affinity_init(const struct acpi_srat_mem_affinity *ma)
+{
+u64 start, end;
+unsigned pxm;
+nodeid_t node;
+int i;
+
+if ( srat_disabled() )
+return;
+
+if ( ma->header.length != sizeof(struct acpi_srat_mem_affinity) )
+{
+bad_srat();
+return;
+}
+if ( !(ma->flags & ACPI_SRAT_MEM_ENABLED) )
+return;
+
+if ( num_node_memblks >= NR_NODE_MEMBLKS )
+{
+printk(XENLOG_WARNING
+   "Too many numa entry, try bigger NR_NODE_MEMBLKS \n");
+bad_srat();
+return;
+}
+
+start = ma->base_address;
+end = start + ma->length;
+pxm = ma->proximity_domain;
+node = setup_node(pxm);
+if ( node == NUMA_NO_NODE )
+{
+bad_srat();
+return;
+}
+/* It is fine to add this area to the nodes data it will be used later*/
+i = conflicting_memblks(start, end);
+if ( i < 0 )
+/* everything fine */;
+else if ( memblk_nodeid[i] == node )
+{
+bool_t mismatch = !(ma->flags & ACPI_SRAT_MEM_HOT_PLUGGABLE) !=
+   !test_bit(i, memblk_hotplug);
+
+printk(XENLOG_WARNING
+   "%sSRAT: PXM %u (%"PRIx64"-%"PRIx64") overlaps with itself 
(%"PRIx64"-%"PRIx64")\n",
+   mismatch ? KERN_ERR : KERN_WARNING, pxm, start, end,
+   node_memblk_range[i].start, node_memblk_range[i].end);
+if ( mismatch )
+{
+bad_srat();
+return;
+}
+}
+else
+{
+ printk(XENLOG_WARNING
+"SRAT: PXM %u (%"PRIx64"-%"PRIx64") overlaps with PXM %u 
(%"PRIx64"-%"PRIx64")\n",
+pxm, start, end, node_to_pxm(memblk_nodeid[i]),
+node_memblk_range[i].start, node_memblk_range[i].end);
+bad_srat();
+return;
+}
+
+printk(XENLOG_INFO "SRAT: Node %u PXM %u %"PRIx64"-%"PRIx64"%s\n",
+   node, pxm, start, end,
+   ma->flags & ACPI_SRAT_MEM_HOT_PLUGGABLE ? " (hotplug)" : "");
+
+numa_add_memblk(node, start, ma->length);
+node_set(node, numa_nodes_parsed);
+if (ma->flags & ACPI_SRAT_MEM_HOT_PLUGGABLE)
+__set_bit(num_node_memblks, memblk_hotplug);
+}
+
 void __init acpi_map_uid_to_mpidr(void)
 {
 int i;
-- 
2.7.4


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

[Xen-devel] [RFC PATCH v1 14/21] ACPI: Move srat_disabled to common code

[vijay . kilari]

From: Vijaya Kumar K 

Move srat_disabled() from xen/arch/x86/numa.c to
xen/commom/srat.c.

Signed-off-by: Vijaya Kumar 
---
 xen/arch/x86/numa.c| 7 ---
 xen/common/srat.c  | 7 +++
 xen/include/asm-x86/acpi.h | 1 -
 xen/include/asm-x86/numa.h | 1 -
 xen/include/xen/srat.h | 2 ++
 5 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/xen/arch/x86/numa.c b/xen/arch/x86/numa.c
index 58de324..ec251bd 100644
--- a/xen/arch/x86/numa.c
+++ b/xen/arch/x86/numa.c
@@ -32,13 +32,6 @@ nodeid_t apicid_to_node[MAX_LOCAL_APIC] = {
 
 nodemask_t __read_mostly node_online_map = { { [0] = 1UL } };
 
-s8 acpi_numa = 0;
-
-int srat_disabled(void)
-{
-return numa_off || acpi_numa < 0;
-}
-
 void __init numa_init_array(void)
 {
 int rr, i;
diff --git a/xen/common/srat.c b/xen/common/srat.c
index cf50c78..a96406e 100644
--- a/xen/common/srat.c
+++ b/xen/common/srat.c
@@ -30,6 +30,13 @@ extern struct node nodes[MAX_NUMNODES] __initdata;
 struct pxm2node __read_mostly pxm2node[MAX_NUMNODES] =
 { [0 ... MAX_NUMNODES - 1] = {.node = NUMA_NO_NODE} };
 
+s8 acpi_numa = 0;
+
+int srat_disabled(void)
+{
+return numa_off || acpi_numa < 0;
+}
+
 static inline bool_t node_found(unsigned idx, unsigned pxm)
 {
 return ((pxm2node[idx].pxm == pxm) &&
diff --git a/xen/include/asm-x86/acpi.h b/xen/include/asm-x86/acpi.h
index f1a8e9d..934cd66 100644
--- a/xen/include/asm-x86/acpi.h
+++ b/xen/include/asm-x86/acpi.h
@@ -104,7 +104,6 @@ extern void acpi_reserve_bootmem(void);
 
 #define ARCH_HAS_POWER_INIT1
 
-extern s8 acpi_numa;
 extern int acpi_scan_nodes(u64 start, u64 end);
 
 #ifdef CONFIG_ACPI_SLEEP
diff --git a/xen/include/asm-x86/numa.h b/xen/include/asm-x86/numa.h
index 79a445c..9c11db4 100644
--- a/xen/include/asm-x86/numa.h
+++ b/xen/include/asm-x86/numa.h
@@ -21,7 +21,6 @@ extern cpumask_t node_to_cpumask[];
 
 extern void numa_init_array(void);
 
-extern int srat_disabled(void);
 extern void srat_detect_node(int cpu);
 
 extern nodeid_t apicid_to_node[];
diff --git a/xen/include/xen/srat.h b/xen/include/xen/srat.h
index 978f1e8..ab33d86 100644
--- a/xen/include/xen/srat.h
+++ b/xen/include/xen/srat.h
@@ -6,7 +6,9 @@ struct pxm2node {
 nodeid_t node;
 };
 
+extern s8 acpi_numa;
 extern struct pxm2node __read_mostly pxm2node[MAX_NUMNODES];
+extern int srat_disabled(void);
 nodeid_t pxm_to_node(unsigned pxm);
 nodeid_t setup_node(unsigned pxm);
 unsigned node_to_pxm(nodeid_t n);
-- 
2.7.4


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

[Xen-devel] [RFC PATCH v1 15/21] ARM: NUMA: Extract MPIDR from MADT table

[vijay . kilari]

From: Vijaya Kumar K 

Parse MADT table and extract MPIDR for all
CPU IDs in MADT ACPI_MADT_TYPE_GENERIC_INTERRUPT entries
and store in cpu_uid_to_hwid[].

This mapping is used by SRAT table parsing to
extract MPIDR of the CPU ID.

Signed-off-by: Vijaya Kumar 
---
 xen/arch/arm/Makefile  |   1 +
 xen/arch/arm/acpi_numa.c   | 122 +
 xen/arch/arm/numa.c|   1 +
 xen/include/asm-arm/acpi.h |   2 +
 4 files changed, 126 insertions(+)

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 7694485..8c5e67b 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -51,6 +51,7 @@ obj-y += vpsci.o
 obj-y += vuart.o
 obj-$(CONFIG_NUMA) += numa.o
 obj-$(CONFIG_NUMA) += dt_numa.o
+obj-$(CONFIG_ACPI_NUMA) += acpi_numa.o
 
 #obj-bin-y += o
 
diff --git a/xen/arch/arm/acpi_numa.c b/xen/arch/arm/acpi_numa.c
new file mode 100644
index 000..3ee87f2
--- /dev/null
+++ b/xen/arch/arm/acpi_numa.c
@@ -0,0 +1,122 @@
+/*
+ * ACPI based NUMA setup
+ *
+ * Copyright (C) 2016 - Cavium Inc.
+ * Vijaya Kumar K 
+ *
+ * Reads the ACPI MADT and SRAT table to setup NUMA information.
+ *
+ * Contains Excerpts from x86 implementation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+extern nodemask_t numa_nodes_parsed;
+struct uid_to_mpidr {
+u32 uid;
+u64 mpidr;
+};
+
+/* Holds mapping of CPU id to MPIDR read from MADT */
+static struct uid_to_mpidr cpu_uid_to_hwid[NR_CPUS] __read_mostly;
+
+static __init void bad_srat(void)
+{
+int i;
+
+printk(KERN_ERR "SRAT: SRAT not used.\n");
+acpi_numa = -1;
+for (i = 0; i < ARRAY_SIZE(pxm2node); i++)
+pxm2node[i].node = NUMA_NO_NODE;
+}
+
+static u64 acpi_get_cpu_mpidr(int uid)
+{
+int i;
+
+if ( uid < ARRAY_SIZE(cpu_uid_to_hwid) && cpu_uid_to_hwid[uid].uid == uid 
&&
+ cpu_uid_to_hwid[uid].mpidr != MPIDR_INVALID )
+return cpu_uid_to_hwid[uid].mpidr;
+
+for ( i = 0; i < NR_CPUS; i++ )
+{
+if ( cpu_uid_to_hwid[i].uid == uid )
+return cpu_uid_to_hwid[i].mpidr;
+}
+
+return MPIDR_INVALID;
+}
+
+static void __init
+acpi_map_cpu_to_mpidr(struct acpi_madt_generic_interrupt *processor)
+{
+static int cpus = 0;
+
+u64 mpidr = processor->arm_mpidr & MPIDR_HWID_MASK;
+
+if ( mpidr == MPIDR_INVALID )
+{
+printk("Skip MADT cpu entry with invalid MPIDR\n");
+bad_srat();
+return;
+}
+
+cpu_uid_to_hwid[cpus].mpidr = mpidr;
+cpu_uid_to_hwid[cpus].uid = processor->uid;
+
+cpus++;
+}
+
+static int __init acpi_parse_madt_handler(struct acpi_subtable_header *header,
+  const unsigned long end)
+{
+struct acpi_madt_generic_interrupt *p =
+   container_of(header, struct acpi_madt_generic_interrupt, 
header);
+
+if ( BAD_MADT_ENTRY(p, end) )
+{
+/* Though MADT is invalid, we disable NUMA by calling bad_srat() */
+bad_srat();
+return -EINVAL;
+}
+
+acpi_table_print_madt_entry(header);
+acpi_map_cpu_to_mpidr(p);
+
+return 0;
+}
+
+void __init acpi_map_uid_to_mpidr(void)
+{
+int i;
+
+for ( i  = 0; i < NR_CPUS; i++ )
+{
+cpu_uid_to_hwid[i].mpidr = MPIDR_INVALID;
+cpu_uid_to_hwid[i].uid = -1;
+}
+
+acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_INTERRUPT,
+acpi_parse_madt_handler, 0);
+}
+
+void __init acpi_numa_arch_fixup(void) {}
diff --git a/xen/arch/arm/numa.c b/xen/arch/arm/numa.c
index 31dc552..5c49347 100644
--- a/xen/arch/arm/numa.c
+++ b/xen/arch/arm/numa.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/include/asm-arm/acpi.h b/xen/include/asm-arm/acpi.h
index 9f954d3..b1f36f4 100644
--- a/xen/include/asm-arm/acpi.h
+++ b/xen/include/asm-arm/acpi.h
@@ -68,6 +68,8 @@ static inline void enable_acpi(void)
 {
 acpi_disabled = 0;
 }
+
+void acpi_map_uid_to_mpidr(void);
 #else
 #define acpi_disabled (1)
 #define disable_acpi()
-- 
2.7.4


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

[Xen-devel] [RFC PATCH v1 16/21] ARM: NUMA: Extract proximity from SRAT table

[vijay . kilari]

From: Vijaya Kumar K 

Register SRAT entry handler for type
ACPI_SRAT_TYPE_GICC_AFFINITY to parse SRAT table
and extract proximity for all CPU IDs.

Signed-off-by: Vijaya Kumar 
---
 xen/arch/arm/acpi_numa.c  | 55 +++
 xen/drivers/acpi/numa.c   | 37 +++
 xen/drivers/acpi/osl.c|  2 ++
 xen/include/acpi/actbl1.h | 17 ++-
 xen/include/xen/acpi.h| 39 +
 5 files changed, 149 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/acpi_numa.c b/xen/arch/arm/acpi_numa.c
index 3ee87f2..f659275 100644
--- a/xen/arch/arm/acpi_numa.c
+++ b/xen/arch/arm/acpi_numa.c
@@ -105,6 +105,61 @@ static int __init acpi_parse_madt_handler(struct 
acpi_subtable_header *header,
 return 0;
 }
 
+/* Callback for Proximity Domain -> ACPI processor UID mapping */
+void __init acpi_numa_gicc_affinity_init(const struct acpi_srat_gicc_affinity 
*pa)
+{
+int pxm, node;
+u64 mpidr = 0;
+static u32 cpus_in_srat;
+
+if ( srat_disabled() )
+return;
+
+if ( pa->header.length < sizeof(struct acpi_srat_gicc_affinity) )
+{
+printk(XENLOG_WARNING "SRAT: Invalid SRAT header length: %d\n",
+   pa->header.length);
+bad_srat();
+return;
+}
+
+if ( !(pa->flags & ACPI_SRAT_GICC_ENABLED) )
+return;
+
+if ( cpus_in_srat >= NR_CPUS )
+{
+printk(XENLOG_WARNING
+   "SRAT: cpu_to_node_map[%d] is too small to fit all cpus\n",
+   NR_CPUS);
+return;
+}
+
+pxm = pa->proximity_domain;
+node = setup_node(pxm);
+if ( node == NUMA_NO_NODE || node >= MAX_NUMNODES )
+{
+printk(XENLOG_WARNING "SRAT: Too many proximity domains %d\n", pxm);
+bad_srat();
+return;
+}
+
+mpidr = acpi_get_cpu_mpidr(pa->acpi_processor_uid);
+if ( mpidr == MPIDR_INVALID )
+{
+printk(XENLOG_WARNING
+   "SRAT: PXM %d with ACPI ID %d has no valid MPIDR in MADT\n",
+   pxm, pa->acpi_processor_uid);
+bad_srat();
+return;
+}
+
+node_set(node, numa_nodes_parsed);
+cpus_in_srat++;
+acpi_numa = 1;
+printk(XENLOG_INFO "SRAT: PXM %d -> MPIDR 0x%lx -> Node %d\n",
+   pxm, mpidr, node);
+}
+
 void __init acpi_map_uid_to_mpidr(void)
 {
 int i;
diff --git a/xen/drivers/acpi/numa.c b/xen/drivers/acpi/numa.c
index 50bf9f8..ce22e88 100644
--- a/xen/drivers/acpi/numa.c
+++ b/xen/drivers/acpi/numa.c
@@ -25,9 +25,11 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
+#include 
 
 #define ACPI_NUMA  0x8000
 #define _COMPONENT ACPI_NUMA
@@ -105,6 +107,21 @@ void __init acpi_table_print_srat_entry(struct 
acpi_subtable_header * header)
}
 #endif /* ACPI_DEBUG_OUTPUT */
break;
+   case ACPI_SRAT_TYPE_GICC_AFFINITY:
+#ifdef ACPI_DEBUG_OUTPUT
+   {
+   struct acpi_srat_gicc_affinity *p =
+   (struct acpi_srat_gicc_affinity *)header;
+   ACPI_DEBUG_PRINT((ACPI_DB_INFO,
+ "SRAT Processor (acpi id[0x%04x]) in"
+ " proximity domain %d %s\n",
+ p->acpi_processor_uid,
+ p->proximity_domain,
+ (p->flags & ACPI_SRAT_GICC_ENABLED) ?
+ "enabled" : "disabled");
+   }
+#endif /* ACPI_DEBUG_OUTPUT */
+   break;
default:
printk(KERN_WARNING PREFIX
   "Found unsupported SRAT entry (type = %#x)\n",
@@ -185,6 +202,24 @@ int __init acpi_parse_srat(struct acpi_table_header *table)
return 0;
 }
 
+static int __init
+acpi_parse_gicc_affinity(struct acpi_subtable_header *header,
+const unsigned long end)
+{
+   const struct acpi_srat_gicc_affinity *processor_affinity
+   = (struct acpi_srat_gicc_affinity *)header;
+
+   if (!processor_affinity)
+   return -EINVAL;
+
+   acpi_table_print_srat_entry(header);
+
+   /* let architecture-dependent part to do it */
+   acpi_numa_gicc_affinity_init(processor_affinity);
+
+   return 0;
+}
+
 int __init
 acpi_table_parse_srat(int id, acpi_madt_entry_handler handler,
  unsigned int max_entries)
@@ -205,6 +240,8 @@ int __init acpi_numa_init(void)
acpi_table_parse_srat(ACPI_SRAT_TYPE_MEMORY_AFFINITY,
  acpi_parse_memory_affinity,
  NR_NODE_MEMBLKS);
+   acpi_table_parse_srat(ACPI_SRAT_TYPE_GICC_AFFINITY,
+ 

[Xen-devel] [RFC PATCH v1 12/21] ARM: NUMA: Do not expose numa info to DOM0

[vijay . kilari]

From: Vijaya Kumar K 

Delete numa-node-id and distance map from Dom0 DT
so that NUMA information is not exposed to Dom0.

This helps particularly to boot Node 1 devices
as if booting on Node0.

However this approach has limitation where memory allocation
for the devices should be local.

Signed-off-by: Vijaya Kumar 
---
 xen/arch/arm/domain_build.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index c97a1f5..5e89eaa 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -424,6 +424,10 @@ static int write_properties(struct domain *d, struct 
kernel_info *kinfo,
 }
 }
 
+/* Don't expose the property numa to the guest */
+if ( dt_property_name_is_equal(prop, "numa-node-id") )
+continue;
+
 /* Don't expose the property "xen,passthrough" to the guest */
 if ( dt_property_name_is_equal(prop, "xen,passthrough") )
 continue;
@@ -1176,6 +1180,11 @@ static int handle_node(struct domain *d, struct 
kernel_info *kinfo,
 DT_MATCH_TYPE("memory"),
 /* The memory mapped timer is not supported by Xen. */
 DT_MATCH_COMPATIBLE("arm,armv7-timer-mem"),
+/*
+ * NUMA info is not exposed to Dom0.
+ * So, skip distance-map infomation
+ */
+DT_MATCH_COMPATIBLE("numa-distance-map-v1"),
 { /* sentinel */ },
 };
 static const struct dt_device_match timer_matches[] __initconst =
-- 
2.7.4


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

[Xen-devel] [RFC PATCH v1 13/21] ACPI: Refactor acpi SRAT and SLIT table handling code

[vijay . kilari]

From: Vijaya Kumar K 

Move SRAT handling code which is common across
architecture is moved to new file xen/commom/srat.c
from xen/arch/x86/srat.c file. New header file srat.h is
introduced.

Signed-off-by: Vijaya Kumar 
---
 xen/arch/x86/domain_build.c |   1 +
 xen/arch/x86/numa.c |   1 +
 xen/arch/x86/physdev.c  |   1 +
 xen/arch/x86/setup.c|   1 +
 xen/arch/x86/smpboot.c  |   1 +
 xen/arch/x86/srat.c | 129 +--
 xen/arch/x86/x86_64/mm.c|   1 +
 xen/common/Makefile |   1 +
 xen/common/srat.c   | 150 
 xen/drivers/passthrough/vtd/iommu.c |   1 +
 xen/include/asm-x86/numa.h  |   2 -
 xen/include/xen/numa.h  |   1 -
 xen/include/xen/srat.h  |  13 
 13 files changed, 173 insertions(+), 130 deletions(-)

diff --git a/xen/arch/x86/domain_build.c b/xen/arch/x86/domain_build.c
index 243df96..4d7795b 100644
--- a/xen/arch/x86/domain_build.c
+++ b/xen/arch/x86/domain_build.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/x86/numa.c b/xen/arch/x86/numa.c
index 28d1891..58de324 100644
--- a/xen/arch/x86/numa.c
+++ b/xen/arch/x86/numa.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
index 5a49796..2184d62 100644
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 176ee74..ee7a368 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
index 9b390b8..6c61114 100644
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/x86/srat.c b/xen/arch/x86/srat.c
index 58dee09..af12e26 100644
--- a/xen/arch/x86/srat.c
+++ b/xen/arch/x86/srat.c
@@ -18,91 +18,20 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
-static struct acpi_table_slit *__read_mostly acpi_slit;
+extern struct acpi_table_slit *__read_mostly acpi_slit;
 
 static nodemask_t memory_nodes_parsed __initdata;
 static nodemask_t processor_nodes_parsed __initdata;
 extern struct node nodes[MAX_NUMNODES] __initdata;
-
-struct pxm2node {
-   unsigned pxm;
-   nodeid_t node;
-};
-static struct pxm2node __read_mostly pxm2node[MAX_NUMNODES] =
-   { [0 ... MAX_NUMNODES - 1] = {.node = NUMA_NO_NODE} };
-
-static unsigned node_to_pxm(nodeid_t n);
-
 extern int num_node_memblks;
 extern struct node node_memblk_range[NR_NODE_MEMBLKS];
 extern nodeid_t memblk_nodeid[NR_NODE_MEMBLKS];
 static __initdata DECLARE_BITMAP(memblk_hotplug, NR_NODE_MEMBLKS);
 
-static inline bool_t node_found(unsigned idx, unsigned pxm)
-{
-   return ((pxm2node[idx].pxm == pxm) &&
-   (pxm2node[idx].node != NUMA_NO_NODE));
-}
-
-nodeid_t pxm_to_node(unsigned pxm)
-{
-   unsigned i;
-
-   if ((pxm < ARRAY_SIZE(pxm2node)) && node_found(pxm, pxm))
-   return pxm2node[pxm].node;
-
-   for (i = 0; i < ARRAY_SIZE(pxm2node); i++)
-   if (node_found(i, pxm))
-   return pxm2node[i].node;
-
-   return NUMA_NO_NODE;
-}
-
-nodeid_t setup_node(unsigned pxm)
-{
-   nodeid_t node;
-   unsigned idx;
-   static bool_t warned;
-   static unsigned nodes_found;
-
-   BUILD_BUG_ON(MAX_NUMNODES >= NUMA_NO_NODE);
-
-   if (pxm < ARRAY_SIZE(pxm2node)) {
-   if (node_found(pxm, pxm))
-   return pxm2node[pxm].node;
-
-   /* Try to maintain indexing of pxm2node by pxm */
-   if (pxm2node[pxm].node == NUMA_NO_NODE) {
-   idx = pxm;
-   goto finish;
-   }
-   }
-
-   for (idx = 0; idx < ARRAY_SIZE(pxm2node); idx++)
-   if (pxm2node[idx].node == NUMA_NO_NODE)
-   goto finish;
-
-   if (!warned) {
-   printk(KERN_WARNING "SRAT: Too many proximity domains (%#x)\n",
-  pxm);
-   warned = 1;
-   }
-
-   return NUMA_NO_NODE;
-
- finish:
-   node = nodes_found++;
-   if (node >= MAX_NUMNODES)
-   return NUMA_NO_NODE;
-   pxm2node[idx].pxm = pxm;
-   pxm2node[idx].node = node;
-
-   return node;
-}
-
 static __init void bad_srat(void)
 {
int i;
@@ -115,48 +44,6 @@ static __init void bad_srat(void)
mem_hotplug = 0;
 }
 
-/*
- * A lot of BIOS fill in 10 (= no distance) everywhere. This 

[Xen-devel] [RFC PATCH v1 08/21] ARM: NUMA: Parse NUMA distance information

[vijay . kilari]

From: Vijaya Kumar K 

Parse distance-matrix and fetch node distance information.
Store distance information in node_distance[].

Signed-off-by: Vijaya Kumar K 
---
 xen/arch/arm/dt_numa.c | 90 ++
 xen/arch/arm/numa.c| 19 +-
 xen/include/asm-arm/numa.h |  1 +
 3 files changed, 109 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/dt_numa.c b/xen/arch/arm/dt_numa.c
index fce9e67..8979612 100644
--- a/xen/arch/arm/dt_numa.c
+++ b/xen/arch/arm/dt_numa.c
@@ -28,6 +28,19 @@
 
 nodemask_t numa_nodes_parsed;
 extern struct node node_memblk_range[NR_NODE_MEMBLKS];
+extern int _node_distance[MAX_NUMNODES * 2];
+extern int *node_distance;
+
+static int numa_set_distance(u32 nodea, u32 nodeb, u32 distance)
+{
+   if ( nodea >= MAX_NUMNODES || nodeb >= MAX_NUMNODES )
+   return -EINVAL;
+
+   _node_distance[(nodea * MAX_NUMNODES) + nodeb] = distance;
+   node_distance = &_node_distance[0];
+
+   return 0;
+}
 
 /*
  * Even though we connect cpus to numa domains later in SMP
@@ -112,6 +125,66 @@ static int __init dt_numa_process_memory_node(const void 
*fdt, int node,
 return 0;
 }
 
+static int __init dt_numa_parse_distance_map(const void *fdt, int node,
+ const char *name,
+ u32 address_cells,
+ u32 size_cells)
+{
+const struct fdt_property *prop;
+const __be32 *matrix;
+int entry_count, len, i;
+
+printk(XENLOG_INFO "NUMA: parsing numa-distance-map\n");
+
+prop = fdt_get_property(fdt, node, "distance-matrix", );
+if ( !prop )
+{
+printk(XENLOG_WARNING
+   "NUMA: No distance-matrix property in distance-map\n");
+
+return -EINVAL;
+}
+
+if ( len % sizeof(u32) != 0 )
+{
+ printk(XENLOG_WARNING
+"distance-matrix in node is not a multiple of u32\n");
+
+return -EINVAL;
+}
+
+entry_count = len / sizeof(u32);
+if ( entry_count <= 0 )
+{
+printk(XENLOG_WARNING "NUMA: Invalid distance-matrix\n");
+
+return -EINVAL;
+}
+
+matrix = (const __be32 *)prop->data;
+for ( i = 0; i + 2 < entry_count; i += 3 )
+{
+u32 nodea, nodeb, distance;
+
+nodea = dt_read_number(matrix, 1);
+matrix++;
+nodeb = dt_read_number(matrix, 1);
+matrix++;
+distance = dt_read_number(matrix, 1);
+matrix++;
+
+numa_set_distance(nodea, nodeb, distance);
+printk(XENLOG_INFO "NUMA:  distance[node%d -> node%d] = %d\n",
+   nodea, nodeb, distance);
+
+/* Set default distance of node B->A same as A->B */
+if ( nodeb > nodea )
+numa_set_distance(nodeb, nodea, distance);
+}
+
+return 0;
+}
+
 static int __init dt_numa_scan_cpu_node(const void *fdt, int node,
 const char *name, int depth,
 u32 address_cells, u32 size_cells,
@@ -136,6 +209,18 @@ static int __init dt_numa_scan_memory_node(const void 
*fdt, int node,
 return 0;
 }
 
+static int __init dt_numa_scan_distance_node(const void *fdt, int node,
+ const char *name, int depth,
+ u32 address_cells, u32 size_cells,
+ void *data)
+{
+if ( device_tree_node_matches(fdt, node, "distance-map") )
+return dt_numa_parse_distance_map(fdt, node, name, address_cells,
+  size_cells);
+
+return 0;
+}
+
 int __init dt_numa_init(void)
 {
 int ret;
@@ -149,6 +234,11 @@ int __init dt_numa_init(void)
 
 ret = device_tree_for_each_node((void *)device_tree_flattened,
 dt_numa_scan_memory_node, NULL);
+if ( ret )
+return ret;
+
+ret = device_tree_for_each_node((void *)device_tree_flattened,
+dt_numa_scan_distance_node, NULL);
 
 return ret;
 }
diff --git a/xen/arch/arm/numa.c b/xen/arch/arm/numa.c
index 9a7f0bb..11d100b 100644
--- a/xen/arch/arm/numa.c
+++ b/xen/arch/arm/numa.c
@@ -22,14 +22,31 @@
 #include 
 #include 
 #include 
+#include 
+
+int _node_distance[MAX_NUMNODES * 2];
+int *node_distance;
+
+u8 __node_distance(nodeid_t a, nodeid_t b)
+{
+if ( !node_distance )
+return a == b ? 10 : 20;
+
+return _node_distance[a * MAX_NUMNODES + b];
+}
+
+EXPORT_SYMBOL(__node_distance);
 
 int __init numa_init(void)
 {
-int ret = 0;
+int i, ret = 0;
 
 if ( numa_off )
 goto no_numa;
 
+for ( i = 0; i < MAX_NUMNODES * 2; i++ )
+_node_distance[i] = 0;
+
 ret = dt_numa_init();
 
 no_numa:
diff --git a/xen/include/asm-arm/numa.h b/xen/include/asm-arm/numa.h
index cdfeecd..b8857e2 100644
--- 

[Xen-devel] [RFC PATCH v1 09/21] ARM: NUMA: Add CPU NUMA support

[vijay . kilari]

From: Vijaya Kumar K 

For each cpu, update cpu_to_node[] with node id from
the MPIDR registers. Also, initialize cpu_to_node[]
with node 0.

Add macros to access cpu_to_node[] information.

Signed-off-by: Vijaya Kumar K 
---
 xen/arch/arm/numa.c| 25 +
 xen/arch/arm/setup.c   |  2 ++
 xen/arch/arm/smpboot.c |  3 +++
 xen/include/asm-arm/numa.h | 15 +++
 4 files changed, 45 insertions(+)

diff --git a/xen/arch/arm/numa.c b/xen/arch/arm/numa.c
index 11d100b..d4dbad4 100644
--- a/xen/arch/arm/numa.c
+++ b/xen/arch/arm/numa.c
@@ -23,9 +23,23 @@
 #include 
 #include 
 #include 
+#include 
 
 int _node_distance[MAX_NUMNODES * 2];
 int *node_distance;
+extern nodemask_t numa_nodes_parsed;
+
+void __init numa_set_cpu_node(int cpu, unsigned long hwid)
+{
+unsigned node;
+
+node = hwid >> 16 & 0xf;
+if ( !node_isset(node, numa_nodes_parsed) || node == MAX_NUMNODES )
+node = 0;
+
+numa_set_node(cpu, node);
+numa_add_cpu(cpu);
+}
 
 u8 __node_distance(nodeid_t a, nodeid_t b)
 {
@@ -37,6 +51,17 @@ u8 __node_distance(nodeid_t a, nodeid_t b)
 
 EXPORT_SYMBOL(__node_distance);
 
+/*
+ * Setup early cpu_to_node.
+ */
+void __init init_cpu_to_node(void)
+{
+int i;
+
+for ( i = 0; i < nr_cpu_ids; i++ )
+numa_set_node(i, 0);
+}
+
 int __init numa_init(void)
 {
 int i, ret = 0;
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index b6618ca..5612ba6 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -749,6 +749,8 @@ void __init start_xen(unsigned long boot_phys_offset,
xen_paddr, xen_paddr + xen_bootmodule->size);
 xen_bootmodule->start = xen_paddr;
 
+init_cpu_to_node();
+
 setup_mm(fdt_paddr, fdt_size);
 
 /* Parse the ACPI tables for possible boot-time configuration */
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index 32e8722..3667d4b 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -313,6 +314,8 @@ void start_secondary(unsigned long boot_phys_offset,
  */
 smp_wmb();
 
+numa_set_cpu_node(cpuid, hwid);
+
 /* Now report this CPU is up */
 cpumask_set_cpu(cpuid, _online_map);
 
diff --git a/xen/include/asm-arm/numa.h b/xen/include/asm-arm/numa.h
index b8857e2..33a9e53 100644
--- a/xen/include/asm-arm/numa.h
+++ b/xen/include/asm-arm/numa.h
@@ -2,16 +2,26 @@
 #define __ARCH_ARM_NUMA_H
 
 #include 
+#include 
 
 typedef u8 nodeid_t;
 
 #define NODES_SHIFT 2
 
 #ifdef CONFIG_NUMA
+
+extern cpumask_t node_to_cpumask[];
+extern nodeid_t  cpu_to_node[NR_CPUS];
+#define cpu_to_node(cpu) (cpu_to_node[cpu])
+#define parent_node(node)(node)
+#define node_to_first_cpu(node)  (__ffs(node_to_cpumask[node]))
+#define node_to_cpumask(node)(node_to_cpumask[node])
+
 int arch_numa_setup(char *opt);
 int __init numa_init(void);
 int __init dt_numa_init(void);
 u8 __node_distance(nodeid_t a, nodeid_t b);
+void __init numa_set_cpu_node(int cpu, unsigned long hwid);
 #else
 static inline int arch_numa_setup(char *opt)
 {
@@ -28,6 +38,11 @@ static inline int __init dt_numa_init(void)
 return -EINVAL;
 }
 
+static inline void __init numa_set_cpu_node(int cpu, unsigned long hwid)
+{
+return;
+}
+
 /* Fake one node for now. See also node_online_map. */
 #define cpu_to_node(cpu) 0
 #define node_to_cpumask(node)   (cpu_online_map)
-- 
2.7.4


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

[Xen-devel] [RFC PATCH v1 10/21] ARM: NUMA: Add memory NUMA support

[vijay . kilari]

From: Vijaya Kumar K 

For all banks in bootinfo.mem, update nodes[] with
corresponding nodeid and register these nodes by
calling setup_node_bootmem().
compute memnode_shift and initialize memnodemap[] to fetch
nodeid for a given physical address.

Signed-off-by: Vijaya Kumar K 
---
 xen/arch/arm/numa.c| 90 ++
 xen/common/numa.c  | 14 
 xen/include/xen/numa.h |  1 +
 3 files changed, 105 insertions(+)

diff --git a/xen/arch/arm/numa.c b/xen/arch/arm/numa.c
index d4dbad4..aa34c82 100644
--- a/xen/arch/arm/numa.c
+++ b/xen/arch/arm/numa.c
@@ -24,10 +24,15 @@
 #include 
 #include 
 #include 
+#include 
 
 int _node_distance[MAX_NUMNODES * 2];
 int *node_distance;
 extern nodemask_t numa_nodes_parsed;
+extern struct node nodes[MAX_NUMNODES] __initdata;
+extern int num_node_memblks;
+extern struct node node_memblk_range[NR_NODE_MEMBLKS];
+extern nodeid_t memblk_nodeid[NR_NODE_MEMBLKS];
 
 void __init numa_set_cpu_node(int cpu, unsigned long hwid)
 {
@@ -51,6 +56,88 @@ u8 __node_distance(nodeid_t a, nodeid_t b)
 
 EXPORT_SYMBOL(__node_distance);
 
+static int __init numa_mem_init(void)
+{
+nodemask_t memory_nodes_parsed;
+int bank, nodeid;
+struct node *nd;
+paddr_t start, size, end;
+
+nodes_clear(memory_nodes_parsed);
+for ( bank = 0 ; bank < bootinfo.mem.nr_banks; bank++ )
+{
+start = bootinfo.mem.bank[bank].start;
+size = bootinfo.mem.bank[bank].size;
+end = start + size;
+
+nodeid = get_numa_node(start, end);
+if ( nodeid == -EINVAL || nodeid > MAX_NUMNODES )
+{
+printk(XENLOG_WARNING
+   "NUMA: node for mem bank start 0x%lx - 0x%lx not found\n",
+   start, end);
+
+return -EINVAL;
+}
+
+nd = [nodeid];
+if ( !node_test_and_set(nodeid, memory_nodes_parsed) )
+{
+nd->start = start;
+nd->end = end;
+}
+else
+{
+if ( start < nd->start )
+nd->start = start;
+if ( nd->end < end )
+nd->end = end;
+}
+}
+
+return 0;
+}
+
+/* Use the information discovered above to actually set up the nodes. */
+static int __init numa_scan_mem_nodes(void)
+{
+int i;
+
+memnode_shift = compute_hash_shift(node_memblk_range, num_node_memblks,
+   memblk_nodeid);
+if ( memnode_shift < 0 )
+{
+printk(XENLOG_WARNING "No NUMA hash found.\n");
+memnode_shift = 0;
+}
+
+for_each_node_mask(i, numa_nodes_parsed)
+{
+u64 size = node_memblk_range[i].end - node_memblk_range[i].start;
+
+if ( size == 0 )
+printk(XENLOG_WARNING "NUMA: Node %u has no memory. \n", i);
+
+printk(XENLOG_INFO
+   "NUMA: NODE[%d]: Start 0x%lx End 0x%lx\n",
+   i, nodes[i].start, nodes[i].end);
+setup_node_bootmem(i, nodes[i].start, nodes[i].end);
+}
+
+return 0;
+}
+
+static int __init numa_initmem_init(void)
+{
+if ( !numa_mem_init() )
+{
+if ( !numa_scan_mem_nodes() )
+return 0;
+}
+
+return -EINVAL;
+}
+
 /*
  * Setup early cpu_to_node.
  */
@@ -74,6 +161,9 @@ int __init numa_init(void)
 
 ret = dt_numa_init();
 
+if ( !ret )
+ret = numa_initmem_init();
+
 no_numa:
 return ret;
 }
diff --git a/xen/common/numa.c b/xen/common/numa.c
index 62c76af..2f5266a 100644
--- a/xen/common/numa.c
+++ b/xen/common/numa.c
@@ -63,6 +63,20 @@ void __init numa_add_memblk(nodeid_t nodeid, u64 start, u64 
size)
 num_node_memblks++;
 }
 
+int __init get_numa_node(u64 start, u64 end)
+{
+int i;
+
+for ( i = 0; i < num_node_memblks; i++ )
+{
+if ( start >= node_memblk_range[i].start &&
+ end <= node_memblk_range[i].end )
+return memblk_nodeid[i];
+}
+
+return -EINVAL;
+}
+
 int valid_numa_range(u64 start, u64 end, nodeid_t node)
 {
 #ifdef CONFIG_NUMA
diff --git a/xen/include/xen/numa.h b/xen/include/xen/numa.h
index 9392a89..4f04ab4 100644
--- a/xen/include/xen/numa.h
+++ b/xen/include/xen/numa.h
@@ -68,6 +68,7 @@ static inline __attribute__((pure)) nodeid_t 
phys_to_nid(paddr_t addr)
 #endif /* CONFIG_NUMA */
 
 extern void numa_add_memblk(nodeid_t nodeid, u64 start, u64 size);
+extern int get_numa_node(u64 start, u64 end);
 extern int valid_numa_range(u64 start, u64 end, nodeid_t node);
 extern int conflicting_memblks(u64 start, u64 end);
 extern void cutoff_node(int i, u64 start, u64 end);
-- 
2.7.4


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

[Xen-devel] [RFC PATCH v1 11/21] ARM: NUMA: Add fallback on NUMA failure

[vijay . kilari]

From: Vijaya Kumar K 

On NUMA initialization failure, reset all the
NUMA structures to emulate as single node.

Signed-off-by: Vijaya Kumar 
---
 xen/arch/arm/numa.c | 50 --
 1 file changed, 48 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/numa.c b/xen/arch/arm/numa.c
index aa34c82..31dc552 100644
--- a/xen/arch/arm/numa.c
+++ b/xen/arch/arm/numa.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -127,6 +128,29 @@ static int __init numa_scan_mem_nodes(void)
 return 0;
 }
 
+static void __init numa_dummy_init(unsigned long start_pfn,
+   unsigned long end_pfn)
+{
+int i;
+
+nodes_clear(numa_nodes_parsed);
+memnode_shift = BITS_PER_LONG - 1;
+memnodemap = _memnodemap;
+nodes_clear(node_online_map);
+node_set_online(0);
+
+for ( i = 0; i < NR_CPUS; i++ )
+numa_set_node(i, 0);
+
+node_distance = NULL;
+for ( i = 0; i < MAX_NUMNODES * 2; i++ )
+_node_distance[i] = 0;
+
+cpumask_copy(_to_cpumask[0], cpumask_of(0));
+setup_node_bootmem(0, (u64)start_pfn << PAGE_SHIFT,
+   (u64)end_pfn << PAGE_SHIFT);
+}
+
 static int __init numa_initmem_init(void)
 {
 if ( !numa_mem_init() )
@@ -151,7 +175,9 @@ void __init init_cpu_to_node(void)
 
 int __init numa_init(void)
 {
-int i, ret = 0;
+int i, bank, ret = 0;
+paddr_t ram_start = ~0;
+paddr_t ram_end = 0;
 
 if ( numa_off )
 goto no_numa;
@@ -164,8 +190,28 @@ int __init numa_init(void)
 if ( !ret )
 ret = numa_initmem_init();
 
+if ( !ret )
+return 0;
+
 no_numa:
-return ret;
+for ( bank = 0 ; bank < bootinfo.mem.nr_banks; bank++ )
+{
+paddr_t bank_start = bootinfo.mem.bank[bank].start;
+paddr_t bank_end = bank_start + bootinfo.mem.bank[bank].size;
+
+ram_start = min(ram_start, bank_start);
+ram_end = max(ram_end, bank_end);
+}
+
+printk(XENLOG_INFO "%s\n",
+   numa_off ? "NUMA turned off" : "No NUMA configuration found");
+
+printk(XENLOG_INFO "Faking a node at %016"PRIx64"-%016"PRIx64"\n",
+   (u64)ram_start, (u64)ram_end);
+
+numa_dummy_init(PFN_UP(ram_start),PFN_DOWN(ram_end));
+
+return 0;
 }
 
 int __init arch_numa_setup(char *opt)
-- 
2.7.4


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

[Xen-devel] [RFC PATCH v1 07/21] ARM: NUMA: Parse memory NUMA information

[vijay . kilari]

From: Vijaya Kumar K 

Parse memory node and fetch numa-node-id information.
For each memory range, store in node_memblk_range[]
along with node id.

Signed-off-by: Vijaya Kumar K 
---
 xen/arch/arm/bootfdt.c|  4 +--
 xen/arch/arm/dt_numa.c| 84 ++-
 xen/common/numa.c |  8 +
 xen/include/xen/device_tree.h |  3 ++
 xen/include/xen/numa.h|  1 +
 5 files changed, 97 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index d1122d8..5e2df92 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -56,8 +56,8 @@ static bool_t __init device_tree_node_compatible(const void 
*fdt, int node,
 return 0;
 }
 
-static void __init device_tree_get_reg(const __be32 **cell, u32 address_cells,
-   u32 size_cells, u64 *start, u64 *size)
+void __init device_tree_get_reg(const __be32 **cell, u32 address_cells,
+u32 size_cells, u64 *start, u64 *size)
 {
 *start = dt_next_cell(address_cells, cell);
 *size = dt_next_cell(size_cells, cell);
diff --git a/xen/arch/arm/dt_numa.c b/xen/arch/arm/dt_numa.c
index 4b94c36..fce9e67 100644
--- a/xen/arch/arm/dt_numa.c
+++ b/xen/arch/arm/dt_numa.c
@@ -27,6 +27,7 @@
 #include 
 
 nodemask_t numa_nodes_parsed;
+extern struct node node_memblk_range[NR_NODE_MEMBLKS];
 
 /*
  * Even though we connect cpus to numa domains later in SMP
@@ -48,11 +49,73 @@ static int __init dt_numa_process_cpu_node(const void *fdt, 
int node,
 return 0;
 }
 
+static int __init dt_numa_process_memory_node(const void *fdt, int node,
+  const char *name,
+  u32 address_cells,
+  u32 size_cells)
+{
+const struct fdt_property *prop;
+int i, ret, banks;
+const __be32 *cell;
+paddr_t start, size;
+u32 reg_cells = address_cells + size_cells;
+u32 nid;
+
+if ( address_cells < 1 || size_cells < 1 )
+{
+printk(XENLOG_WARNING
+   "fdt: node `%s': invalid #address-cells or #size-cells", name);
+return -EINVAL;
+}
+
+nid = device_tree_get_u32(fdt, node, "numa-node-id", MAX_NUMNODES);
+if ( nid >= MAX_NUMNODES) {
+/*
+ * No node id found. Skip this memory node.
+ */
+return 0;
+}
+
+prop = fdt_get_property(fdt, node, "reg", NULL);
+if ( !prop )
+{
+printk(XENLOG_WARNING "fdt: node `%s': missing `reg' property\n",
+   name);
+return -EINVAL;
+}
+
+cell = (const __be32 *)prop->data;
+banks = fdt32_to_cpu(prop->len) / (reg_cells * sizeof (u32));
+
+for ( i = 0; i < banks; i++ )
+{
+device_tree_get_reg(, address_cells, size_cells, , );
+if ( !size )
+continue;
+
+/* It is fine to add this area to the nodes data it will be used 
later*/
+ret = conflicting_memblks(start, start + size);
+if (ret < 0)
+ numa_add_memblk(nid, start, size);
+else
+{
+ printk(XENLOG_ERR
+"NUMA DT: node %u (%"PRIx64"-%"PRIx64") overlaps with ret 
%d (%"PRIx64"-%"PRIx64")\n",
+nid, start, start + size, ret,
+node_memblk_range[i].start, node_memblk_range[i].end);
+ return -EINVAL;
+}
+}
+
+node_set(nid, numa_nodes_parsed);
+
+return 0;
+}
+
 static int __init dt_numa_scan_cpu_node(const void *fdt, int node,
 const char *name, int depth,
 u32 address_cells, u32 size_cells,
 void *data)
-
 {
 if ( device_tree_node_matches(fdt, node, "cpu") )
 return dt_numa_process_cpu_node(fdt, node, name, address_cells,
@@ -61,6 +124,18 @@ static int __init dt_numa_scan_cpu_node(const void *fdt, 
int node,
 return 0;
 }
 
+static int __init dt_numa_scan_memory_node(const void *fdt, int node,
+   const char *name, int depth,
+   u32 address_cells, u32 size_cells,
+   void *data)
+{
+if ( device_tree_node_matches(fdt, node, "memory") )
+return dt_numa_process_memory_node(fdt, node, name, address_cells,
+   size_cells);
+
+return 0;
+}
+
 int __init dt_numa_init(void)
 {
 int ret;
@@ -68,5 +143,12 @@ int __init dt_numa_init(void)
 nodes_clear(numa_nodes_parsed);
 ret = device_tree_for_each_node((void *)device_tree_flattened,
 dt_numa_scan_cpu_node, NULL);
+
+if ( ret )
+return ret;
+
+ret = device_tree_for_each_node((void *)device_tree_flattened,
+   

[Xen-devel] [RFC PATCH v1 06/21] ARM: NUMA: Parse CPU NUMA information

[vijay . kilari]

From: Vijaya Kumar K 

Parse CPU node and fetch numa-node-id information.
For each node-id found, update nodemask_t mask.

Call numa_init() from setup_mm() with start and end
pfn of the complete ram..

Signed-off-by: Vijaya Kumar K 
---
 xen/arch/arm/Makefile |  1 +
 xen/arch/arm/bootfdt.c|  8 ++---
 xen/arch/arm/dt_numa.c| 72 +++
 xen/arch/arm/numa.c   | 14 +
 xen/arch/arm/setup.c  |  3 ++
 xen/include/asm-arm/numa.h| 14 +
 xen/include/xen/device_tree.h |  4 +++
 7 files changed, 112 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index b5d7a19..7694485 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -50,6 +50,7 @@ obj-y += vtimer.o
 obj-y += vpsci.o
 obj-y += vuart.o
 obj-$(CONFIG_NUMA) += numa.o
+obj-$(CONFIG_NUMA) += dt_numa.o
 
 #obj-bin-y += o
 
diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index 979f675..d1122d8 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -17,8 +17,8 @@
 #include 
 #include 
 
-static bool_t __init device_tree_node_matches(const void *fdt, int node,
-  const char *match)
+bool_t __init device_tree_node_matches(const void *fdt, int node,
+   const char *match)
 {
 const char *name;
 size_t match_len;
@@ -63,8 +63,8 @@ static void __init device_tree_get_reg(const __be32 **cell, 
u32 address_cells,
 *size = dt_next_cell(size_cells, cell);
 }
 
-static u32 __init device_tree_get_u32(const void *fdt, int node,
-  const char *prop_name, u32 dflt)
+u32 __init device_tree_get_u32(const void *fdt, int node,
+   const char *prop_name, u32 dflt)
 {
 const struct fdt_property *prop;
 
diff --git a/xen/arch/arm/dt_numa.c b/xen/arch/arm/dt_numa.c
new file mode 100644
index 000..4b94c36
--- /dev/null
+++ b/xen/arch/arm/dt_numa.c
@@ -0,0 +1,72 @@
+/*
+ * OF NUMA Parsing support.
+ *
+ * Copyright (C) 2015 - 2016 Cavium Inc.
+ *
+ * Some code extracts are taken from linux drivers/of/of_numa.c
+ *
+ * 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 
+
+nodemask_t numa_nodes_parsed;
+
+/*
+ * Even though we connect cpus to numa domains later in SMP
+ * init, we need to know the node ids now for all cpus.
+*/
+static int __init dt_numa_process_cpu_node(const void *fdt, int node,
+   const char *name,
+   u32 address_cells, u32 size_cells)
+{
+u32 nid;
+
+nid = device_tree_get_u32(fdt, node, "numa-node-id", MAX_NUMNODES);
+
+if ( nid >= MAX_NUMNODES )
+printk(XENLOG_WARNING "NUMA: Node id %u exceeds maximum value\n", nid);
+else
+node_set(nid, numa_nodes_parsed);
+
+return 0;
+}
+
+static int __init dt_numa_scan_cpu_node(const void *fdt, int node,
+const char *name, int depth,
+u32 address_cells, u32 size_cells,
+void *data)
+
+{
+if ( device_tree_node_matches(fdt, node, "cpu") )
+return dt_numa_process_cpu_node(fdt, node, name, address_cells,
+size_cells);
+
+return 0;
+}
+
+int __init dt_numa_init(void)
+{
+int ret;
+
+nodes_clear(numa_nodes_parsed);
+ret = device_tree_for_each_node((void *)device_tree_flattened,
+dt_numa_scan_cpu_node, NULL);
+return ret;
+}
diff --git a/xen/arch/arm/numa.c b/xen/arch/arm/numa.c
index 59d09c7..9a7f0bb 100644
--- a/xen/arch/arm/numa.c
+++ b/xen/arch/arm/numa.c
@@ -21,6 +21,20 @@
 #include 
 #include 
 #include 
+#include 
+
+int __init numa_init(void)
+{
+int ret = 0;
+
+if ( numa_off )
+goto no_numa;
+
+ret = dt_numa_init();
+
+no_numa:
+return ret;
+}
 
 int __init arch_numa_setup(char *opt)
 {
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 049e449..b6618ca 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -39,6 +39,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -753,6 +754,8 @@ void __init start_xen(unsigned long 

[Xen-devel] [RFC PATCH v1 01/21] ARM: NUMA: Add existing ARM numa code under CONFIG_NUMA

[vijay . kilari]

From: Vijaya Kumar K 

Right not CONFIG_NUMA is not enabled for ARM and
existing code in asm-arm/numa.h is for !COFIG_NUMA.
Hence put this code under #ifndef CONFIG_NUMA.

This help to make this changes work when CONFIG_NUMA
is not enabled.

Also define NODES_SHIFT macro for ARM.

Signed-off-by: Vijaya Kumar K 
---
 xen/include/asm-arm/numa.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/xen/include/asm-arm/numa.h b/xen/include/asm-arm/numa.h
index a2c1a34..a60c7eb 100644
--- a/xen/include/asm-arm/numa.h
+++ b/xen/include/asm-arm/numa.h
@@ -3,6 +3,9 @@
 
 typedef u8 nodeid_t;
 
+#define NODES_SHIFT 2
+
+#ifndef CONFIG_NUMA
 /* Fake one node for now. See also node_online_map. */
 #define cpu_to_node(cpu) 0
 #define node_to_cpumask(node)   (cpu_online_map)
@@ -16,6 +19,7 @@ static inline __attribute__((pure)) nodeid_t 
phys_to_nid(paddr_t addr)
 #define node_spanned_pages(nid) (total_pages)
 #define node_start_pfn(nid) (pdx_to_pfn(frametable_base_pdx))
 #define __node_distance(a, b) (20)
+#endif /* CONFIG_NUMA */
 
 static inline unsigned int arch_get_dma_bitsize(void)
 {
-- 
2.7.4


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

[Xen-devel] [RFC PATCH v1 03/21] NUMA: Move arch specific NUMA code as common

[vijay . kilari]

From: Vijaya Kumar K 

Move some common numa code from xen/arch/x86/srat.c
to xen/common/numa.c

Signed-off-by: Vijaya Kumar K 
---
 xen/arch/x86/srat.c| 54 -
 xen/common/numa.c  | 55 ++
 xen/include/asm-x86/acpi.h |  1 -
 xen/include/asm-x86/numa.h |  1 -
 xen/include/xen/numa.h |  5 -
 5 files changed, 63 insertions(+), 53 deletions(-)

diff --git a/xen/arch/x86/srat.c b/xen/arch/x86/srat.c
index d86783e..58dee09 100644
--- a/xen/arch/x86/srat.c
+++ b/xen/arch/x86/srat.c
@@ -25,7 +25,7 @@ static struct acpi_table_slit *__read_mostly acpi_slit;
 
 static nodemask_t memory_nodes_parsed __initdata;
 static nodemask_t processor_nodes_parsed __initdata;
-static struct node nodes[MAX_NUMNODES] __initdata;
+extern struct node nodes[MAX_NUMNODES] __initdata;
 
 struct pxm2node {
unsigned pxm;
@@ -36,9 +36,9 @@ static struct pxm2node __read_mostly pxm2node[MAX_NUMNODES] =
 
 static unsigned node_to_pxm(nodeid_t n);
 
-static int num_node_memblks;
-static struct node node_memblk_range[NR_NODE_MEMBLKS];
-static nodeid_t memblk_nodeid[NR_NODE_MEMBLKS];
+extern int num_node_memblks;
+extern struct node node_memblk_range[NR_NODE_MEMBLKS];
+extern nodeid_t memblk_nodeid[NR_NODE_MEMBLKS];
 static __initdata DECLARE_BITMAP(memblk_hotplug, NR_NODE_MEMBLKS);
 
 static inline bool_t node_found(unsigned idx, unsigned pxm)
@@ -103,52 +103,6 @@ nodeid_t setup_node(unsigned pxm)
return node;
 }
 
-int valid_numa_range(u64 start, u64 end, nodeid_t node)
-{
-   int i;
-
-   for (i = 0; i < num_node_memblks; i++) {
-   struct node *nd = _memblk_range[i];
-
-   if (nd->start <= start && nd->end > end &&
-   memblk_nodeid[i] == node )
-   return 1;
-   }
-
-   return 0;
-}
-
-static __init int conflicting_memblks(u64 start, u64 end)
-{
-   int i;
-
-   for (i = 0; i < num_node_memblks; i++) {
-   struct node *nd = _memblk_range[i];
-   if (nd->start == nd->end)
-   continue;
-   if (nd->end > start && nd->start < end)
-   return i;
-   if (nd->end == end && nd->start == start)
-   return i;
-   }
-   return -1;
-}
-
-static __init void cutoff_node(int i, u64 start, u64 end)
-{
-   struct node *nd = [i];
-   if (nd->start < start) {
-   nd->start = start;
-   if (nd->end < nd->start)
-   nd->start = nd->end;
-   }
-   if (nd->end > end) {
-   nd->end = end;
-   if (nd->start > nd->end)
-   nd->start = nd->end;
-   }
-}
-
 static __init void bad_srat(void)
 {
int i;
diff --git a/xen/common/numa.c b/xen/common/numa.c
index 59dcb63..13f147c 100644
--- a/xen/common/numa.c
+++ b/xen/common/numa.c
@@ -46,6 +46,61 @@ nodeid_t cpu_to_node[NR_CPUS] __read_mostly = {
 
 cpumask_t node_to_cpumask[MAX_NUMNODES] __read_mostly;
 
+int num_node_memblks;
+struct node node_memblk_range[NR_NODE_MEMBLKS];
+nodeid_t memblk_nodeid[NR_NODE_MEMBLKS];
+struct node nodes[MAX_NUMNODES] __initdata;
+
+int valid_numa_range(u64 start, u64 end, nodeid_t node)
+{
+#ifdef CONFIG_NUMA
+int i;
+
+for (i = 0; i < num_node_memblks; i++) {
+struct node *nd = _memblk_range[i];
+
+if (nd->start <= start && nd->end > end &&
+memblk_nodeid[i] == node )
+return 1;
+}
+
+return 0;
+#else
+return 1;
+#endif
+}
+
+__init int conflicting_memblks(u64 start, u64 end)
+{
+int i;
+
+for (i = 0; i < num_node_memblks; i++) {
+struct node *nd = _memblk_range[i];
+if (nd->start == nd->end)
+continue;
+if (nd->end > start && nd->start < end)
+return i;
+if (nd->end == end && nd->start == start)
+return i;
+}
+return -1;
+}
+
+__init void cutoff_node(int i, u64 start, u64 end)
+{
+struct node *nd = [i];
+if (nd->start < start) {
+nd->start = start;
+if (nd->end < nd->start)
+nd->start = nd->end;
+}
+if (nd->end > end) {
+nd->end = end;
+if (nd->start > nd->end)
+nd->start = nd->end;
+}
+}
+
 /*
  * Given a shift value, try to populate memnodemap[]
  * Returns :
diff --git a/xen/include/asm-x86/acpi.h b/xen/include/asm-x86/acpi.h
index d36bee9..f1a8e9d 100644
--- a/xen/include/asm-x86/acpi.h
+++ b/xen/include/asm-x86/acpi.h
@@ -106,7 +106,6 @@ extern void acpi_reserve_bootmem(void);
 
 extern s8 acpi_numa;
 extern int acpi_scan_nodes(u64 start, u64 end);
-#define NR_NODE_MEMBLKS (MAX_NUMNODES*2)
 
 #ifdef CONFIG_ACPI_SLEEP
 
diff --git a/xen/include/asm-x86/numa.h b/xen/include/asm-x86/numa.h
index 61bcd8e..df1f7d5 100644
--- a/xen/include/asm-x86/numa.h
+++ 

[Xen-devel] [RFC PATCH v1 05/21] ARM: efi: Do not delete memory node from fdt

[vijay . kilari]

From: Vijaya Kumar K 

When booting in UEFI mode, UEFI passes memory information
to Dom0 using EFI memory descriptor table and deletes the
memory nodes from the host DT. However to fetch the memory
numa node id, memory DT node should not be deleted by EFI stub.

With this patch, do not delete memory node from FDT.
This memory nodes are later used by XEN to extract numa
node id information.

Also, parse memory node only if bootmeminfo is NULL.

Signed-off-by: Vijaya Kumar K 
---
 xen/arch/arm/bootfdt.c  |  9 +++--
 xen/arch/arm/efi/efi-boot.h | 25 -
 2 files changed, 7 insertions(+), 27 deletions(-)

diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index cae6f83..979f675 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -285,8 +285,13 @@ static int __init early_scan_node(const void *fdt,
   u32 address_cells, u32 size_cells,
   void *data)
 {
-if ( device_tree_node_matches(fdt, node, "memory") )
-process_memory_node(fdt, node, name, address_cells, size_cells);
+/*
+ * Parse memory node only if bootinfo.mem is empty.
+ */
+if ( bootinfo.mem.nr_banks == 0 ) {
+if ( device_tree_node_matches(fdt, node, "memory") )
+process_memory_node(fdt, node, name, address_cells, size_cells);
+}
 else if ( device_tree_node_compatible(fdt, node, "xen,multiboot-module" ) 
||
   device_tree_node_compatible(fdt, node, "multiboot,module" ))
 process_multiboot_node(fdt, node, name, address_cells, size_cells);
diff --git a/xen/arch/arm/efi/efi-boot.h b/xen/arch/arm/efi/efi-boot.h
index 045d6ce..0b9c37f 100644
--- a/xen/arch/arm/efi/efi-boot.h
+++ b/xen/arch/arm/efi/efi-boot.h
@@ -192,33 +192,8 @@ EFI_STATUS __init fdt_add_uefi_nodes(EFI_SYSTEM_TABLE 
*sys_table,
 int status;
 u32 fdt_val32;
 u64 fdt_val64;
-int prev;
 int num_rsv;
 
-/*
- * Delete any memory nodes present.  The EFI memory map is the only
- * memory description provided to Xen.
- */
-prev = 0;
-for (;;)
-{
-const char *type;
-int len;
-
-node = fdt_next_node(fdt, prev, NULL);
-if ( node < 0 )
-break;
-
-type = fdt_getprop(fdt, node, "device_type", );
-if ( type && strncmp(type, "memory", len) == 0 )
-{
-fdt_del_node(fdt, node);
-continue;
-}
-
-prev = node;
-}
-
/*
 * Delete all memory reserve map entries. When booting via UEFI,
 * kernel will use the UEFI memory map to find reserved regions.
-- 
2.7.4


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

[Xen-devel] [RFC PATCH v1 04/21] NUMA: Refactor generic and arch specific code of numa_setup

[vijay . kilari]

From: Vijaya Kumar K 

numa_setup() contains generic and arch specific code.
Split numa_setup() and move architecture specific code
under arch_numa_setup().

Signed-off-by: Vijaya Kumar K 
---
 xen/arch/arm/Makefile  |  1 +
 xen/arch/arm/numa.c| 28 
 xen/arch/x86/numa.c| 11 +--
 xen/common/numa.c  | 14 ++
 xen/include/asm-arm/numa.h |  9 -
 xen/include/asm-x86/numa.h |  2 +-
 xen/include/xen/numa.h |  1 +
 7 files changed, 54 insertions(+), 12 deletions(-)

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 7afb8a3..b5d7a19 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -49,6 +49,7 @@ obj-y += vm_event.o
 obj-y += vtimer.o
 obj-y += vpsci.o
 obj-y += vuart.o
+obj-$(CONFIG_NUMA) += numa.o
 
 #obj-bin-y += o
 
diff --git a/xen/arch/arm/numa.c b/xen/arch/arm/numa.c
new file mode 100644
index 000..59d09c7
--- /dev/null
+++ b/xen/arch/arm/numa.c
@@ -0,0 +1,28 @@
+/*
+ * ARM NUMA Implementation
+ *
+ * Copyright (C) 2016 - Cavium Inc.
+ * Vijaya Kumar K 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+int __init arch_numa_setup(char *opt)
+{
+return 1;
+}
diff --git a/xen/arch/x86/numa.c b/xen/arch/x86/numa.c
index bc787e0..28d1891 100644
--- a/xen/arch/x86/numa.c
+++ b/xen/arch/x86/numa.c
@@ -18,9 +18,6 @@
 #include 
 #include 
 
-static int numa_setup(char *s);
-custom_param("numa", numa_setup);
-
 #ifndef Dprintk
 #define Dprintk(x...)
 #endif
@@ -34,7 +31,6 @@ nodeid_t apicid_to_node[MAX_LOCAL_APIC] = {
 
 nodemask_t __read_mostly node_online_map = { { [0] = 1UL } };
 
-bool_t numa_off = 0;
 s8 acpi_numa = 0;
 
 int srat_disabled(void)
@@ -145,13 +141,8 @@ void __init numa_initmem_init(unsigned long start_pfn, 
unsigned long end_pfn)
 (u64)end_pfn << PAGE_SHIFT);
 }
 
-/* [numa=off] */
-static __init int numa_setup(char *opt) 
+int __init arch_numa_setup(char *opt)
 { 
-if ( !strncmp(opt,"off",3) )
-numa_off = 1;
-if ( !strncmp(opt,"on",2) )
-numa_off = 0;
 #ifdef CONFIG_NUMA_EMU
 if ( !strncmp(opt, "fake=", 5) )
 {
diff --git a/xen/common/numa.c b/xen/common/numa.c
index 13f147c..9b9cf9c 100644
--- a/xen/common/numa.c
+++ b/xen/common/numa.c
@@ -32,6 +32,10 @@
 #include 
 #include 
 
+static int numa_setup(char *s);
+custom_param("numa", numa_setup);
+
+bool_t numa_off = 0;
 struct node_data node_data[MAX_NUMNODES];
 
 /* Mapping from pdx to node id */
@@ -250,6 +254,16 @@ EXPORT_SYMBOL(memnode_shift);
 EXPORT_SYMBOL(memnodemap);
 EXPORT_SYMBOL(node_data);
 
+static __init int numa_setup(char *opt)
+{
+if ( !strncmp(opt,"off",3) )
+numa_off = 1;
+if ( !strncmp(opt,"on",2) )
+numa_off = 0;
+
+return arch_numa_setup(opt);
+}
+
 static void dump_numa(unsigned char key)
 {
 s_time_t now = NOW();
diff --git a/xen/include/asm-arm/numa.h b/xen/include/asm-arm/numa.h
index a60c7eb..c1e8a7d 100644
--- a/xen/include/asm-arm/numa.h
+++ b/xen/include/asm-arm/numa.h
@@ -5,7 +5,14 @@ typedef u8 nodeid_t;
 
 #define NODES_SHIFT 2
 
-#ifndef CONFIG_NUMA
+#ifdef CONFIG_NUMA
+int arch_numa_setup(char *opt);
+#else
+static inline int arch_numa_setup(char *opt)
+{
+return 1;
+}
+
 /* Fake one node for now. See also node_online_map. */
 #define cpu_to_node(cpu) 0
 #define node_to_cpumask(node)   (cpu_online_map)
diff --git a/xen/include/asm-x86/numa.h b/xen/include/asm-x86/numa.h
index df1f7d5..659ff6a 100644
--- a/xen/include/asm-x86/numa.h
+++ b/xen/include/asm-x86/numa.h
@@ -22,7 +22,6 @@ extern nodeid_t pxm_to_node(unsigned int pxm);
 #define ZONE_ALIGN (1UL << (MAX_ORDER+PAGE_SHIFT))
 
 extern void numa_init_array(void);
-extern bool_t numa_off;
 
 extern int srat_disabled(void);
 extern void srat_detect_node(int cpu);
@@ -32,5 +31,6 @@ extern nodeid_t apicid_to_node[];
 void srat_parse_regions(u64 addr);
 extern u8 __node_distance(nodeid_t a, nodeid_t b);
 unsigned int arch_get_dma_bitsize(void);
+int arch_numa_setup(char *opt);
 
 #endif
diff --git a/xen/include/xen/numa.h b/xen/include/xen/numa.h
index 810f742..77c5cfd 100644
--- a/xen/include/xen/numa.h
+++ b/xen/include/xen/numa.h
@@ -18,6 +18,7 @@
   (((d)->vcpu != NULL && (d)->vcpu[0] != NULL) \
? vcpu_to_node((d)->vcpu[0]) : NUMA_NO_NODE)
 
+extern bool_t numa_off;
 struct node {
u64 start,end;
 };
-- 
2.7.4

[Xen-devel] [RFC PATCH v1 02/21] x86: NUMA: Refactor NUMA code

[vijay . kilari]

From: Vijaya Kumar K 

Move common generic NUMA code to xen/common/numa.c from
xen/arch/x86/numa.c. Also move generic code in header file
xen/include/asm-x86/numa.h to xen/include/xen/numa.h

This common code can be re-used later for ARM.

Signed-off-by: Vijaya Kumar K 
---
 xen/arch/x86/numa.c| 299 ---
 xen/common/Makefile|   1 +
 xen/common/numa.c  | 342 +
 xen/include/asm-x86/numa.h |  47 ---
 xen/include/xen/numa.h |  54 +++
 5 files changed, 397 insertions(+), 346 deletions(-)

diff --git a/xen/arch/x86/numa.c b/xen/arch/x86/numa.c
index 6f4d438..bc787e0 100644
--- a/xen/arch/x86/numa.c
+++ b/xen/arch/x86/numa.c
@@ -25,27 +25,12 @@ custom_param("numa", numa_setup);
 #define Dprintk(x...)
 #endif
 
-/* from proto.h */
-#define round_up(x,y) x)+(y))-1) & (~((y)-1)))
-
-struct node_data node_data[MAX_NUMNODES];
-
-/* Mapping from pdx to node id */
-int memnode_shift;
-static typeof(*memnodemap) _memnodemap[64];
-unsigned long memnodemapsize;
-u8 *memnodemap;
-
-nodeid_t cpu_to_node[NR_CPUS] __read_mostly = {
-[0 ... NR_CPUS-1] = NUMA_NO_NODE
-};
 /*
  * Keep BIOS's CPU2node information, should not be used for memory allocaion
  */
 nodeid_t apicid_to_node[MAX_LOCAL_APIC] = {
 [0 ... MAX_LOCAL_APIC-1] = NUMA_NO_NODE
 };
-cpumask_t node_to_cpumask[MAX_NUMNODES] __read_mostly;
 
 nodemask_t __read_mostly node_online_map = { { [0] = 1UL } };
 
@@ -57,134 +42,6 @@ int srat_disabled(void)
 return numa_off || acpi_numa < 0;
 }
 
-/*
- * Given a shift value, try to populate memnodemap[]
- * Returns :
- * 1 if OK
- * 0 if memnodmap[] too small (of shift too small)
- * -1 if node overlap or lost ram (shift too big)
- */
-static int __init populate_memnodemap(const struct node *nodes,
-  int numnodes, int shift, nodeid_t 
*nodeids)
-{
-unsigned long spdx, epdx;
-int i, res = -1;
-
-memset(memnodemap, NUMA_NO_NODE, memnodemapsize * sizeof(*memnodemap));
-for ( i = 0; i < numnodes; i++ )
-{
-spdx = paddr_to_pdx(nodes[i].start);
-epdx = paddr_to_pdx(nodes[i].end - 1) + 1;
-if ( spdx >= epdx )
-continue;
-if ( (epdx >> shift) >= memnodemapsize )
-return 0;
-do {
-if ( memnodemap[spdx >> shift] != NUMA_NO_NODE )
-return -1;
-
-if ( !nodeids )
-memnodemap[spdx >> shift] = i;
-else
-memnodemap[spdx >> shift] = nodeids[i];
-
-spdx += (1UL << shift);
-} while ( spdx < epdx );
-res = 1;
-}
-
-return res;
-}
-
-static int __init allocate_cachealigned_memnodemap(void)
-{
-unsigned long size = PFN_UP(memnodemapsize * sizeof(*memnodemap));
-unsigned long mfn = alloc_boot_pages(size, 1);
-
-if ( !mfn )
-{
-printk(KERN_ERR
-   "NUMA: Unable to allocate Memory to Node hash map\n");
-memnodemapsize = 0;
-return -1;
-}
-
-memnodemap = mfn_to_virt(mfn);
-mfn <<= PAGE_SHIFT;
-size <<= PAGE_SHIFT;
-printk(KERN_DEBUG "NUMA: Allocated memnodemap from %lx - %lx\n",
-   mfn, mfn + size);
-memnodemapsize = size / sizeof(*memnodemap);
-
-return 0;
-}
-
-/*
- * The LSB of all start and end addresses in the node map is the value of the
- * maximum possible shift.
- */
-static int __init extract_lsb_from_nodes(const struct node *nodes,
- int numnodes)
-{
-int i, nodes_used = 0;
-unsigned long spdx, epdx;
-unsigned long bitfield = 0, memtop = 0;
-
-for ( i = 0; i < numnodes; i++ )
-{
-spdx = paddr_to_pdx(nodes[i].start);
-epdx = paddr_to_pdx(nodes[i].end - 1) + 1;
-if ( spdx >= epdx )
-continue;
-bitfield |= spdx;
-nodes_used++;
-if ( epdx > memtop )
-memtop = epdx;
-}
-if ( nodes_used <= 1 )
-i = BITS_PER_LONG - 1;
-else
-i = find_first_bit(, sizeof(unsigned long)*8);
-memnodemapsize = (memtop >> i) + 1;
-return i;
-}
-
-int __init compute_hash_shift(struct node *nodes, int numnodes,
-  nodeid_t *nodeids)
-{
-int shift;
-
-shift = extract_lsb_from_nodes(nodes, numnodes);
-if ( memnodemapsize <= ARRAY_SIZE(_memnodemap) )
-memnodemap = _memnodemap;
-else if ( allocate_cachealigned_memnodemap() )
-return -1;
-printk(KERN_DEBUG "NUMA: Using %d for the hash shift.\n", shift);
-
-if ( populate_memnodemap(nodes, numnodes, shift, nodeids) != 1 )
-{
-printk(KERN_INFO "Your memory is not aligned you need to "
-   "rebuild your hypervisor with a bigger NODEMAPSIZE "
-   "shift=%d\n", shift);
-return -1;
-}
-
-return shift;
-}
-/* initialize NODE_DATA given nodeid and 

[Xen-devel] [RFC PATCH v1 00/21] ARM: Add Xen NUMA support

[vijay . kilari]

From: Vijaya Kumar K 

With this RFC patch series, NUMA support is added for arm platform.
Both DT and ACPI based NUMA support is added.
Only Xen is made aware of NUMA platform. Dom0 is awareness is not
added.

As part of this series, the code under x86 architecture is
reused by moving into common files.
New files xen/common/numa.c and xen/commom/srat.c files are
added which are common for both x86 and arm.

Patches 1 - 12 & 20 are for DT NUMA and 13 - 19 & 21 are for
ACPI NUMA.

DT NUMA: The following major changes are performed
 - Dropped numa-node-id information from Dom0 DT.
   So that Dom0 devices make allocation from node 0 for
   devmalloc requests.
 - Memory DT is not deleted by EFI. It is exposed to Xen
   to extract numa information.
 - On NUMA failure, Fallback to Non-NUMA booting.
   Assuming all the memory and CPU's are under node 0.
 - CONFIG_NUMA is introduced.

ACPI NUMA:
 - MADT is parsed before parsing SRAT table to extract
   CPU_ID to MPIDR mapping info. In Linux, while parsing SRAT
   table, MADT table is opened and extract MPIDR. However this
   approach is not working on Xen it allows only one table to
   be open at a time because when ACPI table is opened, Xen
   maps to single region. So opening ACPI tables recursively
   leads to overwriting of contents.
 - SRAT table is parsed for ACPI_SRAT_TYPE_GICC_AFFINITY to extract
   proximity info and MPIDR from CPU_ID to MPIDR mapping table.
 - SRAT table is parsed for ACPI_SRAT_TYPE_MEMORY_AFFINITY to extract
   memory proximity.
 - Re-use SLIT parsing of x86 for node distance information.
 - CONFIG_ACPI_NUMA is introduced

The node_distance() API is implemented separately for x86 and arm
as arm has DT and ACPI based distance information.

No changes are made to x86 implementation only code is refactored.
Hence only compilation tested for x86.

Code is shared at https://github.com/vijaykilari/xen-numa rfc_1

Note: Please use this patch series only for review.
For testing, patch to boot allocator is required. Which will
be sent outside this series.

Vijaya Kumar K (21):
  ARM: NUMA: Add existing ARM numa code under CONFIG_NUMA
  x86: NUMA: Refactor NUMA code
  NUMA: Move arch specific NUMA code as common
  NUMA: Refactor generic and arch specific code of numa_setup
  ARM: efi: Do not delete memory node from fdt
  ARM: NUMA: Parse CPU NUMA information
  ARM: NUMA: Parse memory NUMA information
  ARM: NUMA: Parse NUMA distance information
  ARM: NUMA: Add CPU NUMA support
  ARM: NUMA: Add memory NUMA support
  ARM: NUMA: Add fallback on NUMA failure
  ARM: NUMA: Do not expose numa info to DOM0
  ACPI: Refactor acpi SRAT and SLIT table handling code
  ACPI: Move srat_disabled to common code
  ARM: NUMA: Extract MPIDR from MADT table
  ARM: NUMA: Extract proximity from SRAT table
  ARM: NUMA: Extract memory proximity from SRAT table
  ARM: NUMA: update node_distance with ACPI support
  ARM: NUMA: Initialize ACPI NUMA
  ARM: NUMA: Enable CONFIG_NUMA config
  ARM: NUMA: Enable CONFIG_ACPI_NUMA config

 xen/arch/arm/Kconfig|   5 +
 xen/arch/arm/Makefile   |   3 +
 xen/arch/arm/acpi_numa.c| 257 +
 xen/arch/arm/bootfdt.c  |  21 +-
 xen/arch/arm/domain_build.c |   9 +
 xen/arch/arm/dt_numa.c  | 244 
 xen/arch/arm/efi/efi-boot.h |  25 --
 xen/arch/arm/numa.c | 249 
 xen/arch/arm/setup.c|   5 +
 xen/arch/arm/smpboot.c  |   3 +
 xen/arch/x86/domain_build.c |   1 +
 xen/arch/x86/numa.c | 318 +-
 xen/arch/x86/physdev.c  |   1 +
 xen/arch/x86/setup.c|   1 +
 xen/arch/x86/smpboot.c  |   1 +
 xen/arch/x86/srat.c | 183 +--
 xen/arch/x86/x86_64/mm.c|   1 +
 xen/common/Makefile |   2 +
 xen/common/numa.c   | 439 
 xen/common/srat.c   | 157 +
 xen/drivers/acpi/numa.c |  37 +++
 xen/drivers/acpi/osl.c  |   2 +
 xen/drivers/passthrough/vtd/iommu.c |   1 +
 xen/include/acpi/actbl1.h   |  17 +-
 xen/include/asm-arm/acpi.h  |   2 +
 xen/include/asm-arm/numa.h  |  41 
 xen/include/asm-x86/acpi.h  |   2 -
 xen/include/asm-x86/numa.h  |  53 +
 xen/include/xen/acpi.h  |  39 
 xen/include/xen/device_tree.h   |   7 +
 xen/include/xen/numa.h  |  61 -
 xen/include/xen/srat.h  |  15 ++
 32 files changed, 1620 insertions(+), 582 deletions(-)
 create mode 100644 xen/arch/arm/acpi_numa.c
 create mode 100644 xen/arch/arm/dt_numa.c
 create mode 100644 xen/arch/arm/numa.c
 create mode 100644 xen/common/numa.c
 create mode 100644 xen/common/srat.c
 create mode 100644 xen/include/xen/srat.h

-- 
2.7.4

Re: [Xen-devel] [PATCH 2/3] xen/privcmd: Add IOCTL_PRIVCMD_DM_OP

[Andrew Cooper]

On 09/02/17 15:50, Boris Ostrovsky wrote:
>
>
> On 02/09/2017 09:27 AM, Paul Durrant wrote:
>>> -Original Message-
>>> From: Paul Durrant [mailto:paul.durr...@citrix.com]
>>> Sent: 09 February 2017 14:18
>>> To: xen-de...@lists.xenproject.org; linux-ker...@vger.kernel.org
>>> Cc: Paul Durrant ; Boris Ostrovsky
>>> ; Juergen Gross 
>>> Subject: [PATCH 2/3] xen/privcmd: Add IOCTL_PRIVCMD_DM_OP
>>>
>>> Recently a new dm_op[1] hypercall was added to Xen to provide a
>>> mechanism
>>> for restricting device emulators (such as QEMU) to a limited set of
>>> hypervisor operations, and being able to audit those operations in the
>>> kernel of the domain in which they run.
>>>
>>> This patch adds IOCTL_PRIVCMD_DM_OP as gateway for
>>> __HYPERVISOR_dm_op,
>>> bouncing the callers buffers through kernel memory to allow the address
>>> ranges to be audited (and negating the need to bounce through locked
>>> memory in user-space).
>>
>> Actually, it strikes me (now that I've posted the patch) that I
>> should probably just mlock the user buffers rather than bouncing them
>> through kernel... Anyway, I'd still appreciate review on other
>> aspects of the patch.
>
>
> Are you suggesting that the caller (user) mlocks the buffers?

Doesn't libxc already use the hypercall buffer API for each of the buffers?

The kernel oughtn’t to need to do anything special to the user pointers
it has, other than call access_ok() on them.

~Andrew

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

Re: [Xen-devel] [PATCH 2/3] xen/privcmd: Add IOCTL_PRIVCMD_DM_OP

[Boris Ostrovsky]

On 02/09/2017 09:27 AM, Paul Durrant wrote:

-Original Message-
From: Paul Durrant [mailto:paul.durr...@citrix.com]
Sent: 09 February 2017 14:18
To: xen-de...@lists.xenproject.org; linux-ker...@vger.kernel.org
Cc: Paul Durrant ; Boris Ostrovsky
; Juergen Gross 
Subject: [PATCH 2/3] xen/privcmd: Add IOCTL_PRIVCMD_DM_OP

Recently a new dm_op[1] hypercall was added to Xen to provide a
mechanism
for restricting device emulators (such as QEMU) to a limited set of
hypervisor operations, and being able to audit those operations in the
kernel of the domain in which they run.

This patch adds IOCTL_PRIVCMD_DM_OP as gateway for
__HYPERVISOR_dm_op,
bouncing the callers buffers through kernel memory to allow the address
ranges to be audited (and negating the need to bounce through locked
memory in user-space).


Actually, it strikes me (now that I've posted the patch) that I should probably 
just mlock the user buffers rather than bouncing them through kernel... Anyway, 
I'd still appreciate review on other aspects of the patch.



Are you suggesting that the caller (user) mlocks the buffers?

-boris


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

Re: [Xen-devel] [PATCH v2 02/12] libxl: make some functions global to prepare splitting up libxl.c

[Wei Liu]

On Thu, Feb 09, 2017 at 12:42:41PM +0100, Juergen Gross wrote:
> On 09/02/17 12:36, Ian Jackson wrote:
> > Juergen Gross writes ("[PATCH v2 02/12] libxl: make some functions global 
> > to prepare splitting up libxl.c"):
> >> Splitting up libxl.c will require two functions to be globally visible.
> >> Add their prototypes to libxl_internal.h.
> > 
> > Thanks.  However,
> > 
> >> -static void xcinfo2xlinfo(libxl_ctx *ctx,
> >> -  const xc_domaininfo_t *xcinfo,
> >> -  libxl_dominfo *xlinfo)
> >> +void xcinfo2xlinfo(libxl_ctx *ctx,
> >> +   const xc_domaininfo_t *xcinfo,
> >> +   libxl_dominfo *xlinfo)
> > 
> > This function needs a libxl__ prefix adding to its name.
> 
> Aah, of course!
> 
> Will send V3 after waiting for more comments for a while...
> 

If there are no more significant comments, you can just fold in
everything and provide a branch. No need to repost.

> 
> Juergen
> 

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

Re: [Xen-devel] [PATCH 1/3] xen/privcmd: return -ENOSYS for unimplemented IOCTLs

[Paul Durrant]

> -Original Message-
> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
> Sent: 09 February 2017 15:26
> To: Jan Beulich ; Paul Durrant
> 
> Cc: xen-de...@lists.xenproject.org; Juergen Gross ;
> linux-ker...@vger.kernel.org
> Subject: Re: [Xen-devel] [PATCH 1/3] xen/privcmd: return -ENOSYS for
> unimplemented IOCTLs
> 
> 
> 
> On 02/09/2017 09:40 AM, Jan Beulich wrote:
>  On 09.02.17 at 15:17,  wrote:
> >> The code goes so far as to set the default return code to -ENOSYS but
> >> then overrides this to -EINVAL in the switch() statement's default
> >> case.
> >
> > If you already change this, isn't -ENOTTY the traditional way of
> > indicating unsupported ioctls?
> 
> In fact, a while ago David submitted a patch to do just that:
> 
> https://lists.xenproject.org/archives/html/xen-devel/2016-
> 08/msg00744.html
> 
> but it never went anywhere.
> 
> My question is whether anyone might be relying on current error return
> behavior.

I doubt it. It's certainly not a safe thing to do anyway. I'll change to 
-ENOTTY in v2 of the patch.

  Paul

> 
> 
> -boris

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

Re: [Xen-devel] [PATCH v2 04/10] xen: credit2: make accessor helpers inline functions instead of macros

[Dario Faggioli]

On Thu, 2017-02-09 at 07:36 -0700, Jan Beulich wrote:
> > > > On 09.02.17 at 14:58,  wrote:
> > +/* CPU to runq_id macro */
> > +static always_inline int c2r(const struct scheduler *ops, unsigned
> > cpu)
> > +{
> > +return (csched2_priv(ops))->runq_map[(cpu)];
> 
> Any reason for having the (pointless) parentheses here but not ...

> > +/* CPU to runqueue struct macro */
> > +static always_inline
> > +struct csched2_runqueue_data *c2rqd(const struct scheduler *ops,
> > unsigned cpu)
> > +{
> > +return _priv(ops)->rqd[c2r(ops, cpu)];
> 
> ... here?
> 
Nope. I'll get rid of them from above.

> Also I'm not sure whether the sched*.c files are an exception, but
> generally we don't use plain "unsigned" but always "unsigned int".
> 
Yes, in sched_credit.c and sched_credit2.c there are a few unsigned.
But I'm happy to use "unsigned int" for new code, such as here.

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

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

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

[Dario Faggioli]

On Thu, 2017-02-09 at 07:37 -0700, Jan Beulich wrote:
> > > > On 09.02.17 at 14:58,  wrote:
> > This series contains mostly style or cosmetic fixes for Credit2,
> > with the
> > following two exceptions:
> >  - 2 actual fixes for (not so severe) behavioral bugs (patches 5
> > and 6);
> 
> That's not really in line with patch 5 saying "No functional change
> intended."
>
Ah, yes, sorry, it is actually patches 7 and 8 that contains the fixes
now, as I added two patches at the beginning of the series.

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

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

Re: [Xen-devel] [PATCH 1/3] xen/privcmd: return -ENOSYS for unimplemented IOCTLs

[Boris Ostrovsky]

On 02/09/2017 09:40 AM, Jan Beulich wrote:

On 09.02.17 at 15:17,  wrote:

The code goes so far as to set the default return code to -ENOSYS but
then overrides this to -EINVAL in the switch() statement's default
case.


If you already change this, isn't -ENOTTY the traditional way of
indicating unsupported ioctls?


In fact, a while ago David submitted a patch to do just that:

https://lists.xenproject.org/archives/html/xen-devel/2016-08/msg00744.html

but it never went anywhere.

My question is whether anyone might be relying on current error return 
behavior.



-boris

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

Re: [Xen-devel] [PATCH] x86/vmx: fix build with clang 3.8.0

[Andrew Cooper]

On 09/02/17 14:20, Jan Beulich wrote:
 On 09.02.17 at 14:42,  wrote:
>> On 09/02/17 13:14, Jan Beulich wrote:
>> On 09.02.17 at 14:05,  wrote:
 On 09/02/17 13:01, Jan Beulich wrote:
 On 09.02.17 at 13:49,  wrote:
>> On 09/02/17 11:33, Roger Pau Monne wrote:
>>> --- a/xen/include/asm-x86/hvm/vmx/vmx.h
>>> +++ b/xen/include/asm-x86/hvm/vmx/vmx.h
>>> @@ -602,15 +602,16 @@ void vmx_pi_hooks_assign(struct domain *d);
>>>  void vmx_pi_hooks_deassign(struct domain *d);
>>>  
>>>  /* EPT violation qualifications definitions */
>>> -typedef union __transparent__ ept_qual {
>>> +typedef union ept_qual {
>> Please can we use
>>
>> typedef __transparent__ union ept_qual {
>>
>> which clang is happy with, and will help avoid problems such as the
>> cper_mce_record issue in c/s f8be76e2fe
> Would clang also be happy with it moved near the end of that
> line
>
> typedef union ept_qual __transparent__ {
>
> Having the attribute ahead of "union" is, I think, strictly speaking
> undefined behavior, as it then may as well apply to "typedef".
 No.  The result is

 /local/xen.git/xen/include/asm/hvm/vmx/vmx.h:605:40: error: expected
 identifier or '('
 typedef union ept_qual __transparent__ {
^
 /local/xen.git/xen/include/asm/hvm/vmx/vmx.h:614:3: error: type
 specifier missing, defaults to 'int' [-Werror,-Wimplicit-int]
 } ept_qual_t;
   ^~
 2 errors generated.

 In which case the original patch as proposed will probably do.  It turns
 out the presence of ept_qual_t does cause a compiler error if
 __transparent__ is missing from scope.
>>> But then the question is what the attribute applies to in the original
>>> version - the union, or just the typedef? The placement would
>>> suggest the latter, so I'd again be afraid of undefined behavior. Can
>>> it be moved ahead on that line?
>> You mean this?
>>
>> } __transparent__ ept_qual_t;
> Yes.
>
>> Clang is happy with that.
> Good.

Ok.  Fixed up and pushed.

~Andrew

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

Re: [Xen-devel] PML causing race condition during guest bootstorm and host crash on Broadwell cpu.

[Jan Beulich]

>>> On 08.02.17 at 16:32,  wrote:
 On 07.02.17 at 18:26,  wrote:
>> Facing a issue where bootstorm of guests leads to host crash. I debugged 
>> and found that that enabling PML  introduces a  race condition during 
>> guest teardown stage while disabling PML on a vcpu  and context switch 
>> happening for another vcpu.
>> 
>> Crash happens only on Broadwell processors as PML got introduced in this 
>> generation.
>> 
>> Here is my analysis:
>> 
>> Race condition:
>> 
>> vmcs.c vmx_vcpu_disable_pml (vcpu){ vmx_vmcs_enter() ; vm_write( 
>> disable_PML); vmx_vmcx_exit();)
>> 
>> In between I have a callpath from another pcpu executing context 
>> switch-> vmx_fpu_leave() and crash on vmwrite..
>> 
>>if ( !(v->arch.hvm_vmx.host_cr0 & X86_CR0_TS) )
>> {
>>   v->arch.hvm_vmx.host_cr0 |= X86_CR0_TS;
>>   __vmwrite(HOST_CR0, v->arch.hvm_vmx.host_cr0);  //crash
>>   }
> 
> So that's after current has changed already, so it's effectively
> dealing with a foreign VMCS, but it doesn't use vmx_vmcs_enter().
> The locking done in vmx_vmcs_try_enter() / vmx_vmcs_exit(),
> however, assumes that any user of a VMCS either owns the lock
> or has current as the owner of the VMCS. Of course such a call
> also can't be added here, as a vcpu on the context-switch-from
> path can't vcpu_pause() itself.
> 
> That taken together with the bypassing of __context_switch()
> when the incoming vCPU is the idle one (which means that via
> context_saved() ->is_running will be cleared before running
> ->ctxt_switch_from()), the vcpu_pause() invocation in
> vmx_vmcs_try_enter() may not have to wait at all if the call
> happens between the clearing of ->is_running and the
> eventual invocation of vmx_ctxt_switch_from().
> 
> If the above makes sense (which I'm not sure at all), the
> question is whether using this_cpu(curr_vcpu) instead of
> current in the VMCS enter/exit functions would help.

This won't help, as it won't make vcpu_pause() wait (which is the
core of the problem).

Jan


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

Re: [Xen-devel] IOMMU fault with IGD passthrough setup on XEN 4.8.0

[Jan Beulich]

>>> On 09.02.17 at 15:46,  wrote:
> BTW -- I think that fix should not be conflicting with your debug change, 
> right?

Yes - ideally you'd keep that one in place along with adding Roger's
patch.

Jan


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

[Xen-devel] qemu-upstream triggering OOM killer

[Jan Beulich]

Stefano,

the recent qemuu update results in the produced binary triggering the
OOM killer on the first system I tried the updated code on. Is there
anything known in this area? Are there any hints as to finding out
what is going wrong?

Thanks, Jan


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

[Xen-devel] [xen-4.7-testing test] 105661: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

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

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

version targeted for testing:
 xen  d31a0a29f5d7563b7361f7096316fd9e611d8673
baseline version:
 xen  dc309dd5d9153f7d75d6afcc20592d30b1a29c73

Last test of basis   104551  2017-01-21 20:41:38 Z   18 days
Testing same since   105661  2017-02-09 09:43:17 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Dario Faggioli 
  George Dunlap 
  Jan Beulich 
  Joao Martins 

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

Re: [Xen-devel] [PATCH 3/3] xen/privcmd: add IOCTL_PRIVCMD_RESTRICT

[Paul Durrant]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 09 February 2017 14:43
> To: Paul Durrant 
> Cc: xen-de...@lists.xenproject.org; Boris Ostrovsky
> ; Juergen Gross ; linux-
> ker...@vger.kernel.org
> Subject: Re: [Xen-devel] [PATCH 3/3] xen/privcmd: add
> IOCTL_PRIVCMD_RESTRICT
> 
> >>> On 09.02.17 at 15:17,  wrote:
> > @@ -666,6 +680,20 @@ static long privcmd_ioctl_dm_op(void __user
> *udata)
> > return rc;
> >  }
> >
> > +static long privcmd_ioctl_restrict(struct file *file, void __user *udata)
> > +{
> > +   struct privcmd_data *data = file->private_data;
> > +   domid_t dom;
> > +
> > +   if (copy_from_user(, udata, sizeof(dom)))
> > +   return -EFAULT;
> > +
> > +   /* Set restriction to the specified domain */
> > +   data->domid = dom;
> > +
> > +   return 0;
> > +}
> 
> Is it really intended for the caller to be able to undo this, by passing
> in DOMID_INVALID?

Good point. I was intending to fix that, but forgot.

  Paul

> 
> Jan


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

Re: [Xen-devel] IOMMU fault with IGD passthrough setup on XEN 4.8.0

[G.R.]

On Wed, Feb 8, 2017 at 11:59 PM, Jan Beulich  wrote:
 On 08.02.17 at 15:56,  wrote:
>> On Wed, Feb 8, 2017 at 10:29 PM, G.R.  
>> wrote:
>>> On Wed, Feb 8, 2017 at 8:44 PM, Jan Beulich  wrote:
>>> On 07.02.17 at 16:44,  wrote:
> On Mon, Feb 6, 2017 at 8:40 PM, Jan Beulich  wrote:
> On 05.02.17 at 06:51,  wrote:
>>> I finally get some spare time to collect the debug info.
>>
>> As I continue to be puzzled, best I could come up with is an
>> extension to the debug patch. Please use the attached one
>> in place of the earlier one, ideally on top of
>> https://lists.xenproject.org/archives/html/xen-devel/2017-02/msg00448.html
>> to reduce the overall amount of output (and help readability).
>
> Please see attached...

 So can you please give
 https://lists.xenproject.org/archives/html/xen-devel/2017-02/msg00602.html
 a try?

>>> Hmm, it does not help.
>>> But I'll need to double check if I was misleading you.
>>> I used attempt dom0pvh=1 but it was too unstable and I was only able
>>> to disable it through hacking grub.cfg through sshfs remotely.
>>> I forgot to touch the /etc/default/grub so the dom0pvh=1 may have come
>>> back when I was generating the log yesterday.
>>>
>>> Going to do it once again now.
>>
>> It appears that dom0pvh or not does not affect the debug output
>> without Roger's patch.
>> Anyway, attaching the output for you to double check.
>
> Well, if this indeed was with his patch in place, then I'm puzzled.
> I'd have to further extend the debugging patch then, but this may
> take a few days to get to.

Please hold-off and let me double check for you. I'm also confused by
my current situation right now.
I think should be running without Roger's fix with dom0pvh=0.
But I happen to see a lot of fault message right now, from dom0.
Maybe I forgot to reboot last night after reverting back.
I'll build with Roger's fix again and do the experiment once more.
BTW -- I think that fix should not be conflicting with your debug change, right?

Thanks,
Rui

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

Re: [Xen-devel] [RFC v2 3/6] xen/arm: Allow platform_hvc to handle guest SMC calls

[Edgar E. Iglesias]

On Wed, Feb 08, 2017 at 10:04:53PM +, Julien Grall wrote:
> Hi Tamas,
> 
> Can you please try to configure your e-mail client to use '>' rather than '
> '? It makes quite hard to read the e-mail.
> 
> On 08/02/2017 20:15, Tamas K Lengyel wrote:
> >
> >
> >On Wed, Feb 8, 2017 at 12:40 PM, Edgar E. Iglesias
> >> wrote:
> >On Wed, Feb 08, 2017 at 06:29:13PM +0100, Edgar E. Iglesias wrote:
> 
> >If platform_hvc() consumes an SMC, it's considered part of the Xen API.
> >Visible but not filterable by a monitor.
> >
> >
> >Platforms can then dictate which SMC calls are better handled within
> >Xen and
> >which ones can be exposed to dom0 user-space.
> >
> >In addition, there could be a hypercall to disable platform specific
> >handling
> >in Xen alltogether for a given guest. Then everything goes to dom0
> >user-space.
> >
> >It's a little messy...
> >
> >
> >
> >That is messy and I would not want any SMCs reaching the firmware when
> >the monitor application is in use. The monitor interface is disabled by
> >default and there aren't any known usecases where the SMC has to reach
> >both the firmware and the monitor application as well. So I think it is
> >safe to just make the two things mutually exclusive.
> 
> If you look at the SMC Calling Convention [1] both HVC and SMC are
> considered a conduit for service call to the secure firmware or hypervisor.
> It would be up to the hypervisor deciding what to do.
> 
> Lets imagine the guest is deciding to use HVC to access the secure firmware
> (AFAIU this patch series is adding that), are you going to monitor all the

Hi Julien,

My patch enables HVC and SMC to reach the platform specific calls. I didn't
connect PSCI over SMC though, I forgot about that but I definitely think
it makes sense to do so. Unmodified guest code would use SMC for everything
when running without a Hypervisor, so preferably the same would work on top
of Xen.

I'll fix that for v3.

Thanks,
Edgar




> HVCs (including hypercall)?
> 
> Similarly, non-modified baremetal app could use SMC to power on/off the vCPU
> (see PSCI spec). Will you emulate that in the monitor app?
> 
> So I think we need to be consistent across HVC and SMC call. And mutually
> exclusive does not sound right to me for HVC.
> 
> Cheers,
> 
> [1] 
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0028b/index.html
> 
> 
> -- 
> Julien Grall

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

Re: [Xen-devel] [PATCH 3/3] xen/privcmd: add IOCTL_PRIVCMD_RESTRICT

[Jan Beulich]

>>> On 09.02.17 at 15:17,  wrote:
> @@ -666,6 +680,20 @@ static long privcmd_ioctl_dm_op(void __user *udata)
>   return rc;
>  }
>  
> +static long privcmd_ioctl_restrict(struct file *file, void __user *udata)
> +{
> + struct privcmd_data *data = file->private_data;
> + domid_t dom;
> +
> + if (copy_from_user(, udata, sizeof(dom)))
> + return -EFAULT;
> +
> + /* Set restriction to the specified domain */
> + data->domid = dom;
> +
> + return 0;
> +}

Is it really intended for the caller to be able to undo this, by passing
in DOMID_INVALID?

Jan


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

Re: [Xen-devel] [PATCH 1/3] xen/privcmd: return -ENOSYS for unimplemented IOCTLs

[Jan Beulich]

>>> On 09.02.17 at 15:17,  wrote:
> The code goes so far as to set the default return code to -ENOSYS but
> then overrides this to -EINVAL in the switch() statement's default
> case.

If you already change this, isn't -ENOTTY the traditional way of
indicating unsupported ioctls?

Jan


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

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

[Jan Beulich]

>>> On 09.02.17 at 14:58,  wrote:
> This series contains mostly style or cosmetic fixes for Credit2, with the
> following two exceptions:
>  - 2 actual fixes for (not so severe) behavioral bugs (patches 5 and 6);

That's not really in line with patch 5 saying "No functional change
intended."

Jan


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

Re: [Xen-devel] [PATCH v2 04/10] xen: credit2: make accessor helpers inline functions instead of macros

[Jan Beulich]

>>> On 09.02.17 at 14:58,  wrote:
> +/* CPU to runq_id macro */
> +static always_inline int c2r(const struct scheduler *ops, unsigned cpu)
> +{
> +return (csched2_priv(ops))->runq_map[(cpu)];

Any reason for having the (pointless) parentheses here but not ...

> +}
> +
> +/* CPU to runqueue struct macro */
> +static always_inline
> +struct csched2_runqueue_data *c2rqd(const struct scheduler *ops, unsigned 
> cpu)
> +{
> +return _priv(ops)->rqd[c2r(ops, cpu)];

... here?

Also I'm not sure whether the sched*.c files are an exception, but
generally we don't use plain "unsigned" but always "unsigned int".

Jan


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

Re: [Xen-devel] [PATCH v2 04/10] xen: credit2: make accessor helpers inline functions instead of macros

[Jan Beulich]

>>> On 09.02.17 at 15:14,  wrote:
> On 09/02/17 13:58, Dario Faggioli wrote:
>> +struct csched2_private *csched2_priv(const struct scheduler *ops)
> 
> You should either return a const csched2_private *, or not take a const
> ops.  (Your choice.)
> 
> Despite being allowed by the C typesystem, it is type (ab)use as it
> changes the expectation of of what is meant by passing a const ops in
> the first place.

That's debatable. I'd rather see csched2_vcpu() and csched2_dom()
also be changed to match the above.

Jan


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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-xsm5 xen-buildfail REGR. vs. 105279
 build-amd64   5 xen-buildfail REGR. vs. 105279
 build-amd64-xsm   5 xen-buildfail REGR. vs. 105279
 build-i3865 xen-buildfail REGR. vs. 105279
 build-armhf   5 xen-buildfail REGR. vs. 105279
 build-armhf-xsm   5 xen-buildfail REGR. vs. 105279

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd   1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-pvh-intel  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-xsm 15 guest-start/debian.repeat fail REGR. vs. 105629

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

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

version targeted for testing:
 xen  9d5617cd89e7b285afa785b9a9d3495f4e2dffae
baseline version:
 xen  63e1d01b8fd948b3e0fa3beea494e407668aa43b

Last test of basis   105629  2017-02-08 06:54:04 Z1 days
Failing since105640  2017-02-08 14:19:37 Z0 days3 attempts
Testing same since   105659  2017-02-09 06:00:06 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Baptiste Daroussin 
  Fatih Acar 
  George Dunlap 
  Ian Jackson 

Re: [Xen-devel] [PATCH 2/3] xen/privcmd: Add IOCTL_PRIVCMD_DM_OP

[Paul Durrant]

> -Original Message-
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: 09 February 2017 14:18
> To: xen-de...@lists.xenproject.org; linux-ker...@vger.kernel.org
> Cc: Paul Durrant ; Boris Ostrovsky
> ; Juergen Gross 
> Subject: [PATCH 2/3] xen/privcmd: Add IOCTL_PRIVCMD_DM_OP
> 
> Recently a new dm_op[1] hypercall was added to Xen to provide a
> mechanism
> for restricting device emulators (such as QEMU) to a limited set of
> hypervisor operations, and being able to audit those operations in the
> kernel of the domain in which they run.
> 
> This patch adds IOCTL_PRIVCMD_DM_OP as gateway for
> __HYPERVISOR_dm_op,
> bouncing the callers buffers through kernel memory to allow the address
> ranges to be audited (and negating the need to bounce through locked
> memory in user-space).

Actually, it strikes me (now that I've posted the patch) that I should probably 
just mlock the user buffers rather than bouncing them through kernel... Anyway, 
I'd still appreciate review on other aspects of the patch.

  Paul

> 
> [1] http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=524a98c2
> 
> Signed-off-by: Paul Durrant 
> ---
> Cc: Boris Ostrovsky 
> Cc: Juergen Gross 
> ---
>  arch/x86/include/asm/xen/hypercall.h |   7 ++
>  drivers/xen/privcmd.c| 122
> +++
>  include/uapi/xen/privcmd.h   |  13 
>  include/xen/interface/hvm/dm_op.h|  32 +
>  include/xen/interface/xen.h  |   1 +
>  5 files changed, 175 insertions(+)
>  create mode 100644 include/xen/interface/hvm/dm_op.h
> 
> diff --git a/arch/x86/include/asm/xen/hypercall.h
> b/arch/x86/include/asm/xen/hypercall.h
> index a12a047..f6d20f6 100644
> --- a/arch/x86/include/asm/xen/hypercall.h
> +++ b/arch/x86/include/asm/xen/hypercall.h
> @@ -472,6 +472,13 @@ HYPERVISOR_xenpmu_op(unsigned int op, void
> *arg)
>   return _hypercall2(int, xenpmu_op, op, arg);
>  }
> 
> +static inline int
> +HYPERVISOR_dm_op(
> + domid_t dom, unsigned int nr_bufs, void *bufs)
> +{
> + return _hypercall3(int, dm_op, dom, nr_bufs, bufs);
> +}
> +
>  static inline void
>  MULTI_fpu_taskswitch(struct multicall_entry *mcl, int set)
>  {
> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> index b4e5e27..31c43f4 100644
> --- a/drivers/xen/privcmd.c
> +++ b/drivers/xen/privcmd.c
> @@ -32,6 +32,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -548,6 +549,123 @@ static long privcmd_ioctl_mmap_batch(void __user
> *udata, int version)
>   goto out;
>  }
> 
> +static int bounce_in(struct privcmd_dm_op_buf kbufs[], void *kptr[],
> + unsigned int num)
> +{
> + unsigned int i;
> + int rc = 0;
> +
> + for (i = 0; i < num; i++) {
> + kptr[i] = kzalloc(kbufs[i].size, GFP_KERNEL);
> + if (!kptr[i]) {
> + rc = -ENOMEM;
> + break;
> + }
> +
> + if (copy_from_user(kptr[i], kbufs[i].uptr, kbufs[i].size)) {
> + rc = -EFAULT;
> + break;
> + }
> + }
> +
> + return rc;
> +}
> +
> +static int bounce_out(struct privcmd_dm_op_buf kbufs[], void *kptr[],
> + unsigned int num)
> +{
> + unsigned int i;
> + int rc = 0;
> +
> + for (i = 0; i < num; i++)
> + if (copy_to_user(kbufs[i].uptr, kptr[i], kbufs[i].size))
> + rc = -EFAULT;
> +
> + return rc;
> +}
> +
> +static void free_kptr(void *kptr[], unsigned int num)
> +{
> + unsigned int i;
> +
> + if (!kptr)
> + return;
> +
> + for (i = 0; i < num; i++)
> + kfree(kptr[i]);
> +
> + kfree(kptr);
> +}
> +
> +static long privcmd_ioctl_dm_op(void __user *udata)
> +{
> + struct privcmd_dm_op kdata;
> + struct privcmd_dm_op_buf *kbufs;
> + void **kptr = NULL;
> + struct xen_dm_op_buf *xbufs = NULL;
> + unsigned int i;
> + long rc;
> +
> + if (copy_from_user(, udata, sizeof(kdata)))
> + return -EFAULT;
> +
> + if (kdata.num == 0)
> + return 0;
> +
> + /*
> +  * Set a tolerable upper limit on the number of buffers
> +  * without being overly restrictive, since we can't easily
> +  * predict what future dm_ops may require.
> +  */
> + if (kdata.num * sizeof(*kbufs) > PAGE_SIZE)
> + return -EINVAL;
> +
> + kbufs = kcalloc(kdata.num, sizeof(*kbufs), GFP_KERNEL);
> + if (!kbufs)
> + return -ENOMEM;
> +
> + if (copy_from_user(kbufs, kdata.ubufs,
> +sizeof(*kbufs) * kdata.num)) {
> + rc = -EFAULT;
> + goto out;
> + }
> +
> + kptr = kcalloc(kdata.num, sizeof(*kptr), GFP_KERNEL);
> + if (!kptr) {
> + rc = -ENOMEM;
> + goto out;
> +  

Re: [Xen-devel] [PATCH] x86/vmx: fix build with clang 3.8.0

[Jan Beulich]

>>> On 09.02.17 at 14:45,  wrote:
> On Thu, Feb 09, 2017 at 06:14:54AM -0700, Jan Beulich wrote:
>> >>> On 09.02.17 at 14:05,  wrote:
>> > On 09/02/17 13:01, Jan Beulich wrote:
>> > On 09.02.17 at 13:49,  wrote:
>> >>> On 09/02/17 11:33, Roger Pau Monne wrote:
>>  --- a/xen/include/asm-x86/hvm/vmx/vmx.h
>>  +++ b/xen/include/asm-x86/hvm/vmx/vmx.h
>>  @@ -602,15 +602,16 @@ void vmx_pi_hooks_assign(struct domain *d);
>>   void vmx_pi_hooks_deassign(struct domain *d);
>>   
>>   /* EPT violation qualifications definitions */
>>  -typedef union __transparent__ ept_qual {
>>  +typedef union ept_qual {
>> >>> Please can we use
>> >>>
>> >>> typedef __transparent__ union ept_qual {
>> >>>
>> >>> which clang is happy with, and will help avoid problems such as the
>> >>> cper_mce_record issue in c/s f8be76e2fe
>> >> Would clang also be happy with it moved near the end of that
>> >> line
>> >>
>> >> typedef union ept_qual __transparent__ {
>> >>
>> >> Having the attribute ahead of "union" is, I think, strictly speaking
>> >> undefined behavior, as it then may as well apply to "typedef".
>> > 
>> > No.  The result is
>> > 
>> > /local/xen.git/xen/include/asm/hvm/vmx/vmx.h:605:40: error: expected
>> > identifier or '('
>> > typedef union ept_qual __transparent__ {
>> >^
>> > /local/xen.git/xen/include/asm/hvm/vmx/vmx.h:614:3: error: type
>> > specifier missing, defaults to 'int' [-Werror,-Wimplicit-int]
>> > } ept_qual_t;
>> >   ^~
>> > 2 errors generated.
>> > 
>> > In which case the original patch as proposed will probably do.  It turns
>> > out the presence of ept_qual_t does cause a compiler error if
>> > __transparent__ is missing from scope.
>> 
>> But then the question is what the attribute applies to in the original
>> version - the union, or just the typedef? The placement would
>> suggest the latter, so I'd again be afraid of undefined behavior. Can
>> it be moved ahead on that line?
> 
> This is what the clang folks seem to test:
> 
> https://github.com/llvm-mirror/clang/blob/master/test/Sema/transparent-union.c
>  
> 
> So I would keep it with the current semantics, to stay in line with what 
> they do.

At the risk of tripping over a future gcc change in behavior? Better
not ...

Jan


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

Re: [Xen-devel] [PATCH] x86/vmx: fix build with clang 3.8.0

[Jan Beulich]

>>> On 09.02.17 at 14:42,  wrote:
> On 09/02/17 13:14, Jan Beulich wrote:
> On 09.02.17 at 14:05,  wrote:
>>> On 09/02/17 13:01, Jan Beulich wrote:
>>> On 09.02.17 at 13:49,  wrote:
> On 09/02/17 11:33, Roger Pau Monne wrote:
>> --- a/xen/include/asm-x86/hvm/vmx/vmx.h
>> +++ b/xen/include/asm-x86/hvm/vmx/vmx.h
>> @@ -602,15 +602,16 @@ void vmx_pi_hooks_assign(struct domain *d);
>>  void vmx_pi_hooks_deassign(struct domain *d);
>>  
>>  /* EPT violation qualifications definitions */
>> -typedef union __transparent__ ept_qual {
>> +typedef union ept_qual {
> Please can we use
>
> typedef __transparent__ union ept_qual {
>
> which clang is happy with, and will help avoid problems such as the
> cper_mce_record issue in c/s f8be76e2fe
 Would clang also be happy with it moved near the end of that
 line

 typedef union ept_qual __transparent__ {

 Having the attribute ahead of "union" is, I think, strictly speaking
 undefined behavior, as it then may as well apply to "typedef".
>>> No.  The result is
>>>
>>> /local/xen.git/xen/include/asm/hvm/vmx/vmx.h:605:40: error: expected
>>> identifier or '('
>>> typedef union ept_qual __transparent__ {
>>>^
>>> /local/xen.git/xen/include/asm/hvm/vmx/vmx.h:614:3: error: type
>>> specifier missing, defaults to 'int' [-Werror,-Wimplicit-int]
>>> } ept_qual_t;
>>>   ^~
>>> 2 errors generated.
>>>
>>> In which case the original patch as proposed will probably do.  It turns
>>> out the presence of ept_qual_t does cause a compiler error if
>>> __transparent__ is missing from scope.
>> But then the question is what the attribute applies to in the original
>> version - the union, or just the typedef? The placement would
>> suggest the latter, so I'd again be afraid of undefined behavior. Can
>> it be moved ahead on that line?
> 
> You mean this?
> 
> } __transparent__ ept_qual_t;

Yes.

> Clang is happy with that.

Good.

Jan


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

Re: [Xen-devel] [PATCH RESEND v17] xen/sndif: Add sound-device ABI

[Oleksandr Andrushchenko]

On 02/09/2017 02:48 PM, Konrad Rzeszutek Wilk wrote:

On February 9, 2017 3:46:10 AM EST, Oleksandr Andrushchenko 
 wrote:


On 02/08/2017 05:29 PM, Konrad Rzeszutek Wilk wrote:

. snip..

Reviewed-by: Konrad Rzeszutek Wilk 

Couple of issues I found in sndif while preparing displif for review:
1. missing string constants
+#define XENSND_FIELD_BE_VERSIONS"versions"
+#define XENSND_FIELD_FE_VERSION "version"

2. I would like to have one more part in the state diagrams section
which is currently missing: recovery flow for the case when
backend/frontend dies:

+ *--- Recovery flow
---
+ *
+ * In case of frontend unrecoverable errors backend handles that as
+ * if frontend goes into the XenbusStateClosed state.
+ *
+ * In case of backend unrecoverable errors frontend tries removing
+ * the emulated device. If this is possible at the moment of error,
+ * then frontend goes into the XenbusStateInitialising state and is
ready for
+ * new connection with backend. If the emulated device is still in use
and
+ * cannot be removed, then frontend goes into the
XenbusStateReconfiguring state
+ * until either the emulated device removed or backend initiates a new
+ * connection. On the emulated device removal frontend goes into the
+ * XenbusStateInitialising state.
+ *


Thanks, feel free to include this and my reviewed by tag.


Thank you

Thank you,
Oleksandr


Thanks!



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

[Xen-devel] [PATCH 1/3] xen/privcmd: return -ENOSYS for unimplemented IOCTLs

[Paul Durrant]

The code goes so far as to set the default return code to -ENOSYS but
then overrides this to -EINVAL in the switch() statement's default
case.

This patch removes this pointless and incorrect override.

Signed-off-by: Paul Durrant 
---
Cc: Boris Ostrovsky 
Cc: Juergen Gross 
---
 drivers/xen/privcmd.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 6e3306f..b4e5e27 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -572,7 +572,6 @@ static long privcmd_ioctl(struct file *file,
break;
 
default:
-   ret = -EINVAL;
break;
}
 
-- 
2.1.4


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

[Xen-devel] [PATCH 3/3] xen/privcmd: add IOCTL_PRIVCMD_RESTRICT

[Paul Durrant]

The purpose if this ioctl is to allow a user of privcmd to restrict its
operation such that it will no longer service arbitrary hypercalls via
IOCTL_PRIVCMD_HYPERCALL, and will check for a matching domid when
servicing IOCTL_PRIVCMD_DM_OP. The aim of this is to limit the attack
surface for a compromised device model.

Signed-off-by: Paul Durrant 
---
Cc: Boris Ostrovsky 
Cc: Juergen Gross 
---
 drivers/xen/privcmd.c  | 64 +++---
 include/uapi/xen/privcmd.h |  2 ++
 2 files changed, 62 insertions(+), 4 deletions(-)

diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 31c43f4..ef14ac8 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -44,16 +44,25 @@ MODULE_LICENSE("GPL");
 
 #define PRIV_VMA_LOCKED ((void *)1)
 
+struct privcmd_data {
+   domid_t domid;
+};
+
 static int privcmd_vma_range_is_mapped(
struct vm_area_struct *vma,
unsigned long addr,
unsigned long nr_pages);
 
-static long privcmd_ioctl_hypercall(void __user *udata)
+static long privcmd_ioctl_hypercall(struct file *file, void __user *udata)
 {
+   struct privcmd_data *data = file->private_data;
struct privcmd_hypercall hypercall;
long ret;
 
+   /* Disallow arbitrary hypercalls if restricted */
+   if (data->domid != DOMID_INVALID)
+   return -EPERM;
+
if (copy_from_user(, udata, sizeof(hypercall)))
return -EFAULT;
 
@@ -597,8 +606,9 @@ static void free_kptr(void *kptr[], unsigned int num)
kfree(kptr);
 }
 
-static long privcmd_ioctl_dm_op(void __user *udata)
+static long privcmd_ioctl_dm_op(struct file *file, void __user *udata)
 {
+   struct privcmd_data *data = file->private_data;
struct privcmd_dm_op kdata;
struct privcmd_dm_op_buf *kbufs;
void **kptr = NULL;
@@ -609,6 +619,10 @@ static long privcmd_ioctl_dm_op(void __user *udata)
if (copy_from_user(, udata, sizeof(kdata)))
return -EFAULT;
 
+   /* If restriction is in place, check the domid matches */
+   if (data->domid != DOMID_INVALID && data->domid != kdata.dom)
+   return -EPERM;
+
if (kdata.num == 0)
return 0;
 
@@ -666,6 +680,20 @@ static long privcmd_ioctl_dm_op(void __user *udata)
return rc;
 }
 
+static long privcmd_ioctl_restrict(struct file *file, void __user *udata)
+{
+   struct privcmd_data *data = file->private_data;
+   domid_t dom;
+
+   if (copy_from_user(, udata, sizeof(dom)))
+   return -EFAULT;
+
+   /* Set restriction to the specified domain */
+   data->domid = dom;
+
+   return 0;
+}
+
 static long privcmd_ioctl(struct file *file,
  unsigned int cmd, unsigned long data)
 {
@@ -674,7 +702,7 @@ static long privcmd_ioctl(struct file *file,
 
switch (cmd) {
case IOCTL_PRIVCMD_HYPERCALL:
-   ret = privcmd_ioctl_hypercall(udata);
+   ret = privcmd_ioctl_hypercall(file, udata);
break;
 
case IOCTL_PRIVCMD_MMAP:
@@ -690,7 +718,11 @@ static long privcmd_ioctl(struct file *file,
break;
 
case IOCTL_PRIVCMD_DM_OP:
-   ret = privcmd_ioctl_dm_op(udata);
+   ret = privcmd_ioctl_dm_op(file, udata);
+   break;
+
+   case IOCTL_PRIVCMD_RESTRICT:
+   ret = privcmd_ioctl_restrict(file, udata);
break;
 
default:
@@ -700,6 +732,28 @@ static long privcmd_ioctl(struct file *file,
return ret;
 }
 
+static int privcmd_open(struct inode *ino, struct file *file)
+{
+   struct privcmd_data *data = kzalloc(sizeof(*data), GFP_KERNEL);
+
+   if (!data)
+   return -ENOMEM;
+
+   /* DOMID_INVALID implies no restriction */
+   data->domid = DOMID_INVALID;
+
+   file->private_data = data;
+   return 0;
+}
+
+static int privcmd_release(struct inode *ino, struct file *file)
+{
+   struct privcmd_data *data = file->private_data;
+
+   kfree(data);
+   return 0;
+}
+
 static void privcmd_close(struct vm_area_struct *vma)
 {
struct page **pages = vma->vm_private_data;
@@ -768,6 +822,8 @@ static int privcmd_vma_range_is_mapped(
 const struct file_operations xen_privcmd_fops = {
.owner = THIS_MODULE,
.unlocked_ioctl = privcmd_ioctl,
+   .open = privcmd_open,
+   .release = privcmd_release,
.mmap = privcmd_mmap,
 };
 EXPORT_SYMBOL_GPL(xen_privcmd_fops);
diff --git a/include/uapi/xen/privcmd.h b/include/uapi/xen/privcmd.h
index f8c5d75..63ee95c 100644
--- a/include/uapi/xen/privcmd.h
+++ b/include/uapi/xen/privcmd.h
@@ -111,5 +111,7 @@ struct privcmd_dm_op {
_IOC(_IOC_NONE, 'P', 4, sizeof(struct privcmd_mmapbatch_v2))
 #define IOCTL_PRIVCMD_DM_OP\
_IOC(_IOC_NONE, 'P', 5, 

[Xen-devel] [PATCH 0/3] xen/privcmd: support for dm_op and restriction

[Paul Durrant]

This patch series follows on from my recent Xen series [1], to provide
support in privcmd for de-privileging of device emulators.

[1] https://lists.xen.org/archives/html/xen-devel/2017-01/msg02558.html

Paul Durrant (3):
  xen/privcmd: return -ENOSYS for unimplemented IOCTLs
  xen/privcmd: Add IOCTL_PRIVCMD_DM_OP
  xen/privcmd: add IOCTL_PRIVCMD_RESTRICT

 arch/x86/include/asm/xen/hypercall.h |   7 ++
 drivers/xen/privcmd.c| 183 ++-
 include/uapi/xen/privcmd.h   |  15 +++
 include/xen/interface/hvm/dm_op.h|  32 ++
 include/xen/interface/xen.h  |   1 +
 5 files changed, 235 insertions(+), 3 deletions(-)
 create mode 100644 include/xen/interface/hvm/dm_op.h

-- 
2.1.4


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