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

[Corneliu ZUZU]

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

Hi Corneliu,

On 13/07/2016 15:18, Corneliu ZUZU wrote:
Move duplicate macros between asm-arm/arm32/atomic.h and 
asm-arm/arm64/atomic.h

to asm-arm/atomic.h.


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


Regards,



Julien,

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

Could you be more specific on how I should modify that file?

Thanks,
Zuzu C.

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

[Xen-devel] [linux-3.18 test] 97278: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

Re: [Xen-devel] [PATCH 6/8] x86: xen: audit and remove any unnecessary uses of module.h

[Juergen Gross]

On 14/07/16 02:18, Paul Gortmaker wrote:
> Historically a lot of these existed because we did not have
> a distinction between what was modular code and what was providing
> support to modules via EXPORT_SYMBOL and friends.  That changed
> when we forked out support for the latter into the export.h file.
> 
> This means we should be able to reduce the usage of module.h
> in code that is obj-y Makefile or bool Kconfig.  The advantage
> in doing so is that module.h itself sources about 15 other headers;
> adding significantly to what we feed cpp, and it can obscure what
> headers we are effectively using.
> 
> Since module.h was the source for init.h (for __init) and for
> export.h (for EXPORT_SYMBOL) we consider each obj-y/bool instance
> for the presence of either and replace as needed.
> 
> Cc: Boris Ostrovsky 
> Cc: David Vrabel 
> Cc: Juergen Gross 
> Cc: Thomas Gleixner 
> Cc: Ingo Molnar 
> Cc: "H. Peter Anvin" 
> Cc: x...@kernel.org
> Cc: xen-de...@lists.xenproject.org
> Signed-off-by: Paul Gortmaker 

Acked-by: Juergen Gross 

Juergen

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

[Xen-devel] [PATCH v9 12/17] qapi: Change Netdev into a flat union

[Eric Blake]

This is a mostly-mechanical conversion that creates a new flat
union 'Netdev' QAPI type that covers all the branches of the
former 'NetClientOptions' simple union, where the branches are
now listed in a new 'NetClientDriver' enum rather than generated
from the simple union.  The existence of a flat union has no
change to the command line syntax accepted for new code, and
will make it possible for a future patch to switch the QMP
command to parse a boxed union for no change to valid QMP; but
it does have some ripple effect on the C code when dealing with
the new types.

While making the conversion, note that the 'NetLegacy' type
remains unchanged: it applies only to legacy command line options,
and will not be ported to QMP, so it should remain a wrapper
around a simple union; to avoid confusion, the type named
'NetClientOptions' is now gone, and we introduce 'NetLegacyOptions'
in its place.  Then, in the C code, we convert from NetLegacy to
Netdev as soon as possible, so that the bulk of the net stack
only has to deal with one QAPI type, not two.  Note that since
the old legacy code always rejected 'hubport', we can just omit
that branch from the new 'NetLegacyOptions' simple union.

Based on an idea originally by Zoltán Kővágó :
Message-Id: 
<01a527fbf1a5de880091f98cf011616a78ad.1441627176.git.dirty.ice...@gmail.com>
although the sed script in that patch no longer applies due to
other changes in the tree since then, and I also did some manual
cleanups (such as fixing whitespace to keep checkpatch happy).

Signed-off-by: Eric Blake 

---
v8: rewrite commit message, claim authorship, rebase to latest
v7: rebase to latest master
v6: rebase to latest master
---
 qapi-schema.json |  49 ++-
 include/net/net.h|   4 +-
 hw/arm/musicpal.c|   2 +-
 hw/core/qdev-properties-system.c |   2 +-
 hw/net/allwinner_emac.c  |   2 +-
 hw/net/cadence_gem.c |   2 +-
 hw/net/dp8393x.c |   2 +-
 hw/net/e1000.c   |   2 +-
 hw/net/e1000e.c  |   2 +-
 hw/net/eepro100.c|   2 +-
 hw/net/etraxfs_eth.c |   2 +-
 hw/net/fsl_etsec/etsec.c |   2 +-
 hw/net/imx_fec.c |   2 +-
 hw/net/lan9118.c |   2 +-
 hw/net/lance.c   |   2 +-
 hw/net/mcf_fec.c |   2 +-
 hw/net/milkymist-minimac2.c  |   2 +-
 hw/net/mipsnet.c |   2 +-
 hw/net/ne2000-isa.c  |   2 +-
 hw/net/ne2000.c  |   2 +-
 hw/net/opencores_eth.c   |   2 +-
 hw/net/pcnet-pci.c   |   2 +-
 hw/net/rocker/rocker_fp.c|   2 +-
 hw/net/rtl8139.c |   2 +-
 hw/net/smc91c111.c   |   2 +-
 hw/net/spapr_llan.c  |   2 +-
 hw/net/stellaris_enet.c  |   2 +-
 hw/net/vhost_net.c   |  20 +++---
 hw/net/virtio-net.c  |  10 +--
 hw/net/vmxnet3.c |   2 +-
 hw/net/xen_nic.c |   2 +-
 hw/net/xgmac.c   |   2 +-
 hw/net/xilinx_axienet.c  |   2 +-
 hw/net/xilinx_ethlite.c  |   2 +-
 hw/usb/dev-network.c |   2 +-
 monitor.c|  14 ++---
 net/dump.c   |   6 +-
 net/filter.c |   2 +-
 net/hub.c|  22 +++
 net/l2tpv3.c |   6 +-
 net/net.c| 133 +--
 net/netmap.c |   4 +-
 net/slirp.c  |   6 +-
 net/socket.c |   8 +--
 net/tap-win32.c  |   6 +-
 net/tap.c|  24 +++
 net/vde.c|   6 +-
 net/vhost-user.c |  20 +++---
 48 files changed, 230 insertions(+), 172 deletions(-)

diff --git a/qapi-schema.json b/qapi-schema.json
index d2d6506..5658723 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -2809,16 +2809,32 @@
 '*queues':'int' } }

 ##
-# @NetClientOptions
+# @NetClientDriver
 #
-# A discriminated record of network device traits.
+# Available netdev drivers.
+#
+# Since 2.7
+##
+{ 'enum': 'NetClientDriver',
+  'data': [ 'none', 'nic', 'user', 'tap', 'l2tpv3', 'socket', 'vde', 'dump',
+'bridge', 'hubport', 'netmap', 'vhost-user' ] }
+
+##
+# @Netdev
+#
+# Captures the configuration of a network device.
+#
+# @id: identifier for monitor commands.
+#
+# @type: Specify the driver used for interpreting remaining arguments.
 #
 # Since 1.2
 #
 # 'l2tpv3' - since 2.1
-#
 ##
-{ 'union': 'NetClientOptions',
+{ 'union': 'Netdev',
+  'base': { 'id': 'str', 'type': 'NetClientDriver' },
+  'discriminator': 'type',
   'data': {
 'none': 'NetdevNoneOptions',
 'nic':  'NetLegacyNicOptions',
@@ -2853,23 +2869,28 @@
 '*vlan': 'int32',
 '*id':   'str',
 '*name': 'str',
-'opts':  

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

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

Last test of basis96993  2016-07-11 01:58:23 Z3 days
Testing same since97275  2016-07-13 17:16:42 Z0 days1 attempts


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

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

[Xen-devel] [PATCH] apic: remove the unused field apic_id_mask

[Wei Jiangang]

The only user verify_local_APIC() had been removed by
commit 4399c03c6780 ("x86/apic: Remove verify_local_APIC()"),
so no need to keep it.

Signed-off-by: Wei Jiangang 
---
 arch/x86/include/asm/apic.h   | 1 -
 arch/x86/kernel/apic/apic_flat_64.c   | 2 --
 arch/x86/kernel/apic/apic_noop.c  | 1 -
 arch/x86/kernel/apic/apic_numachip.c  | 2 --
 arch/x86/kernel/apic/bigsmp_32.c  | 1 -
 arch/x86/kernel/apic/probe_32.c   | 1 -
 arch/x86/kernel/apic/x2apic_cluster.c | 1 -
 arch/x86/kernel/apic/x2apic_phys.c| 1 -
 arch/x86/kernel/apic/x2apic_uv_x.c| 1 -
 arch/x86/xen/apic.c   | 1 -
 10 files changed, 12 deletions(-)

diff --git a/arch/x86/include/asm/apic.h b/arch/x86/include/asm/apic.h
index bc27611fa58f..f5befd4945f2 100644
--- a/arch/x86/include/asm/apic.h
+++ b/arch/x86/include/asm/apic.h
@@ -300,7 +300,6 @@ struct apic {
 
unsigned int (*get_apic_id)(unsigned long x);
unsigned long (*set_apic_id)(unsigned int id);
-   unsigned long apic_id_mask;
 
int (*cpu_mask_to_apicid_and)(const struct cpumask *cpumask,
  const struct cpumask *andmask,
diff --git a/arch/x86/kernel/apic/apic_flat_64.c 
b/arch/x86/kernel/apic/apic_flat_64.c
index 76f89e2b245a..048747778d37 100644
--- a/arch/x86/kernel/apic/apic_flat_64.c
+++ b/arch/x86/kernel/apic/apic_flat_64.c
@@ -181,7 +181,6 @@ static struct apic apic_flat =  {
 
.get_apic_id= flat_get_apic_id,
.set_apic_id= set_apic_id,
-   .apic_id_mask   = 0xFFu << 24,
 
.cpu_mask_to_apicid_and = flat_cpu_mask_to_apicid_and,
 
@@ -278,7 +277,6 @@ static struct apic apic_physflat =  {
 
.get_apic_id= flat_get_apic_id,
.set_apic_id= set_apic_id,
-   .apic_id_mask   = 0xFFu << 24,
 
.cpu_mask_to_apicid_and = default_cpu_mask_to_apicid_and,
 
diff --git a/arch/x86/kernel/apic/apic_noop.c b/arch/x86/kernel/apic/apic_noop.c
index 13d19ed58514..2cebf59092d8 100644
--- a/arch/x86/kernel/apic/apic_noop.c
+++ b/arch/x86/kernel/apic/apic_noop.c
@@ -141,7 +141,6 @@ struct apic apic_noop = {
 
.get_apic_id= noop_get_apic_id,
.set_apic_id= NULL,
-   .apic_id_mask   = 0x0F << 24,
 
.cpu_mask_to_apicid_and = flat_cpu_mask_to_apicid_and,
 
diff --git a/arch/x86/kernel/apic/apic_numachip.c 
b/arch/x86/kernel/apic/apic_numachip.c
index ab5c2c685a3c..714d4fda0d52 100644
--- a/arch/x86/kernel/apic/apic_numachip.c
+++ b/arch/x86/kernel/apic/apic_numachip.c
@@ -269,7 +269,6 @@ static const struct apic apic_numachip1 __refconst = {
 
.get_apic_id= numachip1_get_apic_id,
.set_apic_id= numachip1_set_apic_id,
-   .apic_id_mask   = 0xffU << 24,
 
.cpu_mask_to_apicid_and = default_cpu_mask_to_apicid_and,
 
@@ -321,7 +320,6 @@ static const struct apic apic_numachip2 __refconst = {
 
.get_apic_id= numachip2_get_apic_id,
.set_apic_id= numachip2_set_apic_id,
-   .apic_id_mask   = 0xffU << 24,
 
.cpu_mask_to_apicid_and = default_cpu_mask_to_apicid_and,
 
diff --git a/arch/x86/kernel/apic/bigsmp_32.c b/arch/x86/kernel/apic/bigsmp_32.c
index cf9bd896c12d..06dbaa458bfe 100644
--- a/arch/x86/kernel/apic/bigsmp_32.c
+++ b/arch/x86/kernel/apic/bigsmp_32.c
@@ -171,7 +171,6 @@ static struct apic apic_bigsmp = {
 
.get_apic_id= bigsmp_get_apic_id,
.set_apic_id= NULL,
-   .apic_id_mask   = 0xFF << 24,
 
.cpu_mask_to_apicid_and = default_cpu_mask_to_apicid_and,
 
diff --git a/arch/x86/kernel/apic/probe_32.c b/arch/x86/kernel/apic/probe_32.c
index f316e34abb42..93edfa01b408 100644
--- a/arch/x86/kernel/apic/probe_32.c
+++ b/arch/x86/kernel/apic/probe_32.c
@@ -101,7 +101,6 @@ static struct apic apic_default = {
 
.get_apic_id= default_get_apic_id,
.set_apic_id= NULL,
-   .apic_id_mask   = 0x0F << 24,
 
.cpu_mask_to_apicid_and = flat_cpu_mask_to_apicid_and,
 
diff --git a/arch/x86/kernel/apic/x2apic_cluster.c 
b/arch/x86/kernel/apic/x2apic_cluster.c
index aca8b75c1552..24170d0809ba 100644
--- a/arch/x86/kernel/apic/x2apic_cluster.c
+++ b/arch/x86/kernel/apic/x2apic_cluster.c
@@ -270,7 +270,6 @@ static struct apic apic_x2apic_cluster = {
 
.get_apic_id= x2apic_get_apic_id,
.set_apic_id= x2apic_set_apic_id,
-   .apic_id_mask   = 0xu,
 
.cpu_mask_to_apicid_and = x2apic_cpu_mask_to_apicid_and,
 
diff --git a/arch/x86/kernel/apic/x2apic_phys.c 

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

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

version targeted for testing:
 seabios  54e3a88609da074aaae2f04e592026ebf82169dc
baseline version:
 seabios  13213a252286372efa5f72b4119faafd5dff5db1

Last test of basis96767  2016-07-07 15:43:40 Z6 days
Testing same since97272  2016-07-13 13:44:49 Z0 days1 attempts


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

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



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

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

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

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


Pushing revision :

+ branch=seabios
+ revision=54e3a88609da074aaae2f04e592026ebf82169dc
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push seabios 
54e3a88609da074aaae2f04e592026ebf82169dc
+ branch=seabios
+ revision=54e3a88609da074aaae2f04e592026ebf82169dc
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=seabios
+ xenbranch=xen-unstable
+ '[' xseabios = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ 

[Xen-devel] [PATCH 6/8] x86: xen: audit and remove any unnecessary uses of module.h

[Paul Gortmaker]

Historically a lot of these existed because we did not have
a distinction between what was modular code and what was providing
support to modules via EXPORT_SYMBOL and friends.  That changed
when we forked out support for the latter into the export.h file.

This means we should be able to reduce the usage of module.h
in code that is obj-y Makefile or bool Kconfig.  The advantage
in doing so is that module.h itself sources about 15 other headers;
adding significantly to what we feed cpp, and it can obscure what
headers we are effectively using.

Since module.h was the source for init.h (for __init) and for
export.h (for EXPORT_SYMBOL) we consider each obj-y/bool instance
for the presence of either and replace as needed.

Cc: Boris Ostrovsky 
Cc: David Vrabel 
Cc: Juergen Gross 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: x...@kernel.org
Cc: xen-de...@lists.xenproject.org
Signed-off-by: Paul Gortmaker 
---
 arch/x86/xen/debugfs.c | 1 -
 arch/x86/xen/enlighten.c   | 2 +-
 arch/x86/xen/mmu.c | 3 ++-
 arch/x86/xen/p2m.c | 2 +-
 arch/x86/xen/platform-pci-unplug.c | 2 +-
 arch/x86/xen/setup.c   | 2 +-
 6 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/x86/xen/debugfs.c b/arch/x86/xen/debugfs.c
index c8377fb26cdf..1daff5545c0a 100644
--- a/arch/x86/xen/debugfs.c
+++ b/arch/x86/xen/debugfs.c
@@ -1,7 +1,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include "debugfs.h"
 
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 575cea4bab94..88845bb50b7b 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -23,7 +23,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 67433714b791..7d5afdb417cc 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -43,7 +43,8 @@
 #include 
 #include 
 #include 
-#include 
+#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index dd2a49a8aacc..37129db76d33 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -60,7 +60,7 @@
  */
 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/xen/platform-pci-unplug.c 
b/arch/x86/xen/platform-pci-unplug.c
index 9586ff32810c..d37a0c7f82cb 100644
--- a/arch/x86/xen/platform-pci-unplug.c
+++ b/arch/x86/xen/platform-pci-unplug.c
@@ -21,7 +21,7 @@
 
 #include 
 #include 
-#include 
+#include 
 
 #include 
 #include "xen-ops.h"
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index e345891450c3..176425233e4d 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -4,7 +4,7 @@
  * Jeremy Fitzhardinge , XenSource Inc, 2007
  */
 
-#include 
+#include 
 #include 
 #include 
 #include 
-- 
2.8.4


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

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

[osstest service owner]

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

Regressions :-(

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

version targeted for testing:
 ovmf 31441f298365dd182a7a672f1b40fbdb6115c12f
baseline version:
 ovmf dc99315b8732b6e3032d01319d3f534d440b43d0

Last test of basis94748  2016-05-24 22:43:25 Z   50 days
Failing since 94750  2016-05-25 03:43:08 Z   49 days  108 attempts
Testing same since97273  2016-07-13 13:44:52 Z0 days1 attempts


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

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



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

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

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

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


Not pushing.

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

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

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

[Boris Ostrovsky]

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

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


Can we force switch to idle (i.e. a non-64b PV guest) when we know
it would be useful for mapping/scrubbing? The cost of TLB flush (if that
was the reason) may be small compared to advantages brought by
fast mapping during scrubbing.


-boris


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

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

[Andrew Cooper]

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

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

Being free is not relevant.  It depends whether current is a 64bit PV
guest or not.  Even in the idle loop, we don't context switch away from
current's pagetables.

Realistically, you must at all times use map_domain_page() (or an
alternative thereabouts), as the 5TB limit with 64bit PV guests turns
into a 3.5TB limit depending on CONFIG_BIGMEM.

>
>
>  Do I need to account for the PDX hole?
 Jan is probably the best person to ask about this, but I am failure sure
 there are lurking dragons here.

 PDX compression is used to reduce the size of the frametable when there
 are large unused ranges of mfns.  Without paying attention to the PDX
 shift, you don't know where the discontinuities lie.

 However, because the PDX shift is an aligned power of two, there are
 likely to be struct page_info*'s in the frame_table which don't point at
 real RAM, and won't have a virtual mapping even in the directmap.
>>> So I would be OK with finding which mfn of my range points to beginning
>>> of the hole and break the mfn range into two sections --- one below the
>>> hole and one above. With hope that both ranges can be mapped
>>> contiguously --- something that I don't know whether is true.
>> If you have a struct page_info * in your hand, and know from the E820
>> where the next non RAM boundary is, I think you should be safe to clear
>> memory over a contiguous range of the directmap.  There shouldn't be any
>> discontinuities over that range.
> OK, I'll look at this, thanks.
>
>
>> Be aware of memory_guard() though which does shoot holes in the
>> directmap.  However, only allocated pages should be guarded, so you
>> should never be in the position of scrubbing pages with a missing
>> mapping in the directmap.  For RAM above the 5TB boundary,
>> map_domain_page() will DTRT, but we might want to see about making a
>> variant which can make mappings spanning more than 4k.
> Maybe have it at least attempt to map a larger range, i.e. not try to
> cover all corner cases. Something like map_domain_page_fast(order).

map_domain_page() is fast if it can use the directmap.  (However, it
doesn't on a debug build to test the highmem logic.)

I expect the exceedingly common case for RAM above the 5TB (or 3.5TB)
boundary will be for it to already align on a 1GB boundary, at which
point 2M or 1G superpages will work just fine for a temporary mapping.

~Andrew

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

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

[Michael Turquette]

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

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

Regards,
Mike

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

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

[Boris Ostrovsky]

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

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

 and then

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


 Would it be valid to this?
>>> In principle, yes.  The frame_table is in order.
>>>
>>> However, mfn_to_virt() will blow up for RAM above the 5TB boundary.  You
>>> need to map_domain_page() to get a mapping.
>> Right, but that would mean going page-by-page, which I want to avoid.
>>
>> Now, DIRECTMAP_SIZE is ~128TB (if my math is correct) --- doesn't it
>> imply that it maps this big a range contiguously (modulo PDX hole)?
> Your maths is correct, and yet you will end up with problems if you
> trust it.
>
> That is the magic mode for the idle and monitor pagetables.  In the
> context of a 64bit PV guest, the cutoff is at 5TB, at which point you
> venture into the virtual address space reserved for guest kernel use. 
> (It is rather depressing that the 64bit PV guest ABI is the factor
> limiting Xen's maximum RAM usage.)

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


>
  Do I need to account for the PDX hole?
>>> Jan is probably the best person to ask about this, but I am failure sure
>>> there are lurking dragons here.
>>>
>>> PDX compression is used to reduce the size of the frametable when there
>>> are large unused ranges of mfns.  Without paying attention to the PDX
>>> shift, you don't know where the discontinuities lie.
>>>
>>> However, because the PDX shift is an aligned power of two, there are
>>> likely to be struct page_info*'s in the frame_table which don't point at
>>> real RAM, and won't have a virtual mapping even in the directmap.
>> So I would be OK with finding which mfn of my range points to beginning
>> of the hole and break the mfn range into two sections --- one below the
>> hole and one above. With hope that both ranges can be mapped
>> contiguously --- something that I don't know whether is true.
> If you have a struct page_info * in your hand, and know from the E820
> where the next non RAM boundary is, I think you should be safe to clear
> memory over a contiguous range of the directmap.  There shouldn't be any
> discontinuities over that range.

OK, I'll look at this, thanks.


>
> Be aware of memory_guard() though which does shoot holes in the
> directmap.  However, only allocated pages should be guarded, so you
> should never be in the position of scrubbing pages with a missing
> mapping in the directmap.  For RAM above the 5TB boundary,
> map_domain_page() will DTRT, but we might want to see about making a
> variant which can make mappings spanning more than 4k.

Maybe have it at least attempt to map a larger range, i.e. not try to
cover all corner cases. Something like map_domain_page_fast(order).


-boris

>
> (You probably want someone else to sanity check my logic here.)
>
> ~Andrew
>
> ___
> 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] Converting heap page_infos to contiguous virtual

[Andrew Cooper]

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

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

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

>>>  Do I need to account for the PDX hole?
>> Jan is probably the best person to ask about this, but I am failure sure
>> there are lurking dragons here.
>>
>> PDX compression is used to reduce the size of the frametable when there
>> are large unused ranges of mfns.  Without paying attention to the PDX
>> shift, you don't know where the discontinuities lie.
>>
>> However, because the PDX shift is an aligned power of two, there are
>> likely to be struct page_info*'s in the frame_table which don't point at
>> real RAM, and won't have a virtual mapping even in the directmap.
> So I would be OK with finding which mfn of my range points to beginning
> of the hole and break the mfn range into two sections --- one below the
> hole and one above. With hope that both ranges can be mapped
> contiguously --- something that I don't know whether is true.

If you have a struct page_info * in your hand, and know from the E820
where the next non RAM boundary is, I think you should be safe to clear
memory over a contiguous range of the directmap.  There shouldn't be any
discontinuities over that range.

Be aware of memory_guard() though which does shoot holes in the
directmap.  However, only allocated pages should be guarded, so you
should never be in the position of scrubbing pages with a missing
mapping in the directmap.  For RAM above the 5TB boundary,
map_domain_page() will DTRT, but we might want to see about making a
variant which can make mappings spanning more than 4k.

(You probably want someone else to sanity check my logic here.)

~Andrew

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  a07e920bbffc5cd64c8e4902b9fbca746bb81aff
baseline version:
 xen  ea210c52abb6458e39f5365f7f2c3abb9c191c47

Last test of basis97274  2016-07-13 15:02:31 Z0 days
Testing same since97276  2016-07-13 18:01:21 Z0 days1 attempts


People who touched revisions under test:
  Julien Grall 
  Stefano Stabellini 

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



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

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

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

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


Pushing revision :

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

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

[Boris Ostrovsky]

On 07/13/2016 04:17 PM, Boris Ostrovsky wrote:
> On 07/13/2016 04:02 PM, Andrew Cooper wrote:
>> On 13/07/16 20:44, Boris Ostrovsky wrote:
>>> I would like to clear a bunch of Xen heap pages at once (i.e. not
>>> page-by-page).
>>>
>>> Greatly simplifying things, let's say I grab (in common/page_alloc.c)
>>> pg = page_list_remove_head((node, zone, order)
>>>
>>> and then
>>>
>>> mfn_t mfn =
>>> _mfn(page_to_mfn(pg));
>>> char *va = mfn_to_virt(mfn_x(mfn));
>>> memset(va, 0, 4096 * (1 << order));
>>>
>>>
>>> Would it be valid to this?
>> In principle, yes.  The frame_table is in order.
>>
>> However, mfn_to_virt() will blow up for RAM above the 5TB boundary.  You
>> need to map_domain_page() to get a mapping.
> Right, but that would mean going page-by-page, which I want to avoid.
>
> Now, DIRECTMAP_SIZE is ~128TB (if my math is correct) --- doesn't it
> imply that it maps this big a range contiguously (modulo PDX hole)?
>
>>>  Do I need to account for the PDX hole?
>> Jan is probably the best person to ask about this, but I am failure sure
>> there are lurking dragons here.
>>
>> PDX compression is used to reduce the size of the frametable when there
>> are large unused ranges of mfns.  Without paying attention to the PDX
>> shift, you don't know where the discontinuities lie.
>>
>> However, because the PDX shift is an aligned power of two, there are
>> likely to be struct page_info*'s in the frame_table which don't point at
>> real RAM, and won't have a virtual mapping even in the directmap.
> So I would be OK with finding which mfn of my range points to beginning
> of the hole and break the mfn range into two sections --- one below the
> hole and one above. With hope that both ranges can be mapped
> contiguously --- something that I don't know whether is true.


In fact, I am OK with breaking the range into many chunks. My goal is to
be able to map something like a few megabytes (maybe few tens of
megabytes at most) contiguously.

-boris


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

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

[Corneliu ZUZU]

On 7/13/2016 10:49 PM, Andrew Cooper wrote:

On 13/07/16 20:33, Corneliu ZUZU wrote:

On 7/13/2016 10:01 PM, Stefano Stabellini wrote:

On Wed, 13 Jul 2016, Corneliu ZUZU wrote:

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

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

Signed-off-by: Corneliu ZUZU 
Suggested-by: Andrew Cooper 
Reviewed-by: Andrew Cooper 
---
Changed since v1:
* removed comments that were duplicate between asm-x86/atomic.h and
  xen/atomic.h
* remove outdated comment ("NB. [...]")
* add atomic_cmpxchg doc-comment
* don't use yoda condition
---
   xen/include/asm-arm/atomic.h |  45 
   xen/include/asm-x86/atomic.h | 103 +-
   xen/include/xen/atomic.h | 171
+++
   3 files changed, 202 insertions(+), 117 deletions(-)
   create mode 100644 xen/include/xen/atomic.h

diff --git a/xen/include/asm-arm/atomic.h
b/xen/include/asm-arm/atomic.h
index e8f7340..01af43b 100644
--- a/xen/include/asm-arm/atomic.h
+++ b/xen/include/asm-arm/atomic.h
@@ -2,6 +2,7 @@
   #define __ARCH_ARM_ATOMIC__
 #include 
+#include 
   #include 
   #include 
   @@ -95,15 +96,6 @@ void __bad_atomic_size(void);
   default: __bad_atomic_size();
break;\
  
}   \

   })
-
-/*
- * NB. I've pushed the volatile qualifier into the operations. This
allows
- * fast accessors such as _atomic_read() and _atomic_set() which
don't give
- * the compiler a fit.
- */
-typedef struct { int counter; } atomic_t;
-
-#define ATOMIC_INIT(i) { (i) }
 /*
* On ARM, ordinary assignment (str instruction) doesn't clear the
local
@@ -141,12 +133,35 @@ static inline void _atomic_set(atomic_t *v,
int i)
   #define atomic_inc_return(v)(atomic_add_return(1, v))
   #define atomic_dec_return(v)(atomic_sub_return(1, v))

What about atomic_inc_return and atomic_dec_return? Doesn't it make
sense to do this for all of them, since we are at it? I believe there
are also a couple more which are #define'd.

Those don't seem to be implemented for X86 and neither are they
referred from common code (probably because they really aren't defined
for X86).

Apologies - this is definitely turning into the rats nest I warned you
it might.

As far as I am concerned, I only think it is important to have the
static inline prototypes for the versions which are actually common
between architectures.  Those are the ones we don't want to break
accidentally.

However, for the helpers which are not common, having them consistently
static inline would be a distinct improvement over mixed
inline/defines.  (static inline functions are superior to macros in many
ways.)

~Andrew



Absolutely no problem! The rats nest you imagined before this series was 
a different one :P . This really doesn't seem like it would require much 
effort.
What I could also try to do is to actually implement them on X86 as 
well. Would that be preferable?
I think the complete functions that are missing there are: 
atomic_sub_return, atomic_{inc,dec}_return, atomic_xchg, 
__atomic_add_unless. Please confirm this list.


As for how I'd implement them:

atomic_sub_return() - would "return arch_fetch_and_add(>counter, 
-i) - i;" - similarly to what atomic_add_return() does - do?


atomic_{inc,dec}_return() - would "return 
atomic_{add,sub}_return(1, v)" respectively as on ARM do?


atomic_xchg() - since xchg() is also available on X86, would 
"return xchg(&((v)->counter), new);" as on ARM do?
   Stefano, Julien: note that I'd have to 
implement this for ARM64, so, since xchg is -also- available on ARM64, 
would the above implementation also do in that case?


__atomic_add_unless() - again, everything this depends on in the 
ARM64 version is already available on X86 too; would it also be advised 
to rename it to atomic_add_unless()?
   Why the built-in leading 
underscores '__'? Is this function used anywhere?


Thanks,
Zuzu C.

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

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

[Konrad Rzeszutek Wilk]

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

ld -mi386pep --subsystem=10 --image-base=0x82d08000 --stack=0,0 
--heap=0,0 --strip-debug --section-alignment=0x20 --file-alignment=0x20 
--major-image-version=4 --minor-image-version=8 --major-os-version=2 
--minor-os-version=0 --major-subsystem-version=2 --minor-subsystem-version=0 -T 
efi.lds -N prelink-efi.o efi/relocs-dummy.o 
/home/konrad/xen/xen/common/symbols-dummy.o -o 
/home/konrad/xen/xen/.xen.efi.0x82d08000.0 &&   ld -mi386pep 
--subsystem=10 --image-base=0x82d0c000 --stack=0,0 --heap=0,0 
--strip-debug --section-alignment=0x20 --file-alignment=0x20 
--major-image-version=4 --minor-image-version=8 --major-os-version=2 
--minor-os-version=0 --major-subsystem-version=2 --minor-subsystem-version=0 -T 
efi.lds -N prelink-efi.o efi/relocs-dummy.o 
/home/konrad/xen/xen/common/symbols-dummy.o -o 
/home/konrad/xen/xen/.xen.efi.0x82d0c000.0 && :
ld: Xen image overlaps stubs area
prelink-efi.o: In function `__high_start':
/home/konrad/xen/xen/arch/x86/boot/x86_64.S:6:(.text+0x23): relocation 
truncated to fit: R_X86_64_PC32 against `gdt_descr'
/home/konrad/xen/xen/arch/x86/boot/x86_64.S:18:(.text+0x43): relocation 
truncated to fit: R_X86_64_PC32 against `stack_start'
/home/konrad/xen/xen/arch/x86/boot/x86_64.S:35:(.text+0x6a): relocation 
truncated to fit: R_X86_64_PC32 against `.data'
/home/konrad/xen/xen/arch/x86/boot/x86_64.S:36:(.text+0x6f): relocation 
truncated to fit: R_X86_64_PC32 against `__start_xen'
.. and more.

Re-running it with -M on a build (the giant ld -mi386pep..) with the 
-ffunction-sections and without it
makes it obvious what the problem is:

With: -ffunction-sections -fdata-sections:

.data   0x82d291e18000   0xf8 prelink-efi.o
0x82d291e18006gdt_descr

*(.text)
.text   0x82d0c010 0x27e4 prelink-efi.o
0x82d0c010start
0x82d0c0100020__high_start

distance is 0x1D1D18000

Normal build:

.data   0x82d0c0818000 0x12e8 prelink-efi.o
0x82d0c0818006gdt_descr

.text   0x82d0c010   0x14b000
0x82d0c010_stext = .
 *(.text)
 .text  0x82d0c010   0x149243 prelink-efi.o
0x82d0c010start
0x82d0c0100020__high_start

where the distance is 0x718000

The 0x1D1D18000 is most certainly over the 32-bit limit and leads to the 
truncation.

Now if we look more closely at the map we can see that each
.text section is:

.text.domain_kill
0x82d0cd20  0x140
 .text.domain_kill
0x82d0cd20  0x139 prelink-efi.o
0x82d0cd20domain_kill

.text.domain_create
0x82d0cd40  0x520
 .text.domain_create
0x82d0cd40  0x502 prelink-efi.o
0x82d0cd40domain_create

.. seperated by 2MB!

A bit of grepping showed that the issue is with:

 --section-alignment=0x20

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

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

diff --git a/livepatch-build b/livepatch-build
index 8dc8889..6ccadd6 100755
--- a/livepatch-build
+++ b/livepatch-build
@@ -86,8 +86,10 @@ function build_special()
 # Build with special GCC flags
 cd "${SRCDIR}/xen" || die
 sed -i 's/CFLAGS += -nostdinc/CFLAGS += -nostdinc -ffunction-sections 
-fdata-sections/' Rules.mk
+sed -i 's/--section-alignment=0x20/--section-alignment=0x1000/' 
arch/x86/Makefile
 make "-j$CPUS" debug="$XEN_DEBUG" &> "${OUTPUT}/build_${name}_compile.log" 
|| die
 sed -i 's/CFLAGS += -nostdinc -ffunction-sections -fdata-sections/CFLAGS 
+= -nostdinc/' Rules.mk
+sed -i 's/--section-alignment=0x1000/--section-alignment=0x20/' 
arch/x86/Makefile
 
 unset LIVEPATCH_BUILD_DIR
 unset LIVEPATCH_CAPTURE_DIR
-- 
2.5.5


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

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

[Andrew Cooper]

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

In principle, yes.  The frame_table is in order.

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

>  Do I need to account for the PDX hole?

Jan is probably the best person to ask about this, but I am failure sure
there are lurking dragons here.

PDX compression is used to reduce the size of the frametable when there
are large unused ranges of mfns.  Without paying attention to the PDX
shift, you don't know where the discontinuities lie.

However, because the PDX shift is an aligned power of two, there are
likely to be struct page_info*'s in the frame_table which don't point at
real RAM, and won't have a virtual mapping even in the directmap.

~Andrew

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

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

[Andrew Cooper]

On 13/07/16 20:33, Corneliu ZUZU wrote:
> On 7/13/2016 10:01 PM, Stefano Stabellini wrote:
>> On Wed, 13 Jul 2016, Corneliu ZUZU wrote:
>>> Create a common-side  to establish, among others,
>>> prototypes of
>>> atomic functions called from common-code. Done to avoid introducing
>>> inconsistencies between arch-side  headers when we
>>> make subtle
>>> changes to one of them.
>>>
>>> Some arm-side macros had to be turned into inline functions in the
>>> process.
>>> Removed outdated comment ("NB. I've [...]").
>>>
>>> Signed-off-by: Corneliu ZUZU 
>>> Suggested-by: Andrew Cooper 
>>> Reviewed-by: Andrew Cooper 
>>> ---
>>> Changed since v1:
>>>* removed comments that were duplicate between asm-x86/atomic.h and
>>>  xen/atomic.h
>>>* remove outdated comment ("NB. [...]")
>>>* add atomic_cmpxchg doc-comment
>>>* don't use yoda condition
>>> ---
>>>   xen/include/asm-arm/atomic.h |  45 
>>>   xen/include/asm-x86/atomic.h | 103 +-
>>>   xen/include/xen/atomic.h | 171
>>> +++
>>>   3 files changed, 202 insertions(+), 117 deletions(-)
>>>   create mode 100644 xen/include/xen/atomic.h
>>>
>>> diff --git a/xen/include/asm-arm/atomic.h
>>> b/xen/include/asm-arm/atomic.h
>>> index e8f7340..01af43b 100644
>>> --- a/xen/include/asm-arm/atomic.h
>>> +++ b/xen/include/asm-arm/atomic.h
>>> @@ -2,6 +2,7 @@
>>>   #define __ARCH_ARM_ATOMIC__
>>> #include 
>>> +#include 
>>>   #include 
>>>   #include 
>>>   @@ -95,15 +96,6 @@ void __bad_atomic_size(void);
>>>   default: __bad_atomic_size();
>>> break;\
>>>  
>>> }   \
>>>   })
>>> -
>>> -/*
>>> - * NB. I've pushed the volatile qualifier into the operations. This
>>> allows
>>> - * fast accessors such as _atomic_read() and _atomic_set() which
>>> don't give
>>> - * the compiler a fit.
>>> - */
>>> -typedef struct { int counter; } atomic_t;
>>> -
>>> -#define ATOMIC_INIT(i) { (i) }
>>> /*
>>>* On ARM, ordinary assignment (str instruction) doesn't clear the
>>> local
>>> @@ -141,12 +133,35 @@ static inline void _atomic_set(atomic_t *v,
>>> int i)
>>>   #define atomic_inc_return(v)(atomic_add_return(1, v))
>>>   #define atomic_dec_return(v)(atomic_sub_return(1, v))
>> What about atomic_inc_return and atomic_dec_return? Doesn't it make
>> sense to do this for all of them, since we are at it? I believe there
>> are also a couple more which are #define'd.
>
> Those don't seem to be implemented for X86 and neither are they
> referred from common code (probably because they really aren't defined
> for X86).

Apologies - this is definitely turning into the rats nest I warned you
it might.

As far as I am concerned, I only think it is important to have the
static inline prototypes for the versions which are actually common
between architectures.  Those are the ones we don't want to break
accidentally.

However, for the helpers which are not common, having them consistently
static inline would be a distinct improvement over mixed
inline/defines.  (static inline functions are superior to macros in many
ways.)

~Andrew

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

[Xen-devel] Converting heap page_infos to contiguous virtual

[Boris Ostrovsky]

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

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

and then

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


Would it be valid to this? Do I need to account for the PDX hole?


Thanks.
-boris





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

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

[Corneliu ZUZU]

Hi Julien,

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

Hi Corneliu,

On 13/07/2016 15:18, Corneliu ZUZU wrote:
Move duplicate macros between asm-arm/arm32/atomic.h and 
asm-arm/arm64/atomic.h

to asm-arm/atomic.h.


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


Regards,



Thanks for pointing that out, I didn't know these files were referred in 
such a way. What is the purpose of README.LinuxPrimitives and how must I 
update it to align with these patches?


Cheers,
Zuzu C.

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

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

[Corneliu ZUZU]

On 7/13/2016 10:01 PM, Stefano Stabellini wrote:

On Wed, 13 Jul 2016, Corneliu ZUZU wrote:

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

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

Signed-off-by: Corneliu ZUZU 
Suggested-by: Andrew Cooper 
Reviewed-by: Andrew Cooper 
---
Changed since v1:
   * removed comments that were duplicate between asm-x86/atomic.h and
 xen/atomic.h
   * remove outdated comment ("NB. [...]")
   * add atomic_cmpxchg doc-comment
   * don't use yoda condition
---
  xen/include/asm-arm/atomic.h |  45 
  xen/include/asm-x86/atomic.h | 103 +-
  xen/include/xen/atomic.h | 171 +++
  3 files changed, 202 insertions(+), 117 deletions(-)
  create mode 100644 xen/include/xen/atomic.h

diff --git a/xen/include/asm-arm/atomic.h b/xen/include/asm-arm/atomic.h
index e8f7340..01af43b 100644
--- a/xen/include/asm-arm/atomic.h
+++ b/xen/include/asm-arm/atomic.h
@@ -2,6 +2,7 @@
  #define __ARCH_ARM_ATOMIC__
  
  #include 

+#include 
  #include 
  #include 
  
@@ -95,15 +96,6 @@ void __bad_atomic_size(void);

  default: __bad_atomic_size(); break;\
  }   \
  })
-
-/*
- * NB. I've pushed the volatile qualifier into the operations. This allows
- * fast accessors such as _atomic_read() and _atomic_set() which don't give
- * the compiler a fit.
- */
-typedef struct { int counter; } atomic_t;
-
-#define ATOMIC_INIT(i) { (i) }
  
  /*

   * On ARM, ordinary assignment (str instruction) doesn't clear the local
@@ -141,12 +133,35 @@ static inline void _atomic_set(atomic_t *v, int i)
  #define atomic_inc_return(v)(atomic_add_return(1, v))
  #define atomic_dec_return(v)(atomic_sub_return(1, v))

What about atomic_inc_return and atomic_dec_return? Doesn't it make
sense to do this for all of them, since we are at it? I believe there
are also a couple more which are #define'd.


Those don't seem to be implemented for X86 and neither are they referred 
from common code (probably because they really aren't defined for X86).



-#define atomic_sub_and_test(i, v)   (atomic_sub_return(i, v) == 0)
-#define atomic_inc(v)   atomic_add(1, v)
-#define atomic_inc_and_test(v)  (atomic_add_return(1, v) == 0)
-#define atomic_dec(v)   atomic_sub(1, v)
-#define atomic_dec_and_test(v)  (atomic_sub_return(1, v) == 0)
-#define atomic_add_negative(i,v)(atomic_add_return(i, v) < 0)
+static inline int atomic_sub_and_test(int i, atomic_t *v)
+{
+return atomic_sub_return(i, v) == 0;
+}
+
+static inline void atomic_inc(atomic_t *v)
+{
+atomic_add(1, v);
+}
+
+static inline int atomic_inc_and_test(atomic_t *v)
+{
+return atomic_add_return(1, v) == 0;
+}
+
+static inline void atomic_dec(atomic_t *v)
+{
+atomic_sub(1, v);
+}
+
+static inline int atomic_dec_and_test(atomic_t *v)
+{
+return atomic_sub_return(1, v) == 0;
+}
+
+static inline int atomic_add_negative(int i, atomic_t *v)
+{
+return atomic_add_return(i, v) < 0;
+}
  
  #endif /* __ARCH_ARM_ATOMIC__ */


Thanks,
Zuzu C.

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

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

[Julien Grall]

Hi Corneliu,

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

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


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


Regards,

--
Julien Grall

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

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

[Stefano Stabellini]

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

As a Xen check, if (!xen_domain()) is the common pattern.

> We need the xen_node from device tree, anyway.

In that case, what don't you just use the global xen_node in this file?

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

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

[Stefano Stabellini]

On Wed, 13 Jul 2016, Corneliu ZUZU wrote:
> Create a common-side  to establish, among others, prototypes of
> atomic functions called from common-code. Done to avoid introducing
> inconsistencies between arch-side  headers when we make subtle
> changes to one of them.
> 
> Some arm-side macros had to be turned into inline functions in the process.
> Removed outdated comment ("NB. I've [...]").
> 
> Signed-off-by: Corneliu ZUZU 
> Suggested-by: Andrew Cooper 
> Reviewed-by: Andrew Cooper 
> ---
> Changed since v1:
>   * removed comments that were duplicate between asm-x86/atomic.h and
> xen/atomic.h
>   * remove outdated comment ("NB. [...]")
>   * add atomic_cmpxchg doc-comment
>   * don't use yoda condition
> ---
>  xen/include/asm-arm/atomic.h |  45 
>  xen/include/asm-x86/atomic.h | 103 +-
>  xen/include/xen/atomic.h | 171 
> +++
>  3 files changed, 202 insertions(+), 117 deletions(-)
>  create mode 100644 xen/include/xen/atomic.h
> 
> diff --git a/xen/include/asm-arm/atomic.h b/xen/include/asm-arm/atomic.h
> index e8f7340..01af43b 100644
> --- a/xen/include/asm-arm/atomic.h
> +++ b/xen/include/asm-arm/atomic.h
> @@ -2,6 +2,7 @@
>  #define __ARCH_ARM_ATOMIC__
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -95,15 +96,6 @@ void __bad_atomic_size(void);
>  default: __bad_atomic_size(); break;\
>  }   \
>  })
> -
> -/*
> - * NB. I've pushed the volatile qualifier into the operations. This allows
> - * fast accessors such as _atomic_read() and _atomic_set() which don't give
> - * the compiler a fit.
> - */
> -typedef struct { int counter; } atomic_t;
> -
> -#define ATOMIC_INIT(i) { (i) }
>  
>  /*
>   * On ARM, ordinary assignment (str instruction) doesn't clear the local
> @@ -141,12 +133,35 @@ static inline void _atomic_set(atomic_t *v, int i)
>  #define atomic_inc_return(v)(atomic_add_return(1, v))
>  #define atomic_dec_return(v)(atomic_sub_return(1, v))

What about atomic_inc_return and atomic_dec_return? Doesn't it make
sense to do this for all of them, since we are at it? I believe there
are also a couple more which are #define'd.


> -#define atomic_sub_and_test(i, v)   (atomic_sub_return(i, v) == 0)
> -#define atomic_inc(v)   atomic_add(1, v)
> -#define atomic_inc_and_test(v)  (atomic_add_return(1, v) == 0)
> -#define atomic_dec(v)   atomic_sub(1, v)
> -#define atomic_dec_and_test(v)  (atomic_sub_return(1, v) == 0)
> -#define atomic_add_negative(i,v)(atomic_add_return(i, v) < 0)
> +static inline int atomic_sub_and_test(int i, atomic_t *v)
> +{
> +return atomic_sub_return(i, v) == 0;
> +}
> +
> +static inline void atomic_inc(atomic_t *v)
> +{
> +atomic_add(1, v);
> +}
> +
> +static inline int atomic_inc_and_test(atomic_t *v)
> +{
> +return atomic_add_return(1, v) == 0;
> +}
> +
> +static inline void atomic_dec(atomic_t *v)
> +{
> +atomic_sub(1, v);
> +}
> +
> +static inline int atomic_dec_and_test(atomic_t *v)
> +{
> +return atomic_sub_return(1, v) == 0;
> +}
> +
> +static inline int atomic_add_negative(int i, atomic_t *v)
> +{
> +return atomic_add_return(i, v) < 0;
> +}
>  
>  #endif /* __ARCH_ARM_ATOMIC__ */

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

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

[Dirk Behme]

On 13.07.2016 20:43, Stefano Stabellini wrote:

On Wed, 13 Jul 2016, Dirk Behme wrote:

On 13.07.2016 00:26, Michael Turquette wrote:

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

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


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

CLK_SET_RATE_GATE
CLK_SET_PARENT_GATE




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

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


These are internal Linux flags, aren't they?



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


Best regards

Dirk



They cannot be set in Xen.

If the only way to make sure that clk_set_rate and clk_set_parent fail
on one of the clocks "owned" by Xen is to set CLK_SET_RATE_GATE and
CLK_SET_PARENT_GATE, we'll have to do that. Even if it means introducing
a new internal Linux API.



And then enable the clocks. All calls to clk_set_parent and clk_set_rate
with those clocks in the path will fail, so long as they are prepared
and enabled. This implementation detail is specific to Linux and
definitely should not go into the binding.



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


I'm still not completely sure about this type of layering and whether or
not it is sane. If you want Xen to manage the clock controller, AND you
want Linux guests or dom0 to consume those clocks and manipulate them in
other drivers, then this solution won't work.

Regards,
Mike



Up to now, the workaround for this has been to use the Linux kernel
command line parameter 'clk_ignore_unused'. See Xen bug

http://bugs.xenproject.org/xen/bug/45

too.

Signed-off-by: Dirk Behme 
---
Changes in v4: Switch to the xen.txt description proposed by Mark:
https://www.spinics.net/lists/arm-kernel/msg516158.html

Changes in v3: Use the xen.txt description proposed by Michael. Thanks!

Changes in v2: Drop the Linux implementation details like
clk_disable_unused
in xen.txt.

  Documentation/devicetree/bindings/arm/xen.txt | 12 +++
  arch/arm/xen/enlighten.c  | 47
+++
  2 files changed, 59 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/xen.txt
b/Documentation/devicetree/bindings/arm/xen.txt
index c9b9321..437e50b 100644
--- a/Documentation/devicetree/bindings/arm/xen.txt
+++ b/Documentation/devicetree/bindings/arm/xen.txt
@@ -17,6 +17,18 @@ the following properties:
A GIC node is also required.
This property is unnecessary when booting Dom0 using ACPI.

+Optional properties:
+
+- clocks: a list of phandle + clock-specifier pairs
+  Clocks described by this property are reserved for use by Xen, and the
+  OS must not alter their state any way, such as disabling or gating a
+  clock, or modifying its rate. Ensuring this may impose constraints on
+  parent clocks or other resources used by the clock tree.
+
+  Note: this property is used to proxy clocks for devices Xen has taken
+  ownership of, such as UARTs, for which the associated clock
+  controller(s) remain under the control of Dom0.
+
  To support UEFI on Xen ARM virtual platforms, Xen populates the FDT
"uefi" node
  under /hypervisor with following parameters:

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 47acb36..5c546d0 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -24,6 +24,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -444,6 +445,52 @@ static int __init xen_pm_init(void)
  }
  late_initcall(xen_pm_init);

+/*
+ * Check if we want to register some clocks, that they
+ * are not freed because unused by clk_disable_unused().
+ * E.g. the serial console clock.
+ */
+static int __init xen_arm_register_clks(void)
+{
+   struct clk *clk;
+   struct device_node *xen_node;
+   unsigned int i, count;
+   int ret = 0;
+
+   xen_node = of_find_compatible_node(NULL, NULL, "xen,xen");
+   if (!xen_node) {
+   pr_err("Xen support was detected before, but it has
disappeared\n");
+   return -EINVAL;
+   

Re: [Xen-devel] [PATCH 14/16] x86/monitor: clarify separation between monitor subsys and vm-event as a whole

[Tamas K Lengyel]

On Tue, Jul 12, 2016 at 10:26 PM, Corneliu ZUZU  wrote:
> On 7/9/2016 9:57 PM, Corneliu ZUZU wrote:
>>
>> On 7/9/2016 9:26 PM, Tamas K Lengyel wrote:

 diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
 index ae1dcb4..7663da2 100644
 --- a/xen/include/asm-x86/domain.h
 +++ b/xen/include/asm-x86/domain.h
 @@ -9,6 +9,7 @@
   #include 
   #include 
   #include 
 +#include 
   #include 

   #define has_32bit_shinfo(d) ((d)->arch.has_32bit_shinfo)
 @@ -503,6 +504,20 @@ typedef enum __packed {
   SMAP_CHECK_DISABLED,/* disable the check */
   } smap_check_policy_t;

 +/*
 + * Should we emulate the next matching instruction on VCPU resume
 + * after a vm_event?
 + */
 +struct arch_vm_event_monitor {
>>>
>>> This should be named struct arch_vcpu_monitor.
>>
>>
>> Good idea.
>>
>>>
 +uint32_t emulate_flags;
 +struct vm_event_emul_read_data emul_read_data;
>>>
>>> This should probably get renamed as well at some point to struct
>>> monitor_emul_read_data.
>>
>>
>> Ack.
>>
 +struct monitor_write_data write_data;
 +};
 +
 +struct arch_vm_event {
 +struct arch_vm_event_monitor *monitor;
 +};
>>>
>>> IMHO there is not much point in defining struct arch_vm_event this
>>> way, we could just as well store the pointer to the arch_monitor
>>> directly in arch_vcpu as we do right now.
>>>
>>
>> I stated the reason for that in the commit message (see 3rd '*'), Jan
>> insists it would be preferable to occupy just one pointer in arch_vcpu
>> (which would still hold if we do as you suggest but I was wondering how
>> probable would it be in the future for one of the paging/share vm-event
>> subsystems to need per-vCPU resources). But personally, yeah, I would have
>> preferred what you suggest as well..
>>
>> Zuzu.
>
>
> Tamas, any update on this? Do you think we should think now about per-vCPU
> resources being occupied in the future by paging/share or leave that for
> later and do what you suggested?

It's highly unlikely that either paging or sharing will have any use
of this struct in the near future provided but subsystems are pretty
much orphaned at this point. If we ever going to need it it's an easy
enough adjustment but for now it's not needed.

Tamas

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

Re: [Xen-devel] [PATCH] xen/apic: Update the comment for apic_id_mask

[Boris Ostrovsky]

On 07/13/2016 03:56 AM, Wei, Jiangang wrote:
> On Thu, 2016-07-07 at 11:37 -0400, Boris Ostrovsky wrote:
>> On 07/07/2016 11:25 AM, Konrad Rzeszutek Wilk wrote:
>>> On Thu, Jul 07, 2016 at 11:28:18AM +0800, Wei Jiangang wrote:
 verify_local_APIC() had been removed by
 commit 4399c03c6780 ("x86/apic: Remove verify_local_APIC()"),
 so apic_id_mask isn't used by it.
>> Is anyone actually using this field? It looks like 4399c03c6780 removed
>> the only user.
> Indeed, the field is useless.
> Maybe we can remove this field from the struct apic .
> what's your opinion?


Since noone seems to be using those I think it can be removed.

-boris


>
> Thanks,
> wei
>> -boris
>>
>>
>>> CC-ing the proper maintainers.
 Signed-off-by: Wei Jiangang 
 ---
  arch/x86/xen/apic.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/arch/x86/xen/apic.c b/arch/x86/xen/apic.c
 index db52a7fafcc2..9cbb1f48381b 100644
 --- a/arch/x86/xen/apic.c
 +++ b/arch/x86/xen/apic.c
 @@ -177,7 +177,7 @@ static struct apic xen_pv_apic = {
  
.get_apic_id= xen_get_apic_id,
.set_apic_id= xen_set_apic_id, /* Can be NULL on 
 32-bit. */
 -  .apic_id_mask   = 0xFF << 24, /* Used by 
 verify_local_APIC. Match with what xen_get_apic_id does. */
 +  .apic_id_mask   = 0xFF << 24, /* Match with what 
 xen_get_apic_id does. */
  
.cpu_mask_to_apicid_and = flat_cpu_mask_to_apicid_and,
  
 -- 
 1.9.3




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


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

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

[Stefano Stabellini]

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

Reviewed-by: Stefano Stabellini 

> ---
> Changed since v1: 
> ---
>  xen/include/asm-arm/atomic.h | 2 +-
>  xen/include/asm-x86/atomic.h | 2 +-
>  xen/include/xen/atomic.h | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/include/asm-arm/atomic.h b/xen/include/asm-arm/atomic.h
> index 01af43b..25a33cb 100644
> --- a/xen/include/asm-arm/atomic.h
> +++ b/xen/include/asm-arm/atomic.h
> @@ -102,7 +102,7 @@ void __bad_atomic_size(void);
>   * strex/ldrex monitor on some implementations. The reason we can use it for
>   * atomic_set() is the clrex or dummy strex done on every exception return.
>   */
> -static inline int atomic_read(atomic_t *v)
> +static inline int atomic_read(const atomic_t *v)
>  {
>  return *(volatile int *)>counter;
>  }
> diff --git a/xen/include/asm-x86/atomic.h b/xen/include/asm-x86/atomic.h
> index 3e99b03..1729e29 100644
> --- a/xen/include/asm-x86/atomic.h
> +++ b/xen/include/asm-x86/atomic.h
> @@ -80,7 +80,7 @@ void __bad_atomic_size(void);
>  } \
>  })
>  
> -static inline int atomic_read(atomic_t *v)
> +static inline int atomic_read(const atomic_t *v)
>  {
>  return read_atomic(>counter);
>  }
> diff --git a/xen/include/xen/atomic.h b/xen/include/xen/atomic.h
> index 3517bc9..d97f91d 100644
> --- a/xen/include/xen/atomic.h
> +++ b/xen/include/xen/atomic.h
> @@ -32,7 +32,7 @@ typedef struct { int counter; } atomic_t;
>   *
>   * Atomically reads the value of @v.
>   */
> -static inline int atomic_read(atomic_t *v);
> +static inline int atomic_read(const atomic_t *v);
>  
>  /**
>   * _atomic_read - read atomic variable non-atomically
> -- 
> 2.5.0
> 

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

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

[Stefano Stabellini]

On Wed, 13 Jul 2016, Corneliu ZUZU wrote:
> Reorder macro definitions to match x86-side.
> 
> Signed-off-by: Corneliu ZUZU 

Reviewed-by: Stefano Stabellini 


>  xen/include/asm-arm/atomic.h | 19 +--
>  1 file changed, 9 insertions(+), 10 deletions(-)
> 
> diff --git a/xen/include/asm-arm/atomic.h b/xen/include/asm-arm/atomic.h
> index 19a87a5..e8f7340 100644
> --- a/xen/include/asm-arm/atomic.h
> +++ b/xen/include/asm-arm/atomic.h
> @@ -138,16 +138,15 @@ static inline void _atomic_set(atomic_t *v, int i)
>  # error "unknown ARM variant"
>  #endif
>  
> -#define atomic_inc(v)   atomic_add(1, v)
> -#define atomic_dec(v)   atomic_sub(1, v)
> -
> -#define atomic_inc_and_test(v)  (atomic_add_return(1, v) == 0)
> -#define atomic_dec_and_test(v)  (atomic_sub_return(1, v) == 0)
> -#define atomic_inc_return(v)(atomic_add_return(1, v))
> -#define atomic_dec_return(v)(atomic_sub_return(1, v))
> -#define atomic_sub_and_test(i, v) (atomic_sub_return(i, v) == 0)
> -
> -#define atomic_add_negative(i,v) (atomic_add_return(i, v) < 0)
> +#define atomic_inc_return(v)(atomic_add_return(1, v))
> +#define atomic_dec_return(v)(atomic_sub_return(1, v))
> +
> +#define atomic_sub_and_test(i, v)   (atomic_sub_return(i, v) == 0)
> +#define atomic_inc(v)   atomic_add(1, v)
> +#define atomic_inc_and_test(v)  (atomic_add_return(1, v) == 0)
> +#define atomic_dec(v)   atomic_sub(1, v)
> +#define atomic_dec_and_test(v)  (atomic_sub_return(1, v) == 0)
> +#define atomic_add_negative(i,v)(atomic_add_return(i, v) < 0)
>  
>  #endif /* __ARCH_ARM_ATOMIC__ */
>  
> -- 
> 2.5.0
> 

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

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

[Stefano Stabellini]

On Wed, 13 Jul 2016, Corneliu ZUZU wrote:
> Place atomic_inc_and_test() implementation after atomic_inc().
> Also remove unneeded empty line and add a needed one.
> 
> Signed-off-by: Corneliu ZUZU 

For the ARM bit, even though it is a bit embarassing acking a one-liner
empty line addition:

Acked-by: Stefano Stabellini 


>  xen/include/asm-arm/atomic.h |  1 +
>  xen/include/asm-x86/atomic.h | 39 +++
>  2 files changed, 20 insertions(+), 20 deletions(-)
> 
> diff --git a/xen/include/asm-arm/atomic.h b/xen/include/asm-arm/atomic.h
> index 41d1b6c..19a87a5 100644
> --- a/xen/include/asm-arm/atomic.h
> +++ b/xen/include/asm-arm/atomic.h
> @@ -150,6 +150,7 @@ static inline void _atomic_set(atomic_t *v, int i)
>  #define atomic_add_negative(i,v) (atomic_add_return(i, v) < 0)
>  
>  #endif /* __ARCH_ARM_ATOMIC__ */
> +
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/xen/include/asm-x86/atomic.h b/xen/include/asm-x86/atomic.h
> index d246b70..5f9f2dd 100644
> --- a/xen/include/asm-x86/atomic.h
> +++ b/xen/include/asm-x86/atomic.h
> @@ -110,7 +110,6 @@ static inline int _atomic_read(atomic_t v)
>  return v.counter;
>  }
>  
> -
>  /**
>   * atomic_set - set atomic variable
>   * @v: pointer of type atomic_t
> @@ -217,6 +216,25 @@ static inline void atomic_inc(atomic_t *v)
>  }
>  
>  /**
> + * atomic_inc_and_test - increment and test
> + * @v: pointer of type atomic_t
> + *
> + * Atomically increments @v by 1
> + * and returns true if the result is zero, or false for all
> + * other cases.
> + */
> +static inline int atomic_inc_and_test(atomic_t *v)
> +{
> +unsigned char c;
> +
> +asm volatile (
> +"lock; incl %0; sete %1"
> +: "=m" (*(volatile int *)>counter), "=qm" (c)
> +: "m" (*(volatile int *)>counter) : "memory" );
> +return c != 0;
> +}
> +
> +/**
>   * atomic_dec - decrement atomic variable
>   * @v: pointer of type atomic_t
>   * 
> @@ -250,25 +268,6 @@ static inline int atomic_dec_and_test(atomic_t *v)
>  }
>  
>  /**
> - * atomic_inc_and_test - increment and test 
> - * @v: pointer of type atomic_t
> - * 
> - * Atomically increments @v by 1
> - * and returns true if the result is zero, or false for all
> - * other cases.
> - */ 
> -static inline int atomic_inc_and_test(atomic_t *v)
> -{
> -unsigned char c;
> -
> -asm volatile (
> -"lock; incl %0; sete %1"
> -: "=m" (*(volatile int *)>counter), "=qm" (c)
> -: "m" (*(volatile int *)>counter) : "memory" );
> -return c != 0;
> -}
> -
> -/**
>   * atomic_add_negative - add and test if negative
>   * @v: pointer of type atomic_t
>   * @i: integer value to add
> -- 
> 2.5.0
> 

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

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

[Dirk Behme]

On 13.07.2016 20:35, Stefano Stabellini wrote:

On Tue, 12 Jul 2016, Dirk Behme wrote:

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

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

Up to now, the workaround for this has been to use the Linux kernel
command line parameter 'clk_ignore_unused'. See Xen bug

http://bugs.xenproject.org/xen/bug/45

too.

Signed-off-by: Dirk Behme 
---
Changes in v4: Switch to the xen.txt description proposed by Mark:
https://www.spinics.net/lists/arm-kernel/msg516158.html

Changes in v3: Use the xen.txt description proposed by Michael. Thanks!

Changes in v2: Drop the Linux implementation details like clk_disable_unused
   in xen.txt.

  Documentation/devicetree/bindings/arm/xen.txt | 12 +++
  arch/arm/xen/enlighten.c  | 47 +++
  2 files changed, 59 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/xen.txt 
b/Documentation/devicetree/bindings/arm/xen.txt
index c9b9321..437e50b 100644
--- a/Documentation/devicetree/bindings/arm/xen.txt
+++ b/Documentation/devicetree/bindings/arm/xen.txt
@@ -17,6 +17,18 @@ the following properties:
A GIC node is also required.
This property is unnecessary when booting Dom0 using ACPI.

+Optional properties:
+
+- clocks: a list of phandle + clock-specifier pairs
+  Clocks described by this property are reserved for use by Xen, and the
+  OS must not alter their state any way, such as disabling or gating a
+  clock, or modifying its rate. Ensuring this may impose constraints on
+  parent clocks or other resources used by the clock tree.
+
+  Note: this property is used to proxy clocks for devices Xen has taken
+  ownership of, such as UARTs, for which the associated clock
+  controller(s) remain under the control of Dom0.
+
  To support UEFI on Xen ARM virtual platforms, Xen populates the FDT "uefi" 
node
  under /hypervisor with following parameters:

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 47acb36..5c546d0 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -24,6 +24,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -444,6 +445,52 @@ static int __init xen_pm_init(void)
  }
  late_initcall(xen_pm_init);

+/*
+ * Check if we want to register some clocks, that they
+ * are not freed because unused by clk_disable_unused().
+ * E.g. the serial console clock.
+ */
+static int __init xen_arm_register_clks(void)
+{
+   struct clk *clk;
+   struct device_node *xen_node;
+   unsigned int i, count;
+   int ret = 0;
+
+   xen_node = of_find_compatible_node(NULL, NULL, "xen,xen");
+   if (!xen_node) {
+   pr_err("Xen support was detected before, but it has 
disappeared\n");
+   return -EINVAL;
+   }


Given that this is a late initcall, the following should work:

 if (!xen_domain())
 return -ENODEV;



Hmm, sorry, "should work" for what?

We need the xen_node from device tree, anyway.

Best regards

Dirk


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

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

[Stefano Stabellini]

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

These are internal Linux flags, aren't they? They cannot be set in Xen.

If the only way to make sure that clk_set_rate and clk_set_parent fail
on one of the clocks "owned" by Xen is to set CLK_SET_RATE_GATE and
CLK_SET_PARENT_GATE, we'll have to do that. Even if it means introducing
a new internal Linux API.


> > And then enable the clocks. All calls to clk_set_parent and clk_set_rate
> > with those clocks in the path will fail, so long as they are prepared
> > and enabled. This implementation detail is specific to Linux and
> > definitely should not go into the binding.
> > 
> > > 
> > > This property is used to proxy clocks for devices Xen has taken ownership
> > > of, such as UARTs, for which the associated clock controller(s) remain
> > > under the control of Dom0.
> > 
> > I'm still not completely sure about this type of layering and whether or
> > not it is sane. If you want Xen to manage the clock controller, AND you
> > want Linux guests or dom0 to consume those clocks and manipulate them in
> > other drivers, then this solution won't work.
> > 
> > Regards,
> > Mike
> > 
> > > 
> > > Up to now, the workaround for this has been to use the Linux kernel
> > > command line parameter 'clk_ignore_unused'. See Xen bug
> > > 
> > > http://bugs.xenproject.org/xen/bug/45
> > > 
> > > too.
> > > 
> > > Signed-off-by: Dirk Behme 
> > > ---
> > > Changes in v4: Switch to the xen.txt description proposed by Mark:
> > >https://www.spinics.net/lists/arm-kernel/msg516158.html
> > > 
> > > Changes in v3: Use the xen.txt description proposed by Michael. Thanks!
> > > 
> > > Changes in v2: Drop the Linux implementation details like
> > > clk_disable_unused
> > >in xen.txt.
> > > 
> > >  Documentation/devicetree/bindings/arm/xen.txt | 12 +++
> > >  arch/arm/xen/enlighten.c  | 47
> > > +++
> > >  2 files changed, 59 insertions(+)
> > > 
> > > diff --git a/Documentation/devicetree/bindings/arm/xen.txt
> > > b/Documentation/devicetree/bindings/arm/xen.txt
> > > index c9b9321..437e50b 100644
> > > --- a/Documentation/devicetree/bindings/arm/xen.txt
> > > +++ b/Documentation/devicetree/bindings/arm/xen.txt
> > > @@ -17,6 +17,18 @@ the following properties:
> > >A GIC node is also required.
> > >This property is unnecessary when booting Dom0 using ACPI.
> > > 
> > > +Optional properties:
> > > +
> > > +- clocks: a list of phandle + clock-specifier pairs
> > > +  Clocks described by this property are reserved for use by Xen, and the
> > > +  OS must not alter their state any way, such as disabling or gating a
> > > +  clock, or modifying its rate. Ensuring this may impose constraints on
> > > +  parent clocks or other resources used by the clock tree.
> > > +
> > > +  Note: this property is used to proxy clocks for devices Xen has taken
> > > +  ownership of, such as UARTs, for which the associated clock
> > > +  controller(s) remain under the control of Dom0.
> > > +
> > >  To support UEFI on Xen ARM virtual platforms, Xen populates the FDT
> > > "uefi" node
> > >  under /hypervisor with following parameters:
> > > 
> > > diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> > > index 47acb36..5c546d0 100644
> > > --- a/arch/arm/xen/enlighten.c
> > > +++ b/arch/arm/xen/enlighten.c
> > > @@ -24,6 +24,7 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > >  #include 
> > >  #include 
> > >  #include 
> > > @@ -444,6 +445,52 @@ static int __init xen_pm_init(void)
> > >  }
> > >  late_initcall(xen_pm_init);
> > > 
> > > +/*
> > > + * Check if we want to register some clocks, that they
> > > + * are not freed because unused by clk_disable_unused().
> > > + * E.g. the serial console clock.
> > > + */
> > > +static int __init 

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

[Stefano Stabellini]

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

Given that this is a late initcall, the following should work:

if (!xen_domain())
return -ENODEV;

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

Re: [Xen-devel] [patch V2 49/67] arm/xen: Convert to hotplug state machine

[Stefano Stabellini]

On Wed, 13 Jul 2016, Anna-Maria Gleixner wrote:
> From: Richard Cochran 
> 
> Install the callbacks via the state machine and let the core invoke
> the callbacks on the already online CPUs.
> 
> The get_cpu() in xen_starting_cpu() boils down to preempt_disable() since
> we already know the CPU we run on. Disabling preemption shouldn't be required
> here from what I see since it we don't switch CPUs while invoking the 
> function.
> 
> Signed-off-by: Richard Cochran 
> Reviewed-by: Sebastian Andrzej Siewior 
> Cc: Linus Torvalds 
> Cc: Peter Zijlstra 
> Cc: Russell King 
> Cc: Stefano Stabellini 
> Cc: Stefano Stabellini 
> Cc: Thomas Gleixner 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: xen-de...@lists.xenproject.org
> Signed-off-by: Anna-Maria Gleixner 

Reviewed-by: Stefano Stabellini 


>  arch/arm/xen/enlighten.c   | 41 +++--
>  include/linux/cpuhotplug.h |  1 +
>  2 files changed, 12 insertions(+), 30 deletions(-)
> 
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index 75cd734..d822e23 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -161,12 +161,11 @@ static struct notifier_block xen_pvclock_gtod_notifier 
> = {
>   .notifier_call = xen_pvclock_gtod_notify,
>  };
>  
> -static void xen_percpu_init(void)
> +static int xen_starting_cpu(unsigned int cpu)
>  {
>   struct vcpu_register_vcpu_info info;
>   struct vcpu_info *vcpup;
>   int err;
> - int cpu = get_cpu();
>  
>   /* 
>* VCPUOP_register_vcpu_info cannot be called twice for the same
> @@ -190,7 +189,13 @@ static void xen_percpu_init(void)
>  
>  after_register_vcpu_info:
>   enable_percpu_irq(xen_events_irq, 0);
> - put_cpu();
> + return 0;
> +}
> +
> +static int xen_dying_cpu(unsigned int cpu)
> +{
> + disable_percpu_irq(xen_events_irq);
> + return 0;
>  }
>  
>  static void xen_restart(enum reboot_mode reboot_mode, const char *cmd)
> @@ -209,28 +214,6 @@ static void xen_power_off(void)
>   BUG_ON(rc);
>  }
>  
> -static int xen_cpu_notification(struct notifier_block *self,
> - unsigned long action,
> - void *hcpu)
> -{
> - switch (action) {
> - case CPU_STARTING:
> - xen_percpu_init();
> - break;
> - case CPU_DYING:
> - disable_percpu_irq(xen_events_irq);
> - break;
> - default:
> - break;
> - }
> -
> - return NOTIFY_OK;
> -}
> -
> -static struct notifier_block xen_cpu_notifier = {
> - .notifier_call = xen_cpu_notification,
> -};
> -
>  static irqreturn_t xen_arm_callback(int irq, void *arg)
>  {
>   xen_hvm_evtchn_do_upcall();
> @@ -351,16 +334,14 @@ static int __init xen_guest_init(void)
>   return -EINVAL;
>   }
>  
> - xen_percpu_init();
> -
> - register_cpu_notifier(_cpu_notifier);
> -
>   pv_time_ops.steal_clock = xen_stolen_accounting;
>   static_key_slow_inc(_steal_enabled);
>   if (xen_initial_domain())
>   pvclock_gtod_register_notifier(_pvclock_gtod_notifier);
>  
> - return 0;
> + return cpuhp_setup_state(CPUHP_AP_ARM_XEN_STARTING,
> +  "AP_ARM_XEN_STARTING", xen_starting_cpu,
> +  xen_dying_cpu);
>  }
>  early_initcall(xen_guest_init);
>  
> diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h
> index 86ac982..f986963 100644
> --- a/include/linux/cpuhotplug.h
> +++ b/include/linux/cpuhotplug.h
> @@ -48,6 +48,7 @@ enum cpuhp_state {
>   CPUHP_AP_KVM_STARTING,
>   CPUHP_AP_KVM_ARM_VGIC_STARTING,
>   CPUHP_AP_KVM_ARM_TIMER_STARTING,
> + CPUHP_AP_ARM_XEN_STARTING,
>   CPUHP_AP_LEDTRIG_STARTING,
>   CPUHP_AP_NOTIFY_STARTING,
>   CPUHP_AP_ONLINE,
> -- 
> 2.8.1
> 
> 
> 

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

Re: [Xen-devel] [PATCH v7 12/14] xen/arm: p2m: Introduce helpers to insert and remove mapping

[Stefano Stabellini]

On Tue, 12 Jul 2016, Julien Grall wrote:
> More the half of the arguments of INSERT and REMOVE are the same for
> each callers. Simplify the callers of apply_p2m_changes by adding new
> helpers which will fill common arguments with default values.
> 
> Signed-off-by: Julien Grall 

Acked-by: Stefano Stabellini 

> ---
> Changes in v7:
> - MATTR_DEV should be used in map_mmio_regions rather than MATTR_MEM
> 
> Changes in v5:
> - Add missing Signed-off-by
> 
> Changes in v4:
> - Patch added
> ---
>  xen/arch/arm/p2m.c | 70 
> --
>  1 file changed, 36 insertions(+), 34 deletions(-)
> 
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index 2ba9477..dd890c2 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -1158,17 +1158,40 @@ out:
>  return rc;
>  }
>  
> +static inline int p2m_insert_mapping(struct domain *d,
> + gfn_t start_gfn,
> + unsigned long nr,
> + mfn_t mfn,
> + int mattr, p2m_type_t t)
> +{
> +return apply_p2m_changes(d, INSERT,
> + pfn_to_paddr(gfn_x(start_gfn)),
> + pfn_to_paddr(gfn_x(start_gfn) + nr),
> + pfn_to_paddr(mfn_x(mfn)),
> + mattr, 0, t, d->arch.p2m.default_access);
> +}
> +
> +static inline int p2m_remove_mapping(struct domain *d,
> + gfn_t start_gfn,
> + unsigned long nr,
> + mfn_t mfn)
> +{
> +return apply_p2m_changes(d, REMOVE,
> + pfn_to_paddr(gfn_x(start_gfn)),
> + pfn_to_paddr(gfn_x(start_gfn) + nr),
> + pfn_to_paddr(mfn_x(mfn)),
> + /* arguments below not used when removing 
> mapping */
> + MATTR_MEM, 0, p2m_invalid,
> + d->arch.p2m.default_access);
> +}
> +
>  int map_regions_rw_cache(struct domain *d,
>   gfn_t gfn,
>   unsigned long nr,
>   mfn_t mfn)
>  {
> -return apply_p2m_changes(d, INSERT,
> - pfn_to_paddr(gfn_x(gfn)),
> - pfn_to_paddr(gfn_x(gfn) + nr),
> - pfn_to_paddr(mfn_x(mfn)),
> - MATTR_MEM, 0, p2m_mmio_direct,
> - d->arch.p2m.default_access);
> +return p2m_insert_mapping(d, gfn, nr, mfn,
> +  MATTR_MEM, p2m_mmio_direct);
>  }
>  
>  int unmap_regions_rw_cache(struct domain *d,
> @@ -1176,12 +1199,7 @@ int unmap_regions_rw_cache(struct domain *d,
> unsigned long nr,
> mfn_t mfn)
>  {
> -return apply_p2m_changes(d, REMOVE,
> - pfn_to_paddr(gfn_x(gfn)),
> - pfn_to_paddr(gfn_x(gfn) + nr),
> - pfn_to_paddr(mfn_x(mfn)),
> - MATTR_MEM, 0, p2m_invalid,
> - d->arch.p2m.default_access);
> +return p2m_remove_mapping(d, gfn, nr, mfn);
>  }
>  
>  int map_mmio_regions(struct domain *d,
> @@ -1189,12 +1207,8 @@ int map_mmio_regions(struct domain *d,
>   unsigned long nr,
>   mfn_t mfn)
>  {
> -return apply_p2m_changes(d, INSERT,
> - pfn_to_paddr(gfn_x(start_gfn)),
> - pfn_to_paddr(gfn_x(start_gfn) + nr),
> - pfn_to_paddr(mfn_x(mfn)),
> - MATTR_DEV, 0, p2m_mmio_direct,
> - d->arch.p2m.default_access);
> +return p2m_insert_mapping(d, start_gfn, nr, mfn,
> +  MATTR_DEV, p2m_mmio_direct);
>  }
>  
>  int unmap_mmio_regions(struct domain *d,
> @@ -1202,12 +1216,7 @@ int unmap_mmio_regions(struct domain *d,
> unsigned long nr,
> mfn_t mfn)
>  {
> -return apply_p2m_changes(d, REMOVE,
> - pfn_to_paddr(gfn_x(start_gfn)),
> - pfn_to_paddr(gfn_x(start_gfn) + nr),
> - pfn_to_paddr(mfn_x(mfn)),
> - MATTR_DEV, 0, p2m_invalid,
> - d->arch.p2m.default_access);
> +return p2m_remove_mapping(d, start_gfn, nr, mfn);
>  }
>  
>  int map_dev_mmio_region(struct domain *d,
> @@ -1237,22 +1246,15 @@ int guest_physmap_add_entry(struct domain *d,
>  unsigned long page_order,
>  p2m_type_t t)
>  {
> -return 

Re: [Xen-devel] [PATCH v7 14/14] xen/arm: p2m: Rework the interface of apply_p2m_changes and use typesafe

[Stefano Stabellini]

On Tue, 12 Jul 2016, Julien Grall wrote:
> Most of the callers of apply_p2m_changes have a GFN, a MFN and the
> number of frame to change in hand.
> 
> Rather than asking each caller to convert the frame to an address,
> rework the interfaces to pass the GFN, MFN and the number of frame.
> 
> Note that it would be possible to do more clean-up in apply_p2m_changes,
> but this will be done in a follow-up series.
> 
> Signed-off-by: Julien Grall 

Acked-by: Stefano Stabellini 


> Changes in v4:
> - Patch added
> ---
>  xen/arch/arm/p2m.c | 62 
> --
>  1 file changed, 28 insertions(+), 34 deletions(-)
> 
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index de2ab05..976f97b 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -906,25 +906,26 @@ static void update_reference_mapping(struct page_info 
> *page,
>  
>  static int apply_p2m_changes(struct domain *d,
>   enum p2m_operation op,
> - paddr_t start_gpaddr,
> - paddr_t end_gpaddr,
> - paddr_t maddr,
> + gfn_t sgfn,
> + unsigned long nr,
> + mfn_t smfn,
>   int mattr,
>   uint32_t mask,
>   p2m_type_t t,
>   p2m_access_t a)
>  {
> +paddr_t start_gpaddr = pfn_to_paddr(gfn_x(sgfn));
> +paddr_t end_gpaddr = pfn_to_paddr(gfn_x(sgfn) + nr);
> +paddr_t maddr = pfn_to_paddr(mfn_x(smfn));
>  int rc, ret;
>  struct p2m_domain *p2m = >arch.p2m;
>  lpae_t *mappings[4] = { NULL, NULL, NULL, NULL };
>  struct page_info *pages[4] = { NULL, NULL, NULL, NULL };
> -paddr_t addr, orig_maddr = maddr;
> +paddr_t addr;
>  unsigned int level = 0;
>  unsigned int cur_root_table = ~0;
>  unsigned int cur_offset[4] = { ~0, ~0, ~0, ~0 };
>  unsigned int count = 0;
> -const unsigned long sgfn = paddr_to_pfn(start_gpaddr),
> -egfn = paddr_to_pfn(end_gpaddr);
>  const unsigned int preempt_count_limit = (op == MEMACCESS) ? 1 : 0x2000;
>  const bool_t preempt = !is_idle_vcpu(current);
>  bool_t flush = false;
> @@ -986,9 +987,9 @@ static int apply_p2m_changes(struct domain *d,
>   * Preempt setting mem_access permissions as required by 
> XSA-89,
>   * if it's not the last iteration.
>   */
> -uint32_t progress = paddr_to_pfn(addr) - sgfn + 1;
> +uint32_t progress = paddr_to_pfn(addr) - gfn_x(sgfn) + 1;
>  
> -if ( (egfn - sgfn) > progress && !(progress & mask) )
> +if ( nr > progress && !(progress & mask) )
>  {
>  rc = progress;
>  goto out;
> @@ -1117,8 +1118,9 @@ static int apply_p2m_changes(struct domain *d,
>  
>  if ( op == INSERT )
>  {
> -p2m->max_mapped_gfn = gfn_max(p2m->max_mapped_gfn, _gfn(egfn));
> -p2m->lowest_mapped_gfn = gfn_min(p2m->lowest_mapped_gfn, _gfn(sgfn));
> +p2m->max_mapped_gfn = gfn_max(p2m->max_mapped_gfn,
> +  gfn_add(sgfn, nr));
> +p2m->lowest_mapped_gfn = gfn_min(p2m->lowest_mapped_gfn, sgfn);
>  }
>  
>  rc = 0;
> @@ -1127,7 +1129,7 @@ out:
>  if ( flush )
>  {
>  flush_tlb_domain(d);
> -ret = iommu_iotlb_flush(d, sgfn, egfn - sgfn);
> +ret = iommu_iotlb_flush(d, gfn_x(sgfn), nr);
>  if ( !rc )
>  rc = ret;
>  }
> @@ -1146,12 +1148,14 @@ out:
>  if ( rc < 0 && ( op == INSERT ) &&
>   addr != start_gpaddr )
>  {
> +unsigned long gfn = paddr_to_pfn(addr);
> +
>  BUG_ON(addr == end_gpaddr);
>  /*
>   * addr keeps the address of the end of the last 
> successfully-inserted
>   * mapping.
>   */
> -apply_p2m_changes(d, REMOVE, start_gpaddr, addr, orig_maddr,
> +apply_p2m_changes(d, REMOVE, sgfn, gfn - gfn_x(sgfn), smfn,
>mattr, 0, p2m_invalid, d->arch.p2m.default_access);
>  }
>  
> @@ -1164,10 +1168,7 @@ static inline int p2m_insert_mapping(struct domain *d,
>   mfn_t mfn,
>   int mattr, p2m_type_t t)
>  {
> -return apply_p2m_changes(d, INSERT,
> - pfn_to_paddr(gfn_x(start_gfn)),
> - pfn_to_paddr(gfn_x(start_gfn) + nr),
> - pfn_to_paddr(mfn_x(mfn)),
> +return apply_p2m_changes(d, INSERT, start_gfn, nr, mfn,
>   mattr, 0, t, d->arch.p2m.default_access);
>  }
>  
> @@ -1176,10 +1177,7 @@ static inline int p2m_remove_mapping(struct domain *d,
>   unsigned long nr,
>

Re: [Xen-devel] [PATCH v7 10/14] xen/arm: Use the typesafes mfn and gfn in map_dev_mmio_region...

[Stefano Stabellini]

On Tue, 12 Jul 2016, Julien Grall wrote:
> to avoid mixing machine frame with guest frame. Also drop the prefix start_.
> 
> Signed-off-by: Julien Grall 

Acked-by: Stefano Stabellini 


> ---
> Changes in v6:
> - Qualify what is being mapped
> - Use PRI_mfn
> 
> Changes in v4:
> - Patch added
> ---
>  xen/arch/arm/mm.c |  2 +-
>  xen/arch/arm/p2m.c| 12 ++--
>  xen/include/asm-arm/p2m.h |  4 ++--
>  3 files changed, 9 insertions(+), 9 deletions(-)
> 
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index 0e408f8..b5fc034 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -1145,7 +1145,7 @@ int xenmem_add_to_physmap_one(
>  if ( extra.res0 )
>  return -EOPNOTSUPP;
>  
> -rc = map_dev_mmio_region(d, gfn_x(gfn), 1, idx);
> +rc = map_dev_mmio_region(d, gfn, 1, _mfn(idx));
>  return rc;
>  
>  default:
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index f11094e..5fe1b91 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -1211,20 +1211,20 @@ int unmap_mmio_regions(struct domain *d,
>  }
>  
>  int map_dev_mmio_region(struct domain *d,
> -unsigned long start_gfn,
> +gfn_t gfn,
>  unsigned long nr,
> -unsigned long mfn)
> +mfn_t mfn)
>  {
>  int res;
>  
> -if ( !(nr && iomem_access_permitted(d, mfn, mfn + nr - 1)) )
> +if ( !(nr && iomem_access_permitted(d, mfn_x(mfn), mfn_x(mfn) + nr - 1)) 
> )
>  return 0;
>  
> -res = map_mmio_regions(d, _gfn(start_gfn), nr, _mfn(mfn));
> +res = map_mmio_regions(d, gfn, nr, mfn);
>  if ( res < 0 )
>  {
> -printk(XENLOG_G_ERR "Unable to map [%#lx - %#lx] in Dom%d\n",
> -   mfn, mfn + nr - 1, d->domain_id);
> +printk(XENLOG_G_ERR "Unable to map MFNs [%#"PRI_mfn" - %#"PRI_mfn" 
> in Dom%d\n",
> +   mfn_x(mfn), mfn_x(mfn) + nr - 1, d->domain_id);
>  return res;
>  }
>  
> diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
> index 4752161..8d29eda 100644
> --- a/xen/include/asm-arm/p2m.h
> +++ b/xen/include/asm-arm/p2m.h
> @@ -152,9 +152,9 @@ int unmap_regions_rw_cache(struct domain *d,
> unsigned long mfn);
>  
>  int map_dev_mmio_region(struct domain *d,
> -unsigned long start_gfn,
> +gfn_t gfn,
>  unsigned long nr,
> -unsigned long mfn);
> +mfn_t mfn);
>  
>  int guest_physmap_add_entry(struct domain *d,
>  gfn_t gfn,
> -- 
> 1.9.1
> 

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

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

[Daniel De Graaf]

On 07/13/2016 08:59 AM, Anshul Makkar wrote:

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

Signed-off-by: Anshul Makkar 


This seems to indicate that getpodtarget should also be added to the list.

Either as-is or with getpodtarget also added,
Acked-by: Daniel De Graaf 

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

Re: [Xen-devel] [DRAFT v2] XenSock protocol design document

[Stefano Stabellini]

On Wed, 13 Jul 2016, Andrew Cooper wrote:
> On 13/07/16 16:47, Stefano Stabellini wrote:
> > Hi all,
> >
> > This is the design document of the XenSock protocol. You can find
> > prototypes of the Linux frontend and backend drivers here:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git xensock-2
> >
> > To use them, make sure to enable CONFIG_XENSOCK in your kernel config
> > and add "xensock=1" to the command line of your DomU Linux kernel. You
> > also need the toolstack to create the initial xenstore nodes for the
> > protocol. To do that, please apply the attached patch to libxl (the
> > patch is based on Xen 4.7.0-rc3) and add "xensock=1" to your DomU config
> > file.
> 
> diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
> index 9e48199..478eb0a 100644
> --- a/net/ipv4/af_inet.c
> +++ b/net/ipv4/af_inet.c
> @@ -120,6 +120,7 @@
>  #include 
>  #endif
>  #include 
> +#include 
>  
>  
>  /* The inetsw table contains everything that inet_create needs to
> @@ -1775,6 +1776,11 @@ static int __init inet_init(void)
>  for (r = [0]; r < [SOCK_MAX]; ++r)
>  INIT_LIST_HEAD(r);
>  
> +if (xensock) {
> +pr_info("Enabling xensock for AF_INET SOCK_STREAM\n");
> +inetsw_array[0].ops = _stream_ops;
> +}
> +
>  for (q = inetsw_array; q < _array[INETSW_ARRAY_LEN]; ++q)
>  inet_register_protosw(q);
>  
> 
> I am curious as to how you plan to persuade Dave Miller to take this patch?
>
> What is your planned mitigation for the fact that INET sockets stop
> behaving like INET sockets.

Let me premise that obviously those 4 lines of code are unlikely to be
the way this code will actually be merged in Linux. As I said these are
just prototypes. But they are far better than the very first version I
had :-)

That's the chicken and egg problem: I cannot really have a proper
conversation about it on the LKML until the protocol is, if not
accepted, at least a bit farther down the review process. In my
experience discussing about design docs on the LKML doesn't work well --
they want to see the code first. Once the design is somewhat "settled",
I'll engage with netdev. They are the ones with the best expertize on
how to integrate this work in Linux.

I did have informal conversations with two or three Linux maintainers
(but not Dave Miller) -- they seemed positive about it and they thought
XenSock is useful. We'll have to see.

At the end of the day, if the Linux drivers are no-go, the protocol can
still be used for fully userspace implementations or other OSes.


> Are there any plans for IPv6?

I don't have any at the moment, but I would be happy to see that
happening.

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

[Xen-devel] [patch V2 49/67] arm/xen: Convert to hotplug state machine

[Anna-Maria Gleixner]

From: Richard Cochran 

Install the callbacks via the state machine and let the core invoke
the callbacks on the already online CPUs.

The get_cpu() in xen_starting_cpu() boils down to preempt_disable() since
we already know the CPU we run on. Disabling preemption shouldn't be required
here from what I see since it we don't switch CPUs while invoking the function.

Signed-off-by: Richard Cochran 
Reviewed-by: Sebastian Andrzej Siewior 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Russell King 
Cc: Stefano Stabellini 
Cc: Stefano Stabellini 
Cc: Thomas Gleixner 
Cc: linux-arm-ker...@lists.infradead.org
Cc: xen-de...@lists.xenproject.org
Signed-off-by: Anna-Maria Gleixner 
---
 arch/arm/xen/enlighten.c   | 41 +++--
 include/linux/cpuhotplug.h |  1 +
 2 files changed, 12 insertions(+), 30 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 75cd734..d822e23 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -161,12 +161,11 @@ static struct notifier_block xen_pvclock_gtod_notifier = {
.notifier_call = xen_pvclock_gtod_notify,
 };
 
-static void xen_percpu_init(void)
+static int xen_starting_cpu(unsigned int cpu)
 {
struct vcpu_register_vcpu_info info;
struct vcpu_info *vcpup;
int err;
-   int cpu = get_cpu();
 
/* 
 * VCPUOP_register_vcpu_info cannot be called twice for the same
@@ -190,7 +189,13 @@ static void xen_percpu_init(void)
 
 after_register_vcpu_info:
enable_percpu_irq(xen_events_irq, 0);
-   put_cpu();
+   return 0;
+}
+
+static int xen_dying_cpu(unsigned int cpu)
+{
+   disable_percpu_irq(xen_events_irq);
+   return 0;
 }
 
 static void xen_restart(enum reboot_mode reboot_mode, const char *cmd)
@@ -209,28 +214,6 @@ static void xen_power_off(void)
BUG_ON(rc);
 }
 
-static int xen_cpu_notification(struct notifier_block *self,
-   unsigned long action,
-   void *hcpu)
-{
-   switch (action) {
-   case CPU_STARTING:
-   xen_percpu_init();
-   break;
-   case CPU_DYING:
-   disable_percpu_irq(xen_events_irq);
-   break;
-   default:
-   break;
-   }
-
-   return NOTIFY_OK;
-}
-
-static struct notifier_block xen_cpu_notifier = {
-   .notifier_call = xen_cpu_notification,
-};
-
 static irqreturn_t xen_arm_callback(int irq, void *arg)
 {
xen_hvm_evtchn_do_upcall();
@@ -351,16 +334,14 @@ static int __init xen_guest_init(void)
return -EINVAL;
}
 
-   xen_percpu_init();
-
-   register_cpu_notifier(_cpu_notifier);
-
pv_time_ops.steal_clock = xen_stolen_accounting;
static_key_slow_inc(_steal_enabled);
if (xen_initial_domain())
pvclock_gtod_register_notifier(_pvclock_gtod_notifier);
 
-   return 0;
+   return cpuhp_setup_state(CPUHP_AP_ARM_XEN_STARTING,
+"AP_ARM_XEN_STARTING", xen_starting_cpu,
+xen_dying_cpu);
 }
 early_initcall(xen_guest_init);
 
diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h
index 86ac982..f986963 100644
--- a/include/linux/cpuhotplug.h
+++ b/include/linux/cpuhotplug.h
@@ -48,6 +48,7 @@ enum cpuhp_state {
CPUHP_AP_KVM_STARTING,
CPUHP_AP_KVM_ARM_VGIC_STARTING,
CPUHP_AP_KVM_ARM_TIMER_STARTING,
+   CPUHP_AP_ARM_XEN_STARTING,
CPUHP_AP_LEDTRIG_STARTING,
CPUHP_AP_NOTIFY_STARTING,
CPUHP_AP_ONLINE,
-- 
2.8.1




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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

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

Last test of basis96794  2016-07-08 15:01:26 Z5 days
Failing since 97261  2016-07-13 11:00:54 Z0 days3 attempts
Testing same since97274  2016-07-13 15:02:31 Z0 days1 attempts


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

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



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

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

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

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


Pushing revision :

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

Re: [Xen-devel] [DRAFT v2] XenSock protocol design document

[Andrew Cooper]

On 13/07/16 16:47, Stefano Stabellini wrote:
> Hi all,
>
> This is the design document of the XenSock protocol. You can find
> prototypes of the Linux frontend and backend drivers here:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git xensock-2
>
> To use them, make sure to enable CONFIG_XENSOCK in your kernel config
> and add "xensock=1" to the command line of your DomU Linux kernel. You
> also need the toolstack to create the initial xenstore nodes for the
> protocol. To do that, please apply the attached patch to libxl (the
> patch is based on Xen 4.7.0-rc3) and add "xensock=1" to your DomU config
> file.

diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index 9e48199..478eb0a 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -120,6 +120,7 @@
 #include 
 #endif
 #include 
+#include 
 
 
 /* The inetsw table contains everything that inet_create needs to
@@ -1775,6 +1776,11 @@ static int __init inet_init(void)
 for (r = [0]; r < [SOCK_MAX]; ++r)
 INIT_LIST_HEAD(r);
 
+if (xensock) {
+pr_info("Enabling xensock for AF_INET SOCK_STREAM\n");
+inetsw_array[0].ops = _stream_ops;
+}
+
 for (q = inetsw_array; q < _array[INETSW_ARRAY_LEN]; ++q)
 inet_register_protosw(q);
 

I am curious as to how you plan to persuade Dave Miller to take this patch?

What is your planned mitigation for the fact that INET sockets stop
behaving like INET sockets.  Are there any plans for IPv6?

~Andrew

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

[Xen-devel] [DRAFT v2] XenSock protocol design document

[Stefano Stabellini]

Hi all,

This is the design document of the XenSock protocol. You can find
prototypes of the Linux frontend and backend drivers here:

git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git xensock-2

To use them, make sure to enable CONFIG_XENSOCK in your kernel config
and add "xensock=1" to the command line of your DomU Linux kernel. You
also need the toolstack to create the initial xenstore nodes for the
protocol. To do that, please apply the attached patch to libxl (the
patch is based on Xen 4.7.0-rc3) and add "xensock=1" to your DomU config
file.

Cheers,

Stefano


Changes in v2:
- add max-dataring-page-order
- add "Publish backend features and transport parameters" to backend
  xenbus workflow
- update new cmd values
- update xen_xensock_request
- add backlog parameter to listen and binary layout
- add description of new data ring format (interface+data)
- modify connect and accept to reflect new data ring format
- add link to POSIX docs
- add error numbers
- add address format section and relevant numeric definitions
- add explicit mention of unimplemented commands
- add protocol node name
- add xenbus shutdown diagram
- add socket operation

---

# XenSocks Protocol v1

## Rationale

XenSocks is a paravirtualized protocol for the POSIX socket API.

The purpose of XenSocks is to allow the implementation of a specific set
of POSIX functions to be done in a domain other than your own. It allows
connect, accept, bind, release, listen, poll, recvmsg and sendmsg to be
implemented in another domain.

XenSocks provides the following benefits:
* guest networking works out of the box with VPNs, wireless networks and
  any other complex configurations on the host
* guest services listen on ports bound directly to the backend domain IP
  addresses
* localhost becomes a secure namespace for inter-VMs communications
* full visibility of the guest behavior on the backend domain, allowing
  for inexpensive filtering and manipulation of any guest calls
* excellent performance


## Design

### Xenstore

The frontend and the backend connect to each other exchanging information via
xenstore. The toolstack creates front and back nodes with state
XenbusStateInitialising. The protocol node name is **xensock**. There can only
be one XenSock frontend per domain.

 Frontend XenBus Nodes

port
 Values: 

 The identifier of the Xen event channel used to signal activity
 in the ring buffer.

ring-ref
 Values: 

 The Xen grant reference granting permission for the backend to map
 the sole page in a single page sized ring buffer.

 Backend XenBus Nodes

max-dataring-page-order
Values: 

The maximum supported size of the data ring in units of lb(machine
pages). (e.g. 0 == 1 page,  1 = 2 pages, 2 == 4 pages, etc.).

 State Machine

Initialization:

*Front*   *Back*
XenbusStateInitialising   XenbusStateInitialising
- Query virtual device- Query backend device
  properties.   identification data.
- Setup OS device instance.   - Publish backend features
- Allocate and initialize the   and transport parameters
  request ring.  |
- Publish transport parameters   |
  that will be in effect during  V
  this connection.XenbusStateInitWait
 |
 |
 V
   XenbusStateInitialised

  - Query frontend transport parameters.
  - Connect to the request ring and
event channel.
 |
 |
 V
 XenbusStateConnected

 - Query backend device properties.
 - Finalize OS virtual device
   instance.
 |
 |
 V
XenbusStateConnected

Once frontend and backend are connected, they have a shared page, which
will is used to exchange messages over a ring, and an event channel,
which is used to send notifications.

Shutdown:

*Front**Back*
XenbusStateConnected   XenbusStateConnected
|
|
V
   XenbusStateClosing

   - Unmap grants
   - Unbind evtchns
 |
 |
 V
 XenbusStateClosing

- Unbind evtchns
- Free rings
- Free data structures
   

Re: [Xen-devel] No graphics with xen pv and Fedora qemu

[Andrew Cooper]

On 10/07/16 16:44, Michael Young wrote:
> On Wed, 29 Jun 2016, Michael Young wrote:
>
>> I have been trying to trace a problem when using Fedora's qemu with a
>> pv guest which is that no graphics are available. I get the errors
>>
>> xen be core: xen be: watching backend path (backend/console/2) failed
>> xen be core: xen be: watching backend path (backend/vkbd/2) failed
>> xen be core: xen be: watching backend path (backend/vfb/2) failed
>> xen be core: xen be: watching backend path (backend/qdisk/2) failed
>> xen be core: xen be: watching backend path (backend/qnic/2) failed
>>
>> in the qemu log file in /var/log/xen . So far I have traced it to rbd
>> support in qemu, because qemu-system-i386 built with the
>> --disable-rbd does have working graphics.
>
> I tracked this down eventually. The failure is in tools/xenstore/xs.c
> in xs_watch when it tries to create a read pthread, because the
> initial stack size of 16384 is apparently too small with qemu with rbd
> enabled. I did get it to work if I increased the stack size to 24576.

This is rather curious (and confusing).

I presume this is the xenstore reader thread in qemu which is causing
problems?

The stack size of the reader thread shouldn't need to be big at all, and
I can't see why rbd specifically would cause an issue.  Is there a stack
overflow happening?

~Andrew

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

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

[Julien Grall]

Hello,

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

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

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

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

On 2016年07月12日 22:50, Wei Liu wrote:

On Tue, Jul 12, 2016 at 10:42:07PM +0800, Shannon Zhao wrote:

Does it mean we would need to update the slack
to take into account the ACPI
blob?

Yes, we need to take into account the ACPI blob.
Probably not in the
slack but directly in mam_memkb.

Sorry, I'm not sure understand this. I found the
b_info->max_memkb but
didn't find the slack you said. And how to fix this? Update
b_info->max_memkb or the slack?

Can you calculate the size of your payload and add that to
max_memkb?


Yeah, but the size will be changed if we change the tables in the
future
and this also should consider x86, right?

That could easily be solved by introducing a function to calculate the
size, right?

Oh, I'm not familiar with this. Let's clarify on this. It can add the
size to max_memkb after generating the ACPI tables and before loading
the tables to guest space and it doesn't have to add the size at
libxl__domain_build_info_setdefault(), right?


This was discussed before: ACPI tables are part of RAM whose size is
specified by the config file (and is reflected in max_memkb I believe).
It may not be presented to the guest as RAM (i.e. on x86 it is labeled
by BIOS (or whoever) as a dedicated type in e820) but it still resides
in DIMMs.


I don't think this was the conclusion of the thread. IHMO, "maxmem" is
the amount of RAM a guest could effectively use.

Whilst the ACPI tables will be in the DIMM from the host point of
view. From a guest point of view it will be a ROM.


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


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






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

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


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


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


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


May I ask why you want to keep maxmem unchanged on x86?

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 1/6] xen/build: Allow the use of C freestanding headers

[Tim Deegan]

At 14:46 +0100 on 13 Jul (1468421211), Andrew Cooper wrote:
> On 22/06/16 14:12, Tim Deegan wrote:
> > At 12:24 +0100 on 22 Jun (1466598248), Andrew Cooper wrote:
> >> The C standard defines two types of conforming implementation; hosted and
> >> freestanding.  A subset of the standard headers are the freestanding 
> >> headers,
> >> requiring no library support at all to use, and therefore usable by Xen.
> >>
> >> Unfortunately, -nostdinc is an overly large switch, and there is no
> >> alternative to only permit inclusion of the freestanding headers.  
> >> Removing it
> >> is unfortunate, as we lose the protection it offers, but anyone who does 
> >> try
> >> to use other parts of the standard library will still fail to link.
> > I'm afraid I don't think this is a good idea:
> >  - Leaving the standard include path around in the Xen build means
> >that the build may differ based on what (unrelated) libraries are
> >installed on the build machines.
> >  - There are plenty of ways for an unexpected header to break things
> >that don't fail at link time, e.g. macros and inlines.
> >  - "Freestanding" headers can bring in quite a lot of unrelated cruft.
> >See Jan's email about linux/glibc, and I remember seeing similar
> >things on solaris and *BSD when I tidied up stdarg.h. E.g. looking
> >at two machines I'm working on today, on one of them,
> >#include  defines __packed, and on the other it does not.
> >
> > Since what we have already works fine for all the compilers we
> > support, I think it ain't broke and we shouldn't fix it.
> 
> Except it is broken.

Broken in theory or actually causing a problem right now?

> We cannot expect to use -Wformat and not the compiler provided
> inttypes.h.

Since we're not using the compiler-provided printf(), I think that
we're on pretty thin ice with -Wformat anyway.  But as long as our
own PRI* macros match our type definitions, all should be well, right?

> The sizes of constructs like "long long" are implementation
> defined, not spec defined.  The compiler is perfectly free to choose
> something which doesn't match our inttypes.h, and we would be in the
> wrong when it fails to compile.

If a compiler we support does that, we can update our integer type
definitions, like we do for attribute annotations, 

BTW, I can absolutely see the argument for deferring to the compiler
in C implementation details.  I think that would have to include
removing all the implementation-reserved names from Xen so we don't
clash with compiler headers.

But in practice it seems to be messy enough to be better avoided --
having /usr/include on the search path is pretty silly.

Tim.

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

Re: [Xen-devel] [PATCH] xl: add option to leave domain paused afer migration

[Wei Liu]

On Wed, Jul 13, 2016 at 10:53:13AM +0200, Roger Pau Monne wrote:
> This is useful for debugging domains that crash on resume from migration.
> 
> Signed-off-by: Roger Pau Monné 

This sounds like a useful thing to have and the patch looks good.

But you forgot to patch xl(1) manpage.

Wei.

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

Re: [Xen-devel] xenstored memory leak

[Juergen Gross]

On 13/07/16 16:28, Ian Jackson wrote:
> David Vrabel writes ("Re: [Xen-devel] xenstored memory leak"):
>> On 13/07/16 14:32, Juergen Gross wrote:
>>> On 13/07/16 15:17, David Vrabel wrote:
 The Linux driver already cleans up open transactions and removes watches
 when the file handle is released.
>>>
>>> Hmm, does this work reliably? I observed a memory leak of about 5kB per
>>> create/destroy domain pair with xenstored _and_ with xenstore domain.
>>
>> Don't know.
>>
>> I only took a quick look at the xenbus_file_release() function and it
>> looked like it ought to be doing the right thing...
> 
> If it didn't, it would leak with oxenstored too.

This I can't tell. I've got no oxenstore domain running.


Juergen

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf   5 xen-build fail REGR. vs. 96794

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  1fb0fe97a647549cc1bbe90f15b6cb2fcc3f79b6
baseline version:
 xen  7da483b0236d8974cc97f81780dcf8e559a63175

Last test of basis96794  2016-07-08 15:01:26 Z4 days
Testing same since97261  2016-07-13 11:00:54 Z0 days2 attempts


People who touched revisions under test:
  Corneliu ZUZU 
  Ian Jackson 
  Juergen Gross 
  Julien Grall 
  Kevin Tian 
  Stefano Stabellini 
  Wei Liu 

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



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

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

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

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


Not pushing.


commit 1fb0fe97a647549cc1bbe90f15b6cb2fcc3f79b6
Author: Corneliu ZUZU 
Date:   Sat Jul 9 07:12:07 2016 +0300

x86/vmx_update_guest_cr: minor optimization

Minor optimization @ vmx_update_guest_cr: checks if 
v->arch.hvm_vmx.exec_control
was modified before actually calling vmx_update_cpu_exec_control(v).

Signed-off-by: Corneliu ZUZU 
Acked-by: Kevin Tian 

commit 22ea8ad02e465e32cd40887c750b55c3a997a288
Author: Juergen Gross 
Date:   Wed Jul 6 16:55:34 2016 +0200

libxl: move DEFINE_DEVICE* macros to libxl_internal.h

In order to be able to have all functions related to a device type in
a single source file move the macros used to generate device type
specific functions to libxl_internal.h. Rename the macros as they are
no longer local to a source file. While at it hide device remove and
device destroy in one macro as those are always used in pairs. Move
usage of the macros to the appropriate source files.

Signed-off-by: Juergen Gross 
Acked-by: Ian Jackson 

commit 2c2c33f038c889acc9f73681c09320164516da47
Author: Juergen Gross 
Date:   Wed Jul 6 16:55:33 2016 +0200

libxl: refactor domcreate_attach_dtdev() to use device type framework

Signed-off-by: Juergen Gross 
Acked-by: Ian Jackson 

commit 26021d77dc14d441ff3b0094f2fafcc5d18aa599
Author: Juergen Gross 
Date:   Wed Jul 6 16:55:32 2016 +0200

libxl: refactor domcreate_attach_pci() to use device type framework

Signed-off-by: Juergen Gross 
Acked-by: Ian Jackson 

commit 74e857c6c7f9dc106fa7a7bbf49a9729f5841ad9
Author: Juergen Gross 
Date:   Wed Jul 6 16:55:31 2016 +0200

libxl: add framework for device types

Instead of duplicate coding for each device type (vtpms, usbctrls, ...)
especially on domain creation introduce a framework for that purpose.

Signed-off-by: Juergen Gross 
Acked-by: Ian Jackson 

commit 56bac262e097684b20f7753ceb6debe594e9725c
Author: Wei Liu 
Date:   Wed Jun 8 15:01:02 2016 +0100

libxl: only issue cpu-add call to QEMU for not present CPU

Calculate the final bitmap for CPUs to add to avoid having annoying
error messages complaining those CPUs are already present. Example
message is like (wrapped):

libxl: error: libxl_qmp.c:287:qmp_handle_error_response: received an
error message from QMP server: Unable to add CPU: 0, it 

Re: [Xen-devel] ACPI builder re-licensing

[Lars Kurth]

On 13/07/2016 15:22, "Boris Ostrovsky"  wrote:

>On 07/13/2016 09:21 AM, Lars Kurth wrote:
>> Boris,
>>
>> I can't remember how we managed this process the last time round (see
>>for https://patchwork.kernel.org/patch/9172431/), but in that case we
>>already had a patch. As far as I can see, we don't have the complete
>>patch yet.
>>
>> Thus, the question I would have to you is whether you want to prepare
>>the complete patch first or get the approvals of all stake-holders first?
>
>I certainly can (and should) prepare and post the patch but I thought we
>should first come up with (A) list at the least.

It's basically in this thread already and is
- Kouya Shimura 
- Daniel's old private e-mail address, if still active.
- Stefan Berger 
- Simon Horman 
- Keir 
 
Possibly Paolo

>OTOH, we can at least
>review the patch first here on xen-devel without bothering people from
>that list with revisions. So yes, I will.
...
>
>Will do and post as the preamble to the patch for review.

Thanks

Regards
Lars

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

Re: [Xen-devel] xenstored memory leak

[Ian Jackson]

David Vrabel writes ("Re: [Xen-devel] xenstored memory leak"):
> On 13/07/16 14:32, Juergen Gross wrote:
> > On 13/07/16 15:17, David Vrabel wrote:
> >> The Linux driver already cleans up open transactions and removes watches
> >> when the file handle is released.
> > 
> > Hmm, does this work reliably? I observed a memory leak of about 5kB per
> > create/destroy domain pair with xenstored _and_ with xenstore domain.
> 
> Don't know.
> 
> I only took a quick look at the xenbus_file_release() function and it
> looked like it ought to be doing the right thing...

If it didn't, it would leak with oxenstored too.

Ian.

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

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

[Corneliu ZUZU]

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

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

Signed-off-by: Corneliu ZUZU 
Suggested-by: Andrew Cooper 
Reviewed-by: Andrew Cooper 
---
Changed since v1:
  * removed comments that were duplicate between asm-x86/atomic.h and
xen/atomic.h
  * remove outdated comment ("NB. [...]")
  * add atomic_cmpxchg doc-comment
  * don't use yoda condition
---
 xen/include/asm-arm/atomic.h |  45 
 xen/include/asm-x86/atomic.h | 103 +-
 xen/include/xen/atomic.h | 171 +++
 3 files changed, 202 insertions(+), 117 deletions(-)
 create mode 100644 xen/include/xen/atomic.h

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

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

[Corneliu ZUZU]

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

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

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

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


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

Re: [Xen-devel] ACPI builder re-licensing

[Boris Ostrovsky]

On 07/13/2016 09:21 AM, Lars Kurth wrote:
> Boris,
>
> I can't remember how we managed this process the last time round (see for 
> https://patchwork.kernel.org/patch/9172431/), but in that case we already had 
> a patch. As far as I can see, we don't have the complete patch yet.
>
> Thus, the question I would have to you is whether you want to prepare the 
> complete patch first or get the approvals of all stake-holders first?

I certainly can (and should) prepare and post the patch but I thought we
should first come up with (A) list at the least. OTOH, we can at least
review the patch first here on xen-devel without bothering people from
that list with revisions. So yes, I will.

>
> I also think we should establish two groups of people regardless of approach
> A) A list of individuals with e-mails we need to get approval from 
> B) A list of company reps which can provide approval on behalf of a companies 
> contribution
>
> What we did in https://patchwork.kernel.org/patch/9172431/ was to get ACKs 
> from people in group A, and e-mail confirmation from people in group B.
>
> Regardless of the approach, we also ought to write an explanation that is 
> easily consumable for people in group B which may not be very involved in Xen.
> - A short introduction outlining what see are trying to do and why (maybe 
> refer back to this thread)
> - Explain why we sent the explanation to person X (that would probably need 
> to contain some boilerplate what (c) they and/or their orgs hold and why we 
> contacted them)
> - End with a question which they clearly can answer (and which we can copy as 
> evidence into the changelog)
>
> Would you be able to draft something? We can then distribute some of the 
> activities based on existing personal relationships.


Will do and post as the preamble to the patch for review.


>
>> On 12 Jul 2016, at 18:09, Ian Jackson  wrote:
>>
>> Boris Ostrovsky writes ("[Xen-devel] ACPI builder re-licensing"):
>>> Who needs to be notified
>>> ===
>> NB that what is required is not notification, but permission.
>>
>>> which indicated major contributions (and therefore a required ack) from
>>> Citrix/Xensource, Suse/Novell, Oracle/Sun, Intel.
> This is group B stuff
> - Citrix/Xensource can be James Bulpin or me
> - Suse/Novell can be arranged by Jan or Juergen 
> - Intel ought to be Susie Li 
> - Oracle/Sun can be arranged by Konrad or you

Konrad is already doing this for Oracle.

>
> Could you double check whether any of these maybe should go into group A? 

Changes from those companies came from multiple submitters so it seems
that getting a single ACK from a rep would be easier?


...

>>> * net-space.pl is Daniel Kiper's (now, but not at the patch's time, at
>>> Oracle) ISP. The patch is
>>>
>>> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=37fddaa5fe1a7e369827e4b9e25cdae5df9b3d7d
>> This patch is not trivial in copyright terms, so we need Daniel
>> Kiper's approval.
> We have Daniel's e-mail address, so this should go into group A. Not sure 
> whether Daniel uses his old address still, which would be preferable.

I spoke with Daniel and he is fine ACKing this.

>
>>> * redhat is one trivial patch by Paolo Bonzini that has been reversed later:
>>>
>>> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=e4fd0475a08fda414da27c4e57b568f147cfc07e
>> If the patch has been reverted then we are not proposing to relicence.
>> We need to be careful not to re-apply it without getting a new signoff
>> from Red Hat.
> We ought to check that. If not true, Paolo Bonzini should go into group A.

In principle we could in the future decide to do exactly what Paolo's
patch originally did (which was to remove the 'if' condition). There is
no way to do it any differently than how Paolo's patch did it.

-boris



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

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

[Corneliu ZUZU]

Reorder macro definitions to match x86-side.

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

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


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

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

[Corneliu ZUZU]

Place atomic_inc_and_test() implementation after atomic_inc().
Also remove unneeded empty line and add a needed one.

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

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


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

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

[Corneliu ZUZU]

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

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

diff --git a/xen/include/asm-arm/arm32/atomic.h 
b/xen/include/asm-arm/arm32/atomic.h
index 7ec712f..be08ff1 100644
--- a/xen/include/asm-arm/arm32/atomic.h
+++ b/xen/include/asm-arm/arm32/atomic.h
@@ -149,17 +149,6 @@ static inline int __atomic_add_unless(atomic_t *v, int a, 
int u)
 
 #define atomic_xchg(v, new) (xchg(&((v)->counter), new))
 
-#define atomic_inc(v)  atomic_add(1, v)
-#define atomic_dec(v)  atomic_sub(1, v)
-
-#define atomic_inc_and_test(v) (atomic_add_return(1, v) == 0)
-#define atomic_dec_and_test(v) (atomic_sub_return(1, v) == 0)
-#define atomic_inc_return(v)(atomic_add_return(1, v))
-#define atomic_dec_return(v)(atomic_sub_return(1, v))
-#define atomic_sub_and_test(i, v) (atomic_sub_return(i, v) == 0)
-
-#define atomic_add_negative(i,v) (atomic_add_return(i, v) < 0)
-
 #endif /* __ARCH_ARM_ARM32_ATOMIC__ */
 /*
  * Local variables:
diff --git a/xen/include/asm-arm/arm64/atomic.h 
b/xen/include/asm-arm/arm64/atomic.h
index b49219e..80d07bf 100644
--- a/xen/include/asm-arm/arm64/atomic.h
+++ b/xen/include/asm-arm/arm64/atomic.h
@@ -125,17 +125,6 @@ static inline int __atomic_add_unless(atomic_t *v, int a, 
int u)
return c;
 }
 
-#define atomic_inc(v)  atomic_add(1, v)
-#define atomic_dec(v)  atomic_sub(1, v)
-
-#define atomic_inc_and_test(v) (atomic_add_return(1, v) == 0)
-#define atomic_dec_and_test(v) (atomic_sub_return(1, v) == 0)
-#define atomic_inc_return(v)(atomic_add_return(1, v))
-#define atomic_dec_return(v)(atomic_sub_return(1, v))
-#define atomic_sub_and_test(i, v) (atomic_sub_return(i, v) == 0)
-
-#define atomic_add_negative(i,v) (atomic_add_return(i, v) < 0)
-
 #endif
 /*
  * Local variables:
diff --git a/xen/include/asm-arm/atomic.h b/xen/include/asm-arm/atomic.h
index 29ab265..41d1b6c 100644
--- a/xen/include/asm-arm/atomic.h
+++ b/xen/include/asm-arm/atomic.h
@@ -138,6 +138,17 @@ static inline void _atomic_set(atomic_t *v, int i)
 # error "unknown ARM variant"
 #endif
 
+#define atomic_inc(v)   atomic_add(1, v)
+#define atomic_dec(v)   atomic_sub(1, v)
+
+#define atomic_inc_and_test(v)  (atomic_add_return(1, v) == 0)
+#define atomic_dec_and_test(v)  (atomic_sub_return(1, v) == 0)
+#define atomic_inc_return(v)(atomic_add_return(1, v))
+#define atomic_dec_return(v)(atomic_sub_return(1, v))
+#define atomic_sub_and_test(i, v) (atomic_sub_return(i, v) == 0)
+
+#define atomic_add_negative(i,v) (atomic_add_return(i, v) < 0)
+
 #endif /* __ARCH_ARM_ATOMIC__ */
 /*
  * Local variables:
-- 
2.5.0


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

Re: [Xen-devel] xenstored memory leak

[Wei Liu]

On Wed, Jul 13, 2016 at 04:09:26PM +0200, Juergen Gross wrote:
> On 13/07/16 15:52, Wei Liu wrote:
> > On Wed, Jul 13, 2016 at 03:25:45PM +0200, Juergen Gross wrote:
> >> On 13/07/16 15:07, Wei Liu wrote:
> >>> On Wed, Jul 13, 2016 at 02:21:38PM +0200, Juergen Gross wrote:
>  On 06/07/16 09:31, Juergen Gross wrote:
> > While testing some patches for support of ballooning in Mini-OS by using
> > the xenstore domain I realized that each xl create/destroy pair would
> > increase memory consumption in Mini-OS by about 5kB. Wondering whether
> > this is a xenstore domain only effect I did the same test with xenstored
> > and oxenstored daemons.
> >
> > xenstored showed the same behavior, the "referenced" size showed by the
> > pmap command grew by about 5kB for each create/destroy pair.
> >
> > oxenstored seemed to be even worse in the beginning (about 6kB for each
> > pair), but after about 100 create/destroys the value seemed to be
> > rather stable.
> >
> > Did anyone notice this memory leak before?
> 
>  I think I've found the problem:
> 
>  qemu as the device model is setting up a xenstore watch for each backend
>  type it is supporting. Unfortunately those watches are never removed
>  again. This sums up to the observed memory leak.
> 
>  I'm not sure how oxenstored is avoiding the problem, may be by testing
>  socket connections to be still alive and so detecting qemu has gone.
>  OTOH this won't help for oxenstored running in another domain than the
>  device model (either due to oxenstore-stubdom, or a driver domain with
>  a qemu based device model).
> 
> >>>
> >>> How unfortunate.
> >>>
> >>> My gut feeling is that xenstored shouldn't have the knowledge to
> >>> associate a watch with a "process". The concept of a process is only
> >>> meaningful to OS, which wouldn't work on cross-domain xenstored setup.
> >>
> >> Right.
> >>
> >>> Maybe the OS xenbus driver should reap all watches on behalf the dead
> >>> process. This would also avoid a crashed QEMU leaking resources.
> >>>
> >>> And xenstored should have proper quota support so that a domain can't
> >>> set up excessive numbers of watches.
> >>
> >> This would be dom0 unless you arrange the device model to be accounted
> >> as the domid it is running for. But this is problematic with a xenstore
> >> domain again.
> >>
> > 
> > The quota could be based on "connection" (ring or socket) and
> > counted as per-connection? Just throwing ideas around, not necessarily
> > saying this is the way to go.
> 
> Sure. But with xenstore domain all xenstore access of dom0 is via one
> ring. And how would you want to apply any quota here solving our
> problem with one qemu process in dom0 creating stale watches? You

That's a job for the kernel driver.

The quota inside xenstored is to protect itself from abuse from one
single connection and punish the bad actors.

> could open a new connection for the device model, of course, but this
> would require some xenbus rework.
> 

I wouldn't go down that route unless absolutely necessary  because that
seems to require xenbus protocol extension.

Wei.

> 
> Juergen

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

[Xen-devel] [PATCH v2 0/5] adjustments

[Corneliu ZUZU]

Corneliu ZUZU (5):
  asm-arm/atomic.h: fix arm32|arm64 macros duplication
  asm-x86/atomic.h: minor: proper atomic_inc_and_test() placement
  asm-arm/atomic.h: reorder macros to match x86-side
  asm/atomic.h: common prototyping (add xen/atomic.h)
  fix: make atomic_read() param const

 xen/include/asm-arm/arm32/atomic.h |  11 ---
 xen/include/asm-arm/arm64/atomic.h |  11 ---
 xen/include/asm-arm/atomic.h   |  46 +++---
 xen/include/asm-x86/atomic.h   | 128 +++
 xen/include/xen/atomic.h   | 171 +
 5 files changed, 220 insertions(+), 147 deletions(-)
 create mode 100644 xen/include/xen/atomic.h

-- 
2.5.0


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

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

[Wei Liu]

On Tue, Jul 12, 2016 at 04:21:00PM +, Rusty Bird wrote:
> Hello Wei,
> 
> For systemd/xendriverdomain.service.in, the hardcoded PID file could be
> removed altogether -- systemd has no trouble figuring out the PID with
> only one process. But I wasn't sure if maybe something outside of the
> xen tree uses it?

Oh, thanks for the heads-up. I will just remove the path with a separate
patch if that's not very useful.

Out-of-tree users have the option patch the script as they see fit. But
if they use systemd it would be better to use the "systemd-way" to
obtain the pid anyway.

Wei.

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

Re: [Xen-devel] xenstored memory leak

[Juergen Gross]

On 13/07/16 15:52, Wei Liu wrote:
> On Wed, Jul 13, 2016 at 03:25:45PM +0200, Juergen Gross wrote:
>> On 13/07/16 15:07, Wei Liu wrote:
>>> On Wed, Jul 13, 2016 at 02:21:38PM +0200, Juergen Gross wrote:
 On 06/07/16 09:31, Juergen Gross wrote:
> While testing some patches for support of ballooning in Mini-OS by using
> the xenstore domain I realized that each xl create/destroy pair would
> increase memory consumption in Mini-OS by about 5kB. Wondering whether
> this is a xenstore domain only effect I did the same test with xenstored
> and oxenstored daemons.
>
> xenstored showed the same behavior, the "referenced" size showed by the
> pmap command grew by about 5kB for each create/destroy pair.
>
> oxenstored seemed to be even worse in the beginning (about 6kB for each
> pair), but after about 100 create/destroys the value seemed to be
> rather stable.
>
> Did anyone notice this memory leak before?

 I think I've found the problem:

 qemu as the device model is setting up a xenstore watch for each backend
 type it is supporting. Unfortunately those watches are never removed
 again. This sums up to the observed memory leak.

 I'm not sure how oxenstored is avoiding the problem, may be by testing
 socket connections to be still alive and so detecting qemu has gone.
 OTOH this won't help for oxenstored running in another domain than the
 device model (either due to oxenstore-stubdom, or a driver domain with
 a qemu based device model).

>>>
>>> How unfortunate.
>>>
>>> My gut feeling is that xenstored shouldn't have the knowledge to
>>> associate a watch with a "process". The concept of a process is only
>>> meaningful to OS, which wouldn't work on cross-domain xenstored setup.
>>
>> Right.
>>
>>> Maybe the OS xenbus driver should reap all watches on behalf the dead
>>> process. This would also avoid a crashed QEMU leaking resources.
>>>
>>> And xenstored should have proper quota support so that a domain can't
>>> set up excessive numbers of watches.
>>
>> This would be dom0 unless you arrange the device model to be accounted
>> as the domid it is running for. But this is problematic with a xenstore
>> domain again.
>>
> 
> The quota could be based on "connection" (ring or socket) and
> counted as per-connection? Just throwing ideas around, not necessarily
> saying this is the way to go.

Sure. But with xenstore domain all xenstore access of dom0 is via one
ring. And how would you want to apply any quota here solving our
problem with one qemu process in dom0 creating stale watches? You
could open a new connection for the device model, of course, but this
would require some xenbus rework.


Juergen

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

Re: [Xen-devel] xenstored memory leak

[Wei Liu]

On Wed, Jul 13, 2016 at 03:25:45PM +0200, Juergen Gross wrote:
> On 13/07/16 15:07, Wei Liu wrote:
> > On Wed, Jul 13, 2016 at 02:21:38PM +0200, Juergen Gross wrote:
> >> On 06/07/16 09:31, Juergen Gross wrote:
> >>> While testing some patches for support of ballooning in Mini-OS by using
> >>> the xenstore domain I realized that each xl create/destroy pair would
> >>> increase memory consumption in Mini-OS by about 5kB. Wondering whether
> >>> this is a xenstore domain only effect I did the same test with xenstored
> >>> and oxenstored daemons.
> >>>
> >>> xenstored showed the same behavior, the "referenced" size showed by the
> >>> pmap command grew by about 5kB for each create/destroy pair.
> >>>
> >>> oxenstored seemed to be even worse in the beginning (about 6kB for each
> >>> pair), but after about 100 create/destroys the value seemed to be
> >>> rather stable.
> >>>
> >>> Did anyone notice this memory leak before?
> >>
> >> I think I've found the problem:
> >>
> >> qemu as the device model is setting up a xenstore watch for each backend
> >> type it is supporting. Unfortunately those watches are never removed
> >> again. This sums up to the observed memory leak.
> >>
> >> I'm not sure how oxenstored is avoiding the problem, may be by testing
> >> socket connections to be still alive and so detecting qemu has gone.
> >> OTOH this won't help for oxenstored running in another domain than the
> >> device model (either due to oxenstore-stubdom, or a driver domain with
> >> a qemu based device model).
> >>
> > 
> > How unfortunate.
> > 
> > My gut feeling is that xenstored shouldn't have the knowledge to
> > associate a watch with a "process". The concept of a process is only
> > meaningful to OS, which wouldn't work on cross-domain xenstored setup.
> 
> Right.
> 
> > Maybe the OS xenbus driver should reap all watches on behalf the dead
> > process. This would also avoid a crashed QEMU leaking resources.
> > 
> > And xenstored should have proper quota support so that a domain can't
> > set up excessive numbers of watches.
> 
> This would be dom0 unless you arrange the device model to be accounted
> as the domid it is running for. But this is problematic with a xenstore
> domain again.
> 

The quota could be based on "connection" (ring or socket) and
counted as per-connection? Just throwing ideas around, not necessarily
saying this is the way to go.

Wei.

> 
> Juergen

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

Re: [Xen-devel] xenstored memory leak

[Juergen Gross]

On 13/07/16 15:17, David Vrabel wrote:
> On 13/07/16 14:07, Wei Liu wrote:
>>
>> My gut feeling is that xenstored shouldn't have the knowledge to
>> associate a watch with a "process". The concept of a process is only
>> meaningful to OS, which wouldn't work on cross-domain xenstored setup.
>> Maybe the OS xenbus driver should reap all watches on behalf the dead
>> process. This would also avoid a crashed QEMU leaking resources.
> 
> The Linux driver already cleans up open transactions and removes watches
> when the file handle is released.

Hmm, does this work reliably? I observed a memory leak of about 5kB per
create/destroy domain pair with xenstored _and_ with xenstore domain.


Juergen


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

Re: [Xen-devel] xenstored memory leak

[Wei Liu]

On Wed, Jul 13, 2016 at 02:20:28PM +0100, Ian Jackson wrote:
> Wei Liu writes ("Re: [Xen-devel] xenstored memory leak"):
> > On Wed, Jul 13, 2016 at 02:21:38PM +0200, Juergen Gross wrote:
> > > qemu as the device model is setting up a xenstore watch for each backend
> > > type it is supporting. Unfortunately those watches are never removed
> > > again. This sums up to the observed memory leak.
> 
> I think this must be a bug in C xenstored.
> 
> > > I'm not sure how oxenstored is avoiding the problem, may be by testing
> > > socket connections to be still alive and so detecting qemu has gone.
> > > OTOH this won't help for oxenstored running in another domain than the
> > > device model (either due to oxenstore-stubdom, or a driver domain with
> > > a qemu based device model).
> > 
> > How unfortunate.
> > 
> > My gut feeling is that xenstored shouldn't have the knowledge to
> > associate a watch with a "process".
> 
> xenstored needs to associate watches with connections.  If a
> connection is terminated, the watches need to be cleaned up, along
> with whatever other things "belong" to that connection (notably
> transactions, and replies in flight).
> 
> Here a `connection' might be a socket, or a ring.
> 

Agreed.

> C xenstored does have code which tries to do this.  It's a bit
> impenetrable, though, because it's done through destructors provided
> to the reference counting membery allocator (!)
> 
> > The concept of a process is only meaningful to OS, which wouldn't
> > work on cross-domain xenstored setup.  Maybe the OS xenbus driver
> > should reap all watches on behalf the dead process. This would also
> > avoid a crashed QEMU leaking resources.
> 
> The OS xenbus driver needs to mediate everything, so that it can
> direct replies to the right places etc.  It needs to (and does)
> maintain a list of watches.  When a process closes the xenbus device,
> it destroys the watches by issuing commands to the actual xenstored
> via its ring connection.
> 
> I guess that the qemu in this case is making a socket connection to
> xenstored.
> 

Yeah, I suspect that as well.

Wei.

> Ian.

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

Re: [Xen-devel] [PATCH 1/6] xen/build: Allow the use of C freestanding headers

[Andrew Cooper]

On 22/06/16 14:12, Tim Deegan wrote:
> At 12:24 +0100 on 22 Jun (1466598248), Andrew Cooper wrote:
>> The C standard defines two types of conforming implementation; hosted and
>> freestanding.  A subset of the standard headers are the freestanding headers,
>> requiring no library support at all to use, and therefore usable by Xen.
>>
>> Unfortunately, -nostdinc is an overly large switch, and there is no
>> alternative to only permit inclusion of the freestanding headers.  Removing 
>> it
>> is unfortunate, as we lose the protection it offers, but anyone who does try
>> to use other parts of the standard library will still fail to link.
> I'm afraid I don't think this is a good idea:
>  - Leaving the standard include path around in the Xen build means
>that the build may differ based on what (unrelated) libraries are
>installed on the build machines.
>  - There are plenty of ways for an unexpected header to break things
>that don't fail at link time, e.g. macros and inlines.
>  - "Freestanding" headers can bring in quite a lot of unrelated cruft.
>See Jan's email about linux/glibc, and I remember seeing similar
>things on solaris and *BSD when I tidied up stdarg.h. E.g. looking
>at two machines I'm working on today, on one of them,
>#include  defines __packed, and on the other it does not.
>
> Since what we have already works fine for all the compilers we
> support, I think it ain't broke and we shouldn't fix it.

Except it is broken.

We cannot expect to use -Wformat and not the compiler provided
inttypes.h.  The sizes of constructs like "long long" are implementation
defined, not spec defined.  The compiler is perfectly free to choose
something which doesn't match our inttypes.h, and we would be in the
wrong when it fails to compile.

~Andrew

>
> Nacked-by: Tim Deegan 
>
> OTOH, I am in favour of s/bool_t/bool/g, at least wherever field size
> is not an issue, and I can see an argument for moving the type and
> limits definitions into files called stdint.h and limits.h.
>
> Cheers,
>
> Tim.
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


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

Re: [Xen-devel] xenstored memory leak

[David Vrabel]

On 13/07/16 14:32, Juergen Gross wrote:
> On 13/07/16 15:17, David Vrabel wrote:
>> On 13/07/16 14:07, Wei Liu wrote:
>>>
>>> My gut feeling is that xenstored shouldn't have the knowledge to
>>> associate a watch with a "process". The concept of a process is only
>>> meaningful to OS, which wouldn't work on cross-domain xenstored setup.
>>> Maybe the OS xenbus driver should reap all watches on behalf the dead
>>> process. This would also avoid a crashed QEMU leaking resources.
>>
>> The Linux driver already cleans up open transactions and removes watches
>> when the file handle is released.
> 
> Hmm, does this work reliably? I observed a memory leak of about 5kB per
> create/destroy domain pair with xenstored _and_ with xenstore domain.

Don't know.

I only took a quick look at the xenbus_file_release() function and it
looked like it ought to be doing the right thing...

David

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

Re: [Xen-devel] xenstored memory leak

[Ian Jackson]

Juergen Gross writes ("Re: [Xen-devel] xenstored memory leak"):
> On 13/07/16 14:40, Andrew Cooper wrote:
> > On 13/07/16 13:21, Juergen Gross wrote:
> >> I'll post a qemu patch to remove those watches on exit soon.

I don't think this is right.  qemu should not explictly remove watches
when it is exiting.  The cleanup should be handled by xenstored
directly (if qemu is connecting via a socket) or by the OS xenbus
driver (otherwise).  Each of those entities keeps a list of which of
their clients owns what watches.

> > That is good, but there needs to be further consideration as to how to
> > clean up after a crashed qemu/etc.
> 
> Hmm, I see two possibilities:
> 
> a) Add a possibility to do xs_unwatch() with a path and a token with
>wildcards (e.g.: xs_unwatch(xs, "/local/domain/0/backend/qdisk",
>"be:*:97:*") for removing all qdisk watches for domid 97) and use
>this when doing the xenstore cleanup from libxl on domain
>destruction.
> 
> b) Instead of watching /local/domain//backend/ let qemu
>create /local/domain//backend// and watch
>this. When this directory is being removed by libxl all the watches
>will be gone automatically.

This is going in entirely the wrong direction.

Ian.

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

Re: [Xen-devel] [PATCH] x86, hvm: document the de facto policy for vCPU ids

[Andrew Cooper]

On 12/07/16 17:28, Konrad Rzeszutek Wilk wrote:
> On Tue, Jul 12, 2016 at 7:44 AM, Vitaly Kuznetsov  wrote:
>> PVHVM guests may need to know Xen's idea of vCPU ids they have and the
>> only way they can figure them out is to use ACPI ids from MADT table.
>> Document the de facto policy.
>>
>> Signed-off-by: Vitaly Kuznetsov 
> Acked-by: Konrad Rzeszutek Wilk 

Reviewed and committed.

~Andrew

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

Re: [Xen-devel] [PATCH v2] vmx/monitor: CPUID events

[Andrew Cooper]

On 12/07/16 19:13, Tamas K Lengyel wrote:
> This patch implements sending notification to a monitor subscriber when an
> x86/vmx guest executes the CPUID instruction.
>
> Signed-off-by: Tamas K Lengyel 
> ---
> Cc: Ian Jackson 
> Cc: Wei Liu 
> Cc: Razvan Cojocaru 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> Cc: Jun Nakajima 
> Cc: Kevin Tian 

Committed.

~Andrew

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

Re: [Xen-devel] xenstored memory leak

[Juergen Gross]

On 13/07/16 15:07, Wei Liu wrote:
> On Wed, Jul 13, 2016 at 02:21:38PM +0200, Juergen Gross wrote:
>> On 06/07/16 09:31, Juergen Gross wrote:
>>> While testing some patches for support of ballooning in Mini-OS by using
>>> the xenstore domain I realized that each xl create/destroy pair would
>>> increase memory consumption in Mini-OS by about 5kB. Wondering whether
>>> this is a xenstore domain only effect I did the same test with xenstored
>>> and oxenstored daemons.
>>>
>>> xenstored showed the same behavior, the "referenced" size showed by the
>>> pmap command grew by about 5kB for each create/destroy pair.
>>>
>>> oxenstored seemed to be even worse in the beginning (about 6kB for each
>>> pair), but after about 100 create/destroys the value seemed to be
>>> rather stable.
>>>
>>> Did anyone notice this memory leak before?
>>
>> I think I've found the problem:
>>
>> qemu as the device model is setting up a xenstore watch for each backend
>> type it is supporting. Unfortunately those watches are never removed
>> again. This sums up to the observed memory leak.
>>
>> I'm not sure how oxenstored is avoiding the problem, may be by testing
>> socket connections to be still alive and so detecting qemu has gone.
>> OTOH this won't help for oxenstored running in another domain than the
>> device model (either due to oxenstore-stubdom, or a driver domain with
>> a qemu based device model).
>>
> 
> How unfortunate.
> 
> My gut feeling is that xenstored shouldn't have the knowledge to
> associate a watch with a "process". The concept of a process is only
> meaningful to OS, which wouldn't work on cross-domain xenstored setup.

Right.

> Maybe the OS xenbus driver should reap all watches on behalf the dead
> process. This would also avoid a crashed QEMU leaking resources.
> 
> And xenstored should have proper quota support so that a domain can't
> set up excessive numbers of watches.

This would be dom0 unless you arrange the device model to be accounted
as the domid it is running for. But this is problematic with a xenstore
domain again.


Juergen

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

Re: [Xen-devel] [PATCH] libxl: constify src parameter of libxl_nocpuid.c:libxl_cpuid_policy_list_copy

[Ian Jackson]

Wei Liu writes ("[PATCH] libxl: constify src parameter of 
libxl_nocpuid.c:libxl_cpuid_policy_list_copy"):
> In 11316d31 ("libxl: constify copy and length calculation functions") I
> forgot to take care of libxl_nocpuid.c which also contains an
> implementation of libxl_cpuid_policy_list_copy. That broke ARM build.

Acked-by: Ian Jackson 

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

Re: [Xen-devel] ACPI builder re-licensing

[Lars Kurth]

Boris,

I can't remember how we managed this process the last time round (see for 
https://patchwork.kernel.org/patch/9172431/), but in that case we already had a 
patch. As far as I can see, we don't have the complete patch yet.

Thus, the question I would have to you is whether you want to prepare the 
complete patch first or get the approvals of all stake-holders first?

I also think we should establish two groups of people regardless of approach
A) A list of individuals with e-mails we need to get approval from 
B) A list of company reps which can provide approval on behalf of a companies 
contribution

What we did in https://patchwork.kernel.org/patch/9172431/ was to get ACKs from 
people in group A, and e-mail confirmation from people in group B.

Regardless of the approach, we also ought to write an explanation that is 
easily consumable for people in group B which may not be very involved in Xen.
- A short introduction outlining what see are trying to do and why (maybe refer 
back to this thread)
- Explain why we sent the explanation to person X (that would probably need to 
contain some boilerplate what (c) they and/or their orgs hold and why we 
contacted them)
- End with a question which they clearly can answer (and which we can copy as 
evidence into the changelog)

Would you be able to draft something? We can then distribute some of the 
activities based on existing personal relationships.

> On 12 Jul 2016, at 18:09, Ian Jackson  wrote:
> 
> Boris Ostrovsky writes ("[Xen-devel] ACPI builder re-licensing"):

>> Who needs to be notified
>> ===
> 
> NB that what is required is not notification, but permission.
> 
>> which indicated major contributions (and therefore a required ack) from
>> Citrix/Xensource, Suse/Novell, Oracle/Sun, Intel.

This is group B stuff
- Citrix/Xensource can be James Bulpin or me
- Suse/Novell can be arranged by Jan or Juergen 
- Intel ought to be Susie Li 
- Oracle/Sun can be arranged by Konrad or you

Could you double check whether any of these maybe should go into group A? 

>> 
>> For the rest ("trivial" or "simple" is, of course, a matter of opinion):
>> 
>> * debian.com is a single trivial patch to a Makefile
>> 
>> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=83f34fdcdd26c3dcc793c571e7b75c705bd92e7a
> 
> You mean debian.org.  Of course debian.org is not the author here and
> would not be the copyrightholder; Bastian Blank would be.  But I agree
> that this patch is trivial.

ACK

> 
>> * Fujitsu provided two patches, one trivial the other not completely trivial
>> 
>> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=e451db15ef6198f5d21b84618c833ac276087d70
>> 
>> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=ab438874b6a8ae955b337c36e7b3204e29b8d407
> 
> This second patch is nontrivial and therefore we need approval from
> Fujitsu.

The second patch was signed off by Kouya Shimura 
I did see him post something on LKLM in Feb 2016 using the above e-mail 
address. 
So probably this could go into group A. If not, Kouya probably would know who 
can make the call on behalf of Fujitsu. 

> 
>> * net-space.pl is Daniel Kiper's (now, but not at the patch's time, at
>> Oracle) ISP. The patch is
>> 
>> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=37fddaa5fe1a7e369827e4b9e25cdae5df9b3d7d
> 
> This patch is not trivial in copyright terms, so we need Daniel
> Kiper's approval.

We have Daniel's e-mail address, so this should go into group A. Not sure 
whether Daniel uses his old address still, which would be preferable.

>> * redhat is one trivial patch by Paolo Bonzini that has been reversed later:
>> 
>> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=e4fd0475a08fda414da27c4e57b568f147cfc07e
> 
> If the patch has been reverted then we are not proposing to relicence.
> We need to be careful not to re-apply it without getting a new signoff
> from Red Hat.

We ought to check that. If not true, Paolo Bonzini should go into group A.

>> * IBM one patch from Stefan Berger
>> 
>> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=9fd9787b0e7995ac5f2da504b92723c24d6a3737
>> 
>>  (plus what seems to inclusion of his work in
>> 
>> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=883236e49a86a0174c6df61cac995ebf16d72b35)
> 
> The latter is rather sloppy practice :-/.
> 
>>  Also, ssdt_tpm.asl is explicitly copyrighted by IBM
> 
> So we need approval from IBM.

Stefan still seems to work for IBM, with stef...@us.ibm.com as e0-mail address. 
So Group A.

>> * A bunch of patches from from Simon Horman at Verge
> 
> So we need approval from Verge.

Group A: ho...@verge.net.au

>> * xen.org are S-o-b by Keir, all from 2011.
> 
> I think those were work-for-hire by Keir with his XenSource/Citrix hat
> on and are now owned by Citrix.  We should reconfirm with Keir.

Group A. Should be straightforward.

Best Regards
Lars


___

Re: [Xen-devel] [PATCH 1/2] asm/atomic.h: common prototyping (add xen/atomic.h)

[Andrew Cooper]

On 13/07/16 14:20, Corneliu ZUZU wrote:
> On 7/13/2016 3:12 PM, Andrew Cooper wrote:
>> On 13/07/16 12:23, Corneliu ZUZU wrote:
>>> +typedef struct { int counter; } atomic_t;
>>> +
>>> +#define ATOMIC_INIT(i) { (i) }
>>> +
>>> +/**
>>> + * atomic_read - read atomic variable
>>> + * @v: pointer of type atomic_t
>>> + *
>>> + * Atomically reads the value of @v.
>>> + */
>>> +static inline int atomic_read(atomic_t *v);
>>> +
>>> +/**
>>> + * _atomic_read - read atomic variable non-atomically
>>> + * @v atomic_t
>>> + *
>>> + * Non-atomically reads the value of @v
>>> + */
>>> +static inline int _atomic_read(atomic_t v);
>>> +
>>> +/**
>>> + * atomic_set - set atomic variable
>>> + * @v: pointer of type atomic_t
>>> + * @i: required value
>>> + *
>>> + * Atomically sets the value of @v to @i.
>>> + */
>>> +static inline void atomic_set(atomic_t *v, int i);
>>> +
>>> +/**
>>> + * _atomic_set - set atomic variable non-atomically
>>> + * @v: pointer of type atomic_t
>>> + * @i: required value
>>> + *
>>> + * Non-atomically sets the value of @v to @i.
>>> + */
>>> +static inline void _atomic_set(atomic_t *v, int i);
>>> +
>>
>
> Is it ok if I also omit repeating the comments which are already @
> xen/atomic.h from the arch-side asm/atomic.h ?

Yes - that should be fine.  No point having identical comments twice.

~Andrew

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

[Xen-devel] [PATCH] libxl: constify src parameter of libxl_nocpuid.c:libxl_cpuid_policy_list_copy

[Wei Liu]

In 11316d31 ("libxl: constify copy and length calculation functions") I
forgot to take care of libxl_nocpuid.c which also contains an
implementation of libxl_cpuid_policy_list_copy. That broke ARM build.

Fix it by constifying the src parameter.

Signed-off-by: Wei Liu 
---
Cc: Ian Jackson 

I've checked, other libxl_no*.c files don't have _length or _copy
functions.
---
 tools/libxl/libxl_nocpuid.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/libxl/libxl_nocpuid.c b/tools/libxl/libxl_nocpuid.c
index 3dcaef2..ef1161c 100644
--- a/tools/libxl/libxl_nocpuid.c
+++ b/tools/libxl/libxl_nocpuid.c
@@ -58,7 +58,7 @@ int libxl__cpuid_policy_list_parse_json(libxl__gc *gc,
 
 void libxl_cpuid_policy_list_copy(libxl_ctx *ctx,
   libxl_cpuid_policy_list *dst,
-  libxl_cpuid_policy_list *src)
+  const libxl_cpuid_policy_list *src)
 {
 }
 
-- 
2.1.4


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

Re: [Xen-devel] xenstored memory leak

[Juergen Gross]

On 13/07/16 14:40, Andrew Cooper wrote:
> On 13/07/16 13:21, Juergen Gross wrote:
>> On 06/07/16 09:31, Juergen Gross wrote:
>>> While testing some patches for support of ballooning in Mini-OS by using
>>> the xenstore domain I realized that each xl create/destroy pair would
>>> increase memory consumption in Mini-OS by about 5kB. Wondering whether
>>> this is a xenstore domain only effect I did the same test with xenstored
>>> and oxenstored daemons.
>>>
>>> xenstored showed the same behavior, the "referenced" size showed by the
>>> pmap command grew by about 5kB for each create/destroy pair.
>>>
>>> oxenstored seemed to be even worse in the beginning (about 6kB for each
>>> pair), but after about 100 create/destroys the value seemed to be
>>> rather stable.
>>>
>>> Did anyone notice this memory leak before?
>> I think I've found the problem:
>>
>> qemu as the device model is setting up a xenstore watch for each backend
>> type it is supporting. Unfortunately those watches are never removed
>> again. This sums up to the observed memory leak.
>>
>> I'm not sure how oxenstored is avoiding the problem, may be by testing
>> socket connections to be still alive and so detecting qemu has gone.
>> OTOH this won't help for oxenstored running in another domain than the
>> device model (either due to oxenstore-stubdom, or a driver domain with
>> a qemu based device model).
> 
> I do seem to remember something along those lines.
> 
>>
>> I'll post a qemu patch to remove those watches on exit soon.
> 
> That is good, but there needs to be further consideration as to how to
> clean up after a crashed qemu/etc.

Hmm, I see two possibilities:

a) Add a possibility to do xs_unwatch() with a path and a token with
   wildcards (e.g.: xs_unwatch(xs, "/local/domain/0/backend/qdisk",
   "be:*:97:*") for removing all qdisk watches for domid 97) and use
   this when doing the xenstore cleanup from libxl on domain
   destruction.

b) Instead of watching /local/domain//backend/ let qemu
   create /local/domain//backend// and watch
   this. When this directory is being removed by libxl all the watches
   will be gone automatically.


Juergen

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

Re: [Xen-devel] xenstored memory leak

[Ian Jackson]

Wei Liu writes ("Re: [Xen-devel] xenstored memory leak"):
> On Wed, Jul 13, 2016 at 02:21:38PM +0200, Juergen Gross wrote:
> > qemu as the device model is setting up a xenstore watch for each backend
> > type it is supporting. Unfortunately those watches are never removed
> > again. This sums up to the observed memory leak.

I think this must be a bug in C xenstored.

> > I'm not sure how oxenstored is avoiding the problem, may be by testing
> > socket connections to be still alive and so detecting qemu has gone.
> > OTOH this won't help for oxenstored running in another domain than the
> > device model (either due to oxenstore-stubdom, or a driver domain with
> > a qemu based device model).
> 
> How unfortunate.
> 
> My gut feeling is that xenstored shouldn't have the knowledge to
> associate a watch with a "process".

xenstored needs to associate watches with connections.  If a
connection is terminated, the watches need to be cleaned up, along
with whatever other things "belong" to that connection (notably
transactions, and replies in flight).

Here a `connection' might be a socket, or a ring.

C xenstored does have code which tries to do this.  It's a bit
impenetrable, though, because it's done through destructors provided
to the reference counting membery allocator (!)

> The concept of a process is only meaningful to OS, which wouldn't
> work on cross-domain xenstored setup.  Maybe the OS xenbus driver
> should reap all watches on behalf the dead process. This would also
> avoid a crashed QEMU leaking resources.

The OS xenbus driver needs to mediate everything, so that it can
direct replies to the right places etc.  It needs to (and does)
maintain a list of watches.  When a process closes the xenbus device,
it destroys the watches by issuing commands to the actual xenstored
via its ring connection.

I guess that the qemu in this case is making a socket connection to
xenstored.

Ian.

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

Re: [Xen-devel] [PATCH 1/2] asm/atomic.h: common prototyping (add xen/atomic.h)

[Corneliu ZUZU]

On 7/13/2016 3:12 PM, Andrew Cooper wrote:

On 13/07/16 12:23, Corneliu ZUZU wrote:

+typedef struct { int counter; } atomic_t;
+
+#define ATOMIC_INIT(i) { (i) }
+
+/**
+ * atomic_read - read atomic variable
+ * @v: pointer of type atomic_t
+ *
+ * Atomically reads the value of @v.
+ */
+static inline int atomic_read(atomic_t *v);
+
+/**
+ * _atomic_read - read atomic variable non-atomically
+ * @v atomic_t
+ *
+ * Non-atomically reads the value of @v
+ */
+static inline int _atomic_read(atomic_t v);
+
+/**
+ * atomic_set - set atomic variable
+ * @v: pointer of type atomic_t
+ * @i: required value
+ *
+ * Atomically sets the value of @v to @i.
+ */
+static inline void atomic_set(atomic_t *v, int i);
+
+/**
+ * _atomic_set - set atomic variable non-atomically
+ * @v: pointer of type atomic_t
+ * @i: required value
+ *
+ * Non-atomically sets the value of @v to @i.
+ */
+static inline void _atomic_set(atomic_t *v, int i);
+




Is it ok if I also omit repeating the comments which are already @ 
xen/atomic.h from the arch-side asm/atomic.h ?


Thanks,
Zuzu C.

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

Re: [Xen-devel] xenstored memory leak

[David Vrabel]

On 13/07/16 14:07, Wei Liu wrote:
> 
> My gut feeling is that xenstored shouldn't have the knowledge to
> associate a watch with a "process". The concept of a process is only
> meaningful to OS, which wouldn't work on cross-domain xenstored setup.
> Maybe the OS xenbus driver should reap all watches on behalf the dead
> process. This would also avoid a crashed QEMU leaking resources.

The Linux driver already cleans up open transactions and removes watches
when the file handle is released.

David

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

[Xen-devel] [ovmf test] 97263: trouble: pass/preparing

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ovmf-amd64  2 hosts-allocate   running
 test-amd64-i386-xl-qemuu-ovmf-amd64  2 hosts-allocate   running

version targeted for testing:
 ovmf 31441f298365dd182a7a672f1b40fbdb6115c12f
baseline version:
 ovmf dc99315b8732b6e3032d01319d3f534d440b43d0

Last test of basis94748  2016-05-24 22:43:25 Z   49 days
Failing since 94750  2016-05-25 03:43:08 Z   49 days  107 attempts
Testing same since0  1970-01-01 00:00:00 Z 16995 days0 attempts


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

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



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

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

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

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


Not pushing.

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

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

Re: [Xen-devel] [PATCH v7 00/14] xen/arm: Use the typesafes gfn and mfn

[Andrew Cooper]

On 12/07/16 14:59, Julien Grall wrote:
> Hello all,
>
> Some of the ARM functions are mixing gfn vs mfn and even physical vs frame.
>
> To avoid more confusion, this patch series makes use of the terminology
> described in xen/include/xen/mm.h and the associated typesafe.
>
> I pushed a branch with this series applied on top of staging:
> git://xenbits.xen.org/people/julieng/xen-unstable.git branch typesafe-v7

Patches 1-6 committed.

~Andrew

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

[Xen-devel] [seabios test] 97265: trouble: pass/preparing

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm  2 hosts-allocate   running
 test-amd64-i386-qemuu-rhel6hvm-amd  2 hosts-allocate   running
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  2 hosts-allocaterunning
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  2 hosts-allocaterunning
 test-amd64-i386-xl-qemuu-debianhvm-amd64  2 hosts-allocate running
 test-amd64-amd64-qemuu-nested-amd  2 hosts-allocate   running
 test-amd64-i386-qemuu-rhel6hvm-intel  2 hosts-allocate   running
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm  2 hosts-allocaterunning
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  2 hosts-allocate running
 test-amd64-amd64-xl-qemuu-win7-amd64  2 hosts-allocate   running
 test-amd64-amd64-qemuu-nested-intel  2 hosts-allocate   running
 test-amd64-i386-xl-qemuu-win7-amd64  2 hosts-allocate   running
 test-amd64-amd64-xl-qemuu-winxpsp3  2 hosts-allocate   running
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  2 hosts-allocate running
 test-amd64-i386-xl-qemuu-winxpsp3  2 hosts-allocate   running

version targeted for testing:
 seabios  54e3a88609da074aaae2f04e592026ebf82169dc
baseline version:
 seabios  13213a252286372efa5f72b4119faafd5dff5db1

Last test of basis96767  2016-07-07 15:43:40 Z5 days
Testing same since0  1970-01-01 00:00:00 Z 16995 days0 attempts


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

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   preparing
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpreparing
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpreparing
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm preparing
 test-amd64-amd64-qemuu-nested-amdpreparing
 test-amd64-i386-qemuu-rhel6hvm-amd   preparing
 test-amd64-amd64-xl-qemuu-debianhvm-amd64preparing
 test-amd64-i386-xl-qemuu-debianhvm-amd64 preparing
 test-amd64-amd64-xl-qemuu-win7-amd64 preparing
 test-amd64-i386-xl-qemuu-win7-amd64  preparing
 test-amd64-amd64-qemuu-nested-intel  preparing
 test-amd64-i386-qemuu-rhel6hvm-intel preparing
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 preparing
 test-amd64-amd64-xl-qemuu-winxpsp3   preparing
 test-amd64-i386-xl-qemuu-winxpsp3preparing



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

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

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

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


Not pushing.


commit 54e3a88609da074aaae2f04e592026ebf82169dc
Author: Paolo Bonzini 
Date:   Thu Jul 7 16:00:40 2016 +0200

smp: restore MSRs on S3 resume

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

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

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

[Wei Liu]

On Wed, Jul 13, 2016 at 01:55:26PM +0100, Ian Jackson wrote:
> osstest service owner writes ("[xen-unstable-smoke test] 97261: regressions - 
> FAIL"):
> > flight 97261 xen-unstable-smoke real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/97261/
> > 
> > Regressions :-(
> > 
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> >  build-armhf   5 xen-buildfail REGR. vs. 96794
> 
> This is a real bug:
> 
>   libxl_nocpuid.c:59:6: error: conflicting types for
>   'libxl_cpuid_policy_list_copy'
> 
> Probably due to 11316d31d684 "libxl: constify copy and length
> calculation functions" ?
> 

Yes, I didn't update the libxl_nocpuid.c. ARM uses that because it
doesn't have cpuid support.

I will go over libxl_no*.c and send out a patch soon.

Wei.

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

Re: [Xen-devel] xenstored memory leak

[Wei Liu]

On Wed, Jul 13, 2016 at 02:21:38PM +0200, Juergen Gross wrote:
> On 06/07/16 09:31, Juergen Gross wrote:
> > While testing some patches for support of ballooning in Mini-OS by using
> > the xenstore domain I realized that each xl create/destroy pair would
> > increase memory consumption in Mini-OS by about 5kB. Wondering whether
> > this is a xenstore domain only effect I did the same test with xenstored
> > and oxenstored daemons.
> > 
> > xenstored showed the same behavior, the "referenced" size showed by the
> > pmap command grew by about 5kB for each create/destroy pair.
> > 
> > oxenstored seemed to be even worse in the beginning (about 6kB for each
> > pair), but after about 100 create/destroys the value seemed to be
> > rather stable.
> > 
> > Did anyone notice this memory leak before?
> 
> I think I've found the problem:
> 
> qemu as the device model is setting up a xenstore watch for each backend
> type it is supporting. Unfortunately those watches are never removed
> again. This sums up to the observed memory leak.
> 
> I'm not sure how oxenstored is avoiding the problem, may be by testing
> socket connections to be still alive and so detecting qemu has gone.
> OTOH this won't help for oxenstored running in another domain than the
> device model (either due to oxenstore-stubdom, or a driver domain with
> a qemu based device model).
> 

How unfortunate.

My gut feeling is that xenstored shouldn't have the knowledge to
associate a watch with a "process". The concept of a process is only
meaningful to OS, which wouldn't work on cross-domain xenstored setup.
Maybe the OS xenbus driver should reap all watches on behalf the dead
process. This would also avoid a crashed QEMU leaking resources.

And xenstored should have proper quota support so that a domain can't
set up excessive numbers of watches.

> I'll post a qemu patch to remove those watches on exit soon.
> 
> To find the problem I've added some debug aid to xenstored: when
> a special parameter is specified on invocation it will dump its memory
> allocation structure via talloc_report_full() to a file whenever it is
> receiving a SIGUSR1 signal. Anybody interested in this patch?
> 

Wouldn't hurt to post to the list. If we take it we take it, if we don't
it would still be useful for people who want custom debug patch later.

Wei.

> 
> Juergen
> 
> ___
> 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

[Xen-devel] [qemu-mainline test] 97264: trouble: pass/preparing/queued/running

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt  queued
 test-armhf-armhf-libvirt-qcow2  queued
 test-armhf-armhf-xl-arndale   queued
 test-armhf-armhf-xl   queued
 test-armhf-armhf-xl-credit2   queued
 test-armhf-armhf-xl-cubietruck  queued
 test-armhf-armhf-libvirt-xsm  queued
 test-armhf-armhf-xl-rtds  queued
 test-armhf-armhf-libvirt-raw  queued
 test-armhf-armhf-xl-xsm   queued
 test-armhf-armhf-xl-vhd   queued
 test-armhf-armhf-xl-multivcpu  queued
 test-amd64-amd64-xl-pvh-amd   2 hosts-allocate   running
 test-amd64-amd64-xl-pvh-intel  2 hosts-allocate   running
 test-amd64-amd64-xl   2 hosts-allocate   running
 test-amd64-amd64-libvirt-xsm  2 hosts-allocate   running
 test-amd64-i386-xl-xsm2 hosts-allocate   running
 test-amd64-i386-libvirt   2 hosts-allocate   running
 test-amd64-amd64-xl-credit2   2 hosts-allocate   running
 test-amd64-amd64-xl-xsm   2 hosts-allocate   running
 test-amd64-i386-xl2 hosts-allocate   running
 test-amd64-amd64-xl-multivcpu  2 hosts-allocate   running
 test-amd64-amd64-pygrub   2 hosts-allocate   running
 test-amd64-amd64-pair 2 hosts-allocate   running
 test-amd64-amd64-i386-pvgrub  2 hosts-allocate   running
 test-amd64-amd64-amd64-pvgrub  2 hosts-allocate   running
 test-amd64-amd64-libvirt-pair  2 hosts-allocate   running
 test-amd64-amd64-qemuu-nested-amd  2 hosts-allocate   running
 build-armhf-libvirt   5 libvirt-buildrunning
 test-amd64-i386-freebsd10-i386  2 hosts-allocate   running
 test-amd64-i386-qemuu-rhel6hvm-intel  2 hosts-allocate   running
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm  2 hosts-allocate   running
 test-amd64-i386-qemuu-rhel6hvm-amd  2 hosts-allocate   running
 test-amd64-i386-libvirt-pair  2 hosts-allocate   running
 test-amd64-amd64-qemuu-nested-intel  2 hosts-allocate   running
 test-amd64-i386-pair  2 hosts-allocate   running
 test-amd64-i386-libvirt-xsm   2 hosts-allocate   running
 test-amd64-amd64-xl-qemuu-win7-amd64  2 hosts-allocate   running
 test-amd64-amd64-libvirt  2 hosts-allocate   running
 test-amd64-i386-xl-qemuu-win7-amd64  2 hosts-allocate   running
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm  2 hosts-allocaterunning
 test-amd64-i386-xl-qemuu-debianhvm-amd64  2 hosts-allocate running
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  2 hosts-allocaterunning
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  2 hosts-allocaterunning
 test-amd64-amd64-xl-qcow2 2 hosts-allocate   running
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  2 hosts-allocate running
 test-amd64-amd64-xl-qemuu-ovmf-amd64  2 hosts-allocate   running
 test-amd64-i386-freebsd10-amd64  2 hosts-allocate   running
 test-amd64-i386-xl-qemuu-ovmf-amd64  2 hosts-allocate   running
 test-amd64-amd64-libvirt-vhd  2 hosts-allocate   running
 test-amd64-i386-xl-raw2 hosts-allocate   running
 test-amd64-amd64-xl-rtds  2 hosts-allocate   running
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  2 hosts-allocate running
 build-armhf-pvops 5 kernel-build running
 test-amd64-amd64-xl-qemuu-winxpsp3  2 hosts-allocate   running
 test-amd64-i386-xl-qemuu-winxpsp3  2 hosts-allocate   running

version targeted for testing:
 qemuuca3d87d4c84032f19478010b5604cac88b045c25
baseline version:
 qemuu4f4a9ca4a4386c137301b3662faba076455ff15a

Last test of basis96791  2016-07-08 12:20:07 Z5 days
Testing same since0  1970-01-01 00:00:00 Z 16995 days0 attempts


People who touched revisions under test:
  Alex Bennée 
  Alexander Yarygin 
  Anthony PERARD 
  Ashok Raj 
  Cornelia Huck 
  Daniel P. Berrange 
  David Gibson 
  David Hildenbrand 
  Denis V. Lunev 
  Eduardo Habkost 
  Eric Blake 
  Eugene (jno) Dvurechenski 

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

[Anshul Makkar]

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

Signed-off-by: Anshul Makkar 
---
---
 tools/flask/policy/modules/xen.if | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

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


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

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

[Ian Jackson]

osstest service owner writes ("[xen-unstable-smoke test] 97261: regressions - 
FAIL"):
> flight 97261 xen-unstable-smoke real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/97261/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-armhf   5 xen-buildfail REGR. vs. 96794

This is a real bug:

  libxl_nocpuid.c:59:6: error: conflicting types for
  'libxl_cpuid_policy_list_copy'

Probably due to 11316d31d684 "libxl: constify copy and length
calculation functions" ?

>  test-amd64-amd64-libvirt 11 guest-startfail REGR. vs. 96794

^ this is fallout from the new stricter firewall rules:

2016-07-13 12:02:30 Z FAILURE: guest debian.guest.osstest
5a:36:0e:ed:00:02 22 link/ip/tcp: wait timed out: connect to
infra:5556: Connection refused.

Because many other tests will be fail for similar reasons, I am going
to abort all currently running flights.  There will be a flurry of
emails reporting these unfinished flights.

Ian.

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

Re: [Xen-devel] [PATCH 2/2] Allow kdump with crash_kexec_post_notifiers

[David Vrabel]

On 13/07/16 13:20, Petr Tesarik wrote:
> If a crash kernel is loaded, do not crash the running domain. This is
> needed if the kernel is loaded with crash_kexec_post_notifiers, because
> panic notifiers are run before __crash_kexec() in that case, and this
> Xen hook prevents its being called later.

Prioritising the in-kernel kexec image over the hypervisor one seems
sensible behaviour to me.

Reviewed-by: David Vrabel 

David

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

Re: [Xen-devel] [PATCH 1/2] Add a kexec_crash_loaded() function

[Josh Triplett]

On Wed, Jul 13, 2016 at 02:19:55PM +0200, Petr Tesarik wrote:
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -95,6 +95,12 @@ int kexec_should_crash(struct task_struct *p)
>   return 0;
>  }
>  
> +int kexec_crash_loaded(void)
> +{
> + return !!kexec_crash_image;
> +}

Nit: this function should return bool rather than int, since it
effectively returns true/false.

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt 11 guest-start   fail REGR. vs. 96794
 test-amd64-amd64-xl-qemuu-debianhvm-i386 9 debian-hvm-install fail REGR. vs. 
96794
 build-armhf   5 xen-build fail REGR. vs. 96794

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a

version targeted for testing:
 xen  1fb0fe97a647549cc1bbe90f15b6cb2fcc3f79b6
baseline version:
 xen  7da483b0236d8974cc97f81780dcf8e559a63175

Last test of basis96794  2016-07-08 15:01:26 Z4 days
Testing same since97261  2016-07-13 11:00:54 Z0 days1 attempts


People who touched revisions under test:
  Corneliu ZUZU 
  Ian Jackson 
  Juergen Gross 
  Julien Grall 
  Kevin Tian 
  Stefano Stabellini 
  Wei Liu 

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



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

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

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

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


Not pushing.


commit 1fb0fe97a647549cc1bbe90f15b6cb2fcc3f79b6
Author: Corneliu ZUZU 
Date:   Sat Jul 9 07:12:07 2016 +0300

x86/vmx_update_guest_cr: minor optimization

Minor optimization @ vmx_update_guest_cr: checks if 
v->arch.hvm_vmx.exec_control
was modified before actually calling vmx_update_cpu_exec_control(v).

Signed-off-by: Corneliu ZUZU 
Acked-by: Kevin Tian 

commit 22ea8ad02e465e32cd40887c750b55c3a997a288
Author: Juergen Gross 
Date:   Wed Jul 6 16:55:34 2016 +0200

libxl: move DEFINE_DEVICE* macros to libxl_internal.h

In order to be able to have all functions related to a device type in
a single source file move the macros used to generate device type
specific functions to libxl_internal.h. Rename the macros as they are
no longer local to a source file. While at it hide device remove and
device destroy in one macro as those are always used in pairs. Move
usage of the macros to the appropriate source files.

Signed-off-by: Juergen Gross 
Acked-by: Ian Jackson 

commit 2c2c33f038c889acc9f73681c09320164516da47
Author: Juergen Gross 
Date:   Wed Jul 6 16:55:33 2016 +0200

libxl: refactor domcreate_attach_dtdev() to use device type framework

Signed-off-by: Juergen Gross 
Acked-by: Ian Jackson 

commit 26021d77dc14d441ff3b0094f2fafcc5d18aa599
Author: Juergen Gross 
Date:   Wed Jul 6 16:55:32 2016 +0200

libxl: refactor domcreate_attach_pci() to use device type framework

Signed-off-by: Juergen Gross 
Acked-by: Ian Jackson 

commit 74e857c6c7f9dc106fa7a7bbf49a9729f5841ad9
Author: Juergen Gross 
Date:   Wed Jul 6 16:55:31 2016 +0200

libxl: add framework for device types

Instead of duplicate coding for each device type (vtpms, usbctrls, ...)
especially on domain creation introduce a framework for that purpose.

Signed-off-by: Juergen Gross 
Acked-by: Ian Jackson 

commit 56bac262e097684b20f7753ceb6debe594e9725c
Author: Wei Liu 
Date:   Wed Jun 8 15:01:02 2016 +0100

libxl: only issue cpu-add call to QEMU for not present CPU

Calculate the final bitmap for CPUs to add to avoid having annoying
error 

Re: [Xen-devel] xenstored memory leak

[Andrew Cooper]

On 13/07/16 13:21, Juergen Gross wrote:
> On 06/07/16 09:31, Juergen Gross wrote:
>> While testing some patches for support of ballooning in Mini-OS by using
>> the xenstore domain I realized that each xl create/destroy pair would
>> increase memory consumption in Mini-OS by about 5kB. Wondering whether
>> this is a xenstore domain only effect I did the same test with xenstored
>> and oxenstored daemons.
>>
>> xenstored showed the same behavior, the "referenced" size showed by the
>> pmap command grew by about 5kB for each create/destroy pair.
>>
>> oxenstored seemed to be even worse in the beginning (about 6kB for each
>> pair), but after about 100 create/destroys the value seemed to be
>> rather stable.
>>
>> Did anyone notice this memory leak before?
> I think I've found the problem:
>
> qemu as the device model is setting up a xenstore watch for each backend
> type it is supporting. Unfortunately those watches are never removed
> again. This sums up to the observed memory leak.
>
> I'm not sure how oxenstored is avoiding the problem, may be by testing
> socket connections to be still alive and so detecting qemu has gone.
> OTOH this won't help for oxenstored running in another domain than the
> device model (either due to oxenstore-stubdom, or a driver domain with
> a qemu based device model).

I do seem to remember something along those lines.

>
> I'll post a qemu patch to remove those watches on exit soon.

That is good, but there needs to be further consideration as to how to
clean up after a crashed qemu/etc.

>
> To find the problem I've added some debug aid to xenstored: when
> a special parameter is specified on invocation it will dump its memory
> allocation structure via talloc_report_full() to a file whenever it is
> receiving a SIGUSR1 signal. Anybody interested in this patch?

Sounds useful.  +1

~Andrew

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

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

[Paulina Szubarczyk]

On 06/22/2016 10:38 AM, Paulina Szubarczyk wrote:

Copy data operated on during request from/to local buffers to/from
the grant references.

Before grant copy operation local buffers must be allocated what is
done by calling ioreq_init_copy_buffers. For the 'read' operation,
first, the qemu device invokes the read operation on local buffers
and on the completion grant copy is called and buffers are freed.
For the 'write' operation grant copy is performed before invoking
write by qemu device.

A new value 'feature_grant_copy' is added to recognize when the
grant copy operation is supported by a guest.
The body of the function 'ioreq_runio_qemu_aio' is moved to
'ioreq_runio_qemu_aio_blk' and in the 'ioreq_runio_qemu_aio' depending
on the support for grant copy according checks, initialization, grant
operation are made, then the 'ioreq_runio_qemu_aio_blk' function is
called.

Signed-off-by: Paulina Szubarczyk 
---
Changes since v2:
- to use the xengnttab_* function directly added -lxengnttab to configure
   and include  in include/hw/xen/xen_common.h
- in ioreq_copy removed an out path, changed a log level, made explicit
   assignement to 'xengnttab_copy_grant_segment'
* I did not change the way of testing if grant_copy operation is implemented.
   As far as I understand if the code from gnttab_unimp.c is used then the 
gnttab
   device is unavailable and the handler to gntdev would be invalid. But
   if the handler is valid then the ioctl should return operation unimplemented
   if the gntdev does not implement the operation.

  configure   |   2 +-
  hw/block/xen_disk.c | 171 
  include/hw/xen/xen_common.h |   2 +
  3 files changed, 162 insertions(+), 13 deletions(-)

diff --git a/configure b/configure
index e41876a..355d3fa 100755
--- a/configure
+++ b/configure
@@ -1843,7 +1843,7 @@ fi
  # xen probe

  if test "$xen" != "no" ; then
-  xen_libs="-lxenstore -lxenctrl -lxenguest"
+  xen_libs="-lxenstore -lxenctrl -lxenguest -lxengnttab"

# First we test whether Xen headers and libraries are available.
# If no, we are done and there is no Xen support.
diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
index 37e14d1..4eca06a 100644
--- a/hw/block/xen_disk.c
+++ b/hw/block/xen_disk.c
@@ -131,6 +131,9 @@ struct XenBlkDev {
  unsigned intpersistent_gnt_count;
  unsigned intmax_grants;

+/* Grant copy */
+gbooleanfeature_grant_copy;
+
  /* qemu block driver */
  DriveInfo   *dinfo;
  BlockBackend*blk;
@@ -500,6 +503,99 @@ static int ioreq_map(struct ioreq *ioreq)
  return 0;
  }

+static void* get_buffer(int count)
+{
+return xc_memalign(xen_xc, XC_PAGE_SIZE, count*XC_PAGE_SIZE);
+}
+
+static void free_buffers(struct ioreq *ioreq)
+{
+int i;
+
+for (i = 0; i < ioreq->v.niov; i++) {
+ioreq->page[i] = NULL;
+}
+
+free(ioreq->pages);
+}
+
+static int ioreq_init_copy_buffers(struct ioreq *ioreq) {
+int i;
+
+if (ioreq->v.niov == 0) {
+return 0;
+}
+
+ioreq->pages = get_buffer(ioreq->v.niov);
+if (!ioreq->pages) {
+return -1;
+}
+
+for (i = 0; i < ioreq->v.niov; i++) {
+ioreq->page[i] = ioreq->pages + i*XC_PAGE_SIZE;
+ioreq->v.iov[i].iov_base += (uintptr_t)ioreq->page[i];
+}
+
+return 0;
+}
+
+static int ioreq_copy(struct ioreq *ioreq)
+{
+XenGnttab gnt = ioreq->blkdev->xendev.gnttabdev;
+xengnttab_grant_copy_segment_t segs[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+int i, count = 0, r, rc;
+int64_t file_blk = ioreq->blkdev->file_blk;
+
+if (ioreq->v.niov == 0) {
+return 0;
+}
+
+count = ioreq->v.niov;
+
+for (i = 0; i < count; i++) {
+
+if (ioreq->req.operation == BLKIF_OP_READ) {
+segs[i].flags = GNTCOPY_dest_gref;
+segs[i].dest.foreign.ref = ioreq->refs[i];
+segs[i].dest.foreign.domid = ioreq->domids[i];
+segs[i].dest.foreign.offset = ioreq->req.seg[i].first_sect * 
file_blk;
+segs[i].source.virt = ioreq->v.iov[i].iov_base;
+} else {
+segs[i].flags = GNTCOPY_source_gref;
+segs[i].source.foreign.ref = ioreq->refs[i];
+segs[i].source.foreign.domid = ioreq->domids[i];
+segs[i].source.foreign.offset = ioreq->req.seg[i].first_sect * 
file_blk;
+segs[i].dest.virt = ioreq->v.iov[i].iov_base;
+}
+segs[i].len = (ioreq->req.seg[i].last_sect
+   - ioreq->req.seg[i].first_sect + 1) * file_blk;
+
+}
+
+rc = xengnttab_grant_copy(gnt, count, segs);
+
+if (rc) {
+xen_be_printf(>blkdev->xendev, 0,
+  "failed to copy data %d \n", rc);
+ioreq->aio_errors++;
+return -1;
+} else {
+r = 0;
+}
+
+for (i = 0; i < count; i++) {
+if (segs[i].status != GNTST_okay) {
+

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

[Juergen Gross]

Xenstore watches of the /local/domain//backend/ directories
are never removed. This can lead to a memory leak in xenstored,
especially when xenstored is running in another domain (this will be
the case either for a system with xenstore-stubdom, or with driver
domains running qemu-based backends).

Avoid this problem by calling xs_unwatch() for these directories when
terminating qemu.

Signed-off-by: Juergen Gross 
---
 hw/xen/xen_backend.c | 28 ++--
 1 file changed, 22 insertions(+), 6 deletions(-)

diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
index bab79b1..6413475 100644
--- a/hw/xen/xen_backend.c
+++ b/hw/xen/xen_backend.c
@@ -52,6 +52,13 @@ struct xs_dirs {
 };
 static QTAILQ_HEAD(xs_dirs_head, xs_dirs) xs_cleanup =
 QTAILQ_HEAD_INITIALIZER(xs_cleanup);
+struct xs_watches {
+char path[XEN_BUFSIZE];
+char token[XEN_BUFSIZE];
+QTAILQ_ENTRY(xs_watches) list;
+};
+static QTAILQ_HEAD(xs_watches_head, xs_watches) xs_w_cleanup =
+QTAILQ_HEAD_INITIALIZER(xs_w_cleanup);
 
 static QTAILQ_HEAD(XenDeviceHead, XenDevice) xendevs = 
QTAILQ_HEAD_INITIALIZER(xendevs);
 static int debug = 0;
@@ -70,10 +77,14 @@ static void xenstore_cleanup_dir(char *dir)
 void xen_config_cleanup(void)
 {
 struct xs_dirs *d;
+struct xs_watches *w;
 
 QTAILQ_FOREACH(d, _cleanup, list) {
 xs_rm(xenstore, 0, d->xs_dir);
 }
+QTAILQ_FOREACH(w, _w_cleanup, list) {
+xs_unwatch(xenstore, w->path, w->token);
+}
 }
 
 int xenstore_write_str(const char *base, const char *node, const char *val)
@@ -629,20 +640,25 @@ void xen_be_check_state(struct XenDevice *xendev)
 static int xenstore_scan(const char *type, int dom, struct XenDevOps *ops)
 {
 struct XenDevice *xendev;
-char path[XEN_BUFSIZE], token[XEN_BUFSIZE];
+struct xs_watches *w;
 char **dev = NULL;
 unsigned int cdev, j;
 
 /* setup watch */
-snprintf(token, sizeof(token), "be:%p:%d:%p", type, dom, ops);
-snprintf(path, sizeof(path), "backend/%s/%d", type, dom);
-if (!xs_watch(xenstore, path, token)) {
-xen_be_printf(NULL, 0, "xen be: watching backend path (%s) failed\n", 
path);
+w = g_malloc(sizeof(*w));
+
+snprintf(w->token, sizeof(w->token), "be:%p:%d:%p", type, dom, ops);
+snprintf(w->path, sizeof(w->path), "backend/%s/%d", type, dom);
+if (!xs_watch(xenstore, w->path, w->token)) {
+xen_be_printf(NULL, 0, "xen be: watching backend path (%s) failed\n",
+  w->path);
+g_free(w);
 return -1;
 }
+QTAILQ_INSERT_TAIL(_w_cleanup, w, list);
 
 /* look for backends */
-dev = xs_directory(xenstore, 0, path, );
+dev = xs_directory(xenstore, 0, w->path, );
 if (!dev) {
 return 0;
 }
-- 
2.6.6


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

Re: [Xen-devel] [PATCH 0/2] Allow crash dumps with crash_kexec_post_notifiers

[Petr Tesarik]

On Wed, 13 Jul 2016 14:19:50 +0200
Petr Tesarik  wrote:

> Hello all,
> 
> this patch series makes it possible to save a kernel crash dump when the
> kernel command line includes "crash_kexec_post_notifiers".

Oh ... I forgot to add: This only applies to running Linux under Xen.
If you run on bare metal, you can always save the dump already, as you
certainly know.

Petr T

> There might
> be other approaches, but mine has the advantage that no new sysctl is
> required, and the behaviour is the same whether panic notifiers are run
> or not: If you load a crash kernel with kexec, it will be used, otherwise
> the hypervisor facility is used (using a hypercall).
> 
> Feedback welcome!
> 
> Petr T
> 
> ---
> 
> Petr Tesarik (2):
>   Add a kexec_crash_loaded() function
>   Allow kdump with crash_kexec_post_notifiers
> 
> 
>  arch/x86/xen/enlighten.c |3 ++-
>  include/linux/kexec.h|2 ++
>  kernel/kexec_core.c  |5 +
>  kernel/ksysfs.c  |2 +-
>  4 files changed, 10 insertions(+), 2 deletions(-)
> 
> --
> Signature
> 
> ___
> kexec mailing list
> ke...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec


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

Re: [Xen-devel] [PATCH 1/2] asm/atomic.h: common prototyping (add xen/atomic.h)

[Corneliu ZUZU]

Hi Julien,

On 7/13/2016 3:14 PM, Julien Grall wrote:

Hi Corneliu,

On 13/07/2016 12:23, Corneliu ZUZU wrote:
Following Andrew Cooper's suggestion, create a common-side 
 to
establish, among others, prototypes of atomic functions called from 
common-code.
Done to avoid introducing inconsistencies between arch-side 


headers when we make subtle changes to one of them.

Some arm-side macros had to be turned into inline functions in the 
process.


You forgot to mention that you moved the code from 
asm-arm/arm{32,64}/atomic.h to asm-arm/arm.h.


Furthermore, this change should really be a separate patch.


Noted, will do.





Also includes a minor adjustment asm-x86/atomic.h: reorder 
atomic_inc_and_test()

to follow after atomic_inc().

Signed-off-by: Corneliu ZUZU 


[...]


diff --git a/xen/include/asm-arm/atomic.h b/xen/include/asm-arm/atomic.h
index 29ab265..8e8c5d1 100644
--- a/xen/include/asm-arm/atomic.h
+++ b/xen/include/asm-arm/atomic.h
@@ -2,6 +2,7 @@
 #define __ARCH_ARM_ATOMIC__

 #include 
+#include 
 #include 
 #include 

@@ -95,15 +96,6 @@ void __bad_atomic_size(void);
 default: __bad_atomic_size(); 
break;\

} \
 })
-
-/*
- * NB. I've pushed the volatile qualifier into the operations. This 
allows
- * fast accessors such as _atomic_read() and _atomic_set() which 
don't give

- * the compiler a fit.
- */
-typedef struct { int counter; } atomic_t;
-
-#define ATOMIC_INIT(i) { (i) }

 /*
  * On ARM, ordinary assignment (str instruction) doesn't clear the 
local

@@ -138,6 +130,85 @@ static inline void _atomic_set(atomic_t *v, int i)
 # error "unknown ARM variant"
 #endif

+#define atomic_inc_return(v)(atomic_add_return(1, v))
+#define atomic_dec_return(v)(atomic_sub_return(1, v))
+
+/**
+ * atomic_sub_and_test - subtract value from variable and test result
+ * @i: integer value to subtract
+ * @v: pointer of type atomic_t
+ *
+ * Atomically subtracts @i from @v and returns
+ * true if the result is zero, or false for all
+ * other cases.
+ */
+static inline int atomic_sub_and_test(int i, atomic_t *v)
+{
+return 0 == atomic_sub_return(i, v);
+}


Please don't use yoda condition. It's less readable and compiler have 
safety nowadays to prevent using "=".


Oh yeah, given that Xen's compiled with -Wall -Werror that's not 
necessary. Ack.





+
+/**
+ * atomic_inc - increment atomic variable
+ * @v: pointer of type atomic_t
+ *
+ * Atomically increments @v by 1.
+ */
+static inline void atomic_inc(atomic_t *v)
+{
+atomic_add(1, v);
+}


Regards,


Thanks,
Corneliu.

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

[Xen-devel] [PATCH 1/2] Add a kexec_crash_loaded() function

[Petr Tesarik]

Provide a wrapper function to be used by kernel code to check whether
a crash kernel is loaded. It returns the same value that can be seen
in /sys/kernel/kexec_crash_loaded by userspace programs.

I'm exporting the function, because it will be used by Xen, and it is
possible to compile Xen modules separately to enable the use of PV
drivers with unmodified bare-metal kernels.

Signed-off-by: Petr Tesarik 
---
 include/linux/kexec.h |2 ++
 kernel/kexec_core.c   |6 ++
 kernel/ksysfs.c   |2 +-
 3 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index e8acb2b..d461d02 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -228,6 +228,7 @@ extern void *kexec_purgatory_get_symbol_addr(struct kimage 
*image,
 extern void __crash_kexec(struct pt_regs *);
 extern void crash_kexec(struct pt_regs *);
 int kexec_should_crash(struct task_struct *);
+int kexec_crash_loaded(void);
 void crash_save_cpu(struct pt_regs *regs, int cpu);
 void crash_save_vmcoreinfo(void);
 void arch_crash_save_vmcoreinfo(void);
@@ -324,6 +325,7 @@ struct task_struct;
 static inline void __crash_kexec(struct pt_regs *regs) { }
 static inline void crash_kexec(struct pt_regs *regs) { }
 static inline int kexec_should_crash(struct task_struct *p) { return 0; }
+static inline int kexec_crash_loaded(void) { return 0; }
 #define kexec_in_progress false
 #endif /* CONFIG_KEXEC_CORE */
 
diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index 56b3ed0..a303dce 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -95,6 +95,12 @@ int kexec_should_crash(struct task_struct *p)
return 0;
 }
 
+int kexec_crash_loaded(void)
+{
+   return !!kexec_crash_image;
+}
+EXPORT_SYMBOL_GPL(kexec_crash_loaded);
+
 /*
  * When kexec transitions to the new kernel there is a one-to-one
  * mapping between physical and virtual addresses.  On processors
diff --git a/kernel/ksysfs.c b/kernel/ksysfs.c
index 152da4a..bf9fc9d 100644
--- a/kernel/ksysfs.c
+++ b/kernel/ksysfs.c
@@ -101,7 +101,7 @@ KERNEL_ATTR_RO(kexec_loaded);
 static ssize_t kexec_crash_loaded_show(struct kobject *kobj,
   struct kobj_attribute *attr, char *buf)
 {
-   return sprintf(buf, "%d\n", !!kexec_crash_image);
+   return sprintf(buf, "%d\n", kexec_crash_loaded());
 }
 KERNEL_ATTR_RO(kexec_crash_loaded);
 


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

Re: [Xen-devel] [PATCH 1/2] asm/atomic.h: common prototyping (add xen/atomic.h)

[Corneliu ZUZU]

On 7/13/2016 3:12 PM, Andrew Cooper wrote:

On 13/07/16 12:23, Corneliu ZUZU wrote:

Following Andrew Cooper's suggestion, create a common-side  to
establish, among others, prototypes of atomic functions called from common-code.
Done to avoid introducing inconsistencies between arch-side 
headers when we make subtle changes to one of them.

Some arm-side macros had to be turned into inline functions in the process.

Also includes a minor adjustment asm-x86/atomic.h: reorder atomic_inc_and_test()
to follow after atomic_inc().

Suggested-by: Andrew Cooper 


Nice, didn't know that.





Signed-off-by: Corneliu ZUZU 

Thanks for doing this!


diff --git a/xen/include/xen/atomic.h b/xen/include/xen/atomic.h
new file mode 100644
index 000..5d5c051
--- /dev/null
+++ b/xen/include/xen/atomic.h
@@ -0,0 +1,155 @@
+/*
+ * include/xen/atomic.h
+ *
+ * Common atomic operations entities (atomic_t, function prototypes).
+ * Include _from_ arch-side .
+ *
+ * Copyright (c) 2016 Bitdefender S.R.L.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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 .
+ */
+
+#ifndef __XEN_ATOMIC_H__
+#define __XEN_ATOMIC_H__
+
+/*
+ * NB. I've pushed the volatile qualifier into the operations. This allows
+ * fast accessors such as _atomic_read() and _atomic_set() which don't give
+ * the compiler a fit.
+ */

I would recommend simply dropping this paragraph.  Is is very out of date.


Ack.




+typedef struct { int counter; } atomic_t;
+
+#define ATOMIC_INIT(i) { (i) }
+
+/**
+ * atomic_read - read atomic variable
+ * @v: pointer of type atomic_t
+ *
+ * Atomically reads the value of @v.
+ */
+static inline int atomic_read(atomic_t *v);
+
+/**
+ * _atomic_read - read atomic variable non-atomically
+ * @v atomic_t
+ *
+ * Non-atomically reads the value of @v
+ */
+static inline int _atomic_read(atomic_t v);
+
+/**
+ * atomic_set - set atomic variable
+ * @v: pointer of type atomic_t
+ * @i: required value
+ *
+ * Atomically sets the value of @v to @i.
+ */
+static inline void atomic_set(atomic_t *v, int i);
+
+/**
+ * _atomic_set - set atomic variable non-atomically
+ * @v: pointer of type atomic_t
+ * @i: required value
+ *
+ * Non-atomically sets the value of @v to @i.
+ */
+static inline void _atomic_set(atomic_t *v, int i);
+

/**
  * atomic_cmpxchg - compare and exchange an atomic variable
  *...
  */


Ack.




+static inline int atomic_cmpxchg(atomic_t *v, int old, int new);

With those changes, Reviewed-by: Andrew Cooper 


Thanks too for the prompt review,
Zuzu C.

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

[Xen-devel] [PATCH 0/2] Allow crash dumps with crash_kexec_post_notifiers

[Petr Tesarik]

Hello all,

this patch series makes it possible to save a kernel crash dump when the
kernel command line includes "crash_kexec_post_notifiers". There might
be other approaches, but mine has the advantage that no new sysctl is
required, and the behaviour is the same whether panic notifiers are run
or not: If you load a crash kernel with kexec, it will be used, otherwise
the hypervisor facility is used (using a hypercall).

Feedback welcome!

Petr T

---

Petr Tesarik (2):
  Add a kexec_crash_loaded() function
  Allow kdump with crash_kexec_post_notifiers


 arch/x86/xen/enlighten.c |3 ++-
 include/linux/kexec.h|2 ++
 kernel/kexec_core.c  |5 +
 kernel/ksysfs.c  |2 +-
 4 files changed, 10 insertions(+), 2 deletions(-)

--
Signature

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

[Xen-devel] [PATCH 2/2] Allow kdump with crash_kexec_post_notifiers

[Petr Tesarik]

If a crash kernel is loaded, do not crash the running domain. This is
needed if the kernel is loaded with crash_kexec_post_notifiers, because
panic notifiers are run before __crash_kexec() in that case, and this
Xen hook prevents its being called later.

Signed-off-by: Petr Tesarik 
---
 arch/x86/xen/enlighten.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 760789a..6e3e7c6 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1325,7 +1325,8 @@ static void xen_crash_shutdown(struct pt_regs *regs)
 static int
 xen_panic_event(struct notifier_block *this, unsigned long event, void *ptr)
 {
-   xen_reboot(SHUTDOWN_crash);
+   if (!kexec_crash_loaded())
+   xen_reboot(SHUTDOWN_crash);
return NOTIFY_DONE;
 }
 


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