date:20151021

In <1431963008.4944.80.ca...@citrix.com> I proposed stabilising some
parts of the libxenctrl API/ABI by disaggregating into separate
libraries.

This is v4 of that set of series against:
xen
qemu-xen
qemu-xen-traditional
mini-os

NB: Samuel+minios-devel will only get the mini-os side and Stefano+qemu
-devel the qemu-xen side.

The code in for all repos can be found in:

git://xenbits.xen.org/people/ianc/libxenctrl-split/xen.git  v4
git://xenbits.xen.org/people/ianc/libxenctrl-split/qemu-xen.git v4
git://xenbits.xen.org/people/ianc/libxenctrl-split/qemu-xen-traditional.git v4
git://xenbits.xen.org/people/ianc/libxenctrl-split/mini-os.git  v4

The tip of the xen.git branch contains an extra patch hacking Config.mk
to point to all the others above, which should get the correct things for
the HEAD of the branch, but not further back in time.

The new libraries here are:

 * libxentoollog: Common logging infrastructure
 * libxenevtchn: Userspace access to evtchns (via /dev/xen/evtchn etc)
 * libxengnttab: Userspace access to grant tables (via /dev/xen/gnt??? etc)
 * libxencall: Making hypercalls (i.e. the IOCTL_PRIVCMD_HYPERCALL type
   functionality)
 * libxenforeignmemory: Privileged mappings of foreign memory
   (IOCTL_PRIVCMD_MMAP et al)

The first three were actually pretty distinct within libxenctrl already and
have not changed in quite some time.

Although the other two are somewhat new they are based on top of long
standing stable ioctls, which gives me some confidence.

Nonetheless I would appreciate extra review of at least the interface
headers of all of these with a particular eye to the suitability of these
interfaces being maintained in an ABI (_B_, not _P_) stable way going
forward.

Still to come would be libraries for specific out of tree purposes
(device model, kexec), which would be adding new library at the same
level as libxc I think, rather than underneath, i.e. also using the
libraries split out here, but hopefully not libxenctrl itself.

The new libraries use linker version-scripts to hopefully make future
ABI changes be possible in a compatible way.

Since last time I have:

 * Addressed various review comments:
* Addressed feedback from Stefano on the qemu-xen series (and this
  version now goes to qemu-devel too)
* Switched the foreign mapping interfaces to use size_t for the number
  of pages.
* Fixed the callers of xenforeignmemory_unmap (should have been pages,
  but everywhere was passing bytes like the previous munmap case)
* HACK patch in xen.git now updates Config.mk instead of .config

The whole thing has been build tested on Linux (incl stubdoms), and on
FreeBSD. I have runtime tested older versions on Linux but my test boxes
are currently in some netherworld having been moved to a different colo.

Neither NetBSD nor Solaris have been tested at all. It's certainly not
impossible that I've not got the #includes in the new files quite right.

http://xenbits.xen.org/people/ianc/libxenctrl-split/v4.html is the document
I've been using to try and track what I'm doing. It may not be all that
useful. The history of it is in the v4-with-doc branch of the xen.git
linked to above.

Ian.

___
Minios-devel mailing list
minios-de...@lists.xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo/minios-devel

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

Re: [Xen-devel] [ANNOUNCE] Switching to qemu-xen.git and qemu-xen-traditional.git

2015-10-21 Thread Olaf Hering

On Wed, Oct 21, Ian Campbell wrote:

> http://xenbits.xen.org/gitweb/?p=qemu-xen.git

Is the HEAD warning expected?

$ git clone git://xenbits.xen.org/qemu-xen qemu-xen.git
$ cd $_
$ git remote show origin
* remote origin
  Fetch URL: git://xenbits.xen.org/qemu-xen
  Push  URL: git://xenbits.xen.org/qemu-xen
  HEAD branch (remote HEAD is ambiguous, may be one of the following):
master
staging
  Remote branches:
master  tracked
stable-4.2  tracked
stable-4.3  tracked
stable-4.4  tracked
stable-4.5  tracked
stable-4.6  tracked
staging tracked
staging-4.2 tracked
staging-4.3 tracked
staging-4.4 tracked
staging-4.5 tracked
staging-4.6 tracked
upstream-tested tracked
  Local branch configured for 'git pull':
master merges with remote master
  Local ref configured for 'git push':
master pushes to master (up to date)

Olaf

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

[Xen-devel] [xen-4.2-testing test] 63110: regressions - FAIL

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 build-amd64-rumpuserxen   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-i386-i386-pv 1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-i386-i386-xl-raw 1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-i386-i386-xl-multivcpu   1 build-check(1)   blocked  n/a
 test-i386-i386-pair   1 build-check(1)   blocked  n/a
 test-i386-i386-xl-winxpsp31 build-check(1)   blocked  n/a
 build-i386-rumpuserxen1 build-check(1)   blocked  n/a
 test-i386-i386-xl 1 build-check(1)   blocked  n/a
 test-i386-i386-xl-credit2 1 build-check(1)   blocked  n/a
 test-i386-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-migrupgrade  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-i386-i386-xl-qemut-winxpsp3  1 build-check(1)   blocked  n/a
 test-i386-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-win7-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-migrupgrade   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-freebsd10-i386  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-win7-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-rhel6hvm-amd  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-freebsd10-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xend-qemut-winxpsp3  1 build-check(1)  blocked n/a

Re: [Xen-devel] [PATCH v2 1/1] xen-netfront: update num_queues to real created

2015-10-21 Thread David Miller

From: Joe Jin 
Date: Mon, 19 Oct 2015 13:37:17 +0800

> Sometimes xennet_create_queues() may failed to created all requested
> queues, we need to update num_queues to real created to avoid NULL
> pointer dereference.
> 
> Signed-off-by: Joe Jin 

Applied.

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

[Xen-devel] [xen-unstable test] 63102: regressions - trouble: blocked/fail/pass/preparing/running

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   5 xen-build fail REGR. vs. 63080
 build-i386-xsm5 xen-build fail REGR. vs. 63080
 build-i3865 xen-build fail REGR. vs. 63080
 build-amd64   5 xen-build fail REGR. vs. 63080
 test-armhf-armhf-libvirt-qcow2  2 hosts-allocate   running
 test-armhf-armhf-libvirt-raw  2 hosts-allocate   running
 test-armhf-armhf-libvirt-xsm  9 debian-install   running
 test-armhf-armhf-libvirt  2 hosts-allocate   running
 test-armhf-armhf-xl-arndale   2 hosts-allocate   running
 test-armhf-armhf-xl-rtds  2 hosts-allocate   running
 test-armhf-armhf-xl-xsm   3 host-install(3)  running
 test-armhf-armhf-xl-multivcpu  2 hosts-allocate   running
 test-armhf-armhf-xl-credit2  16 guest-start/debian.repeatrunning
 test-armhf-armhf-xl-vhd   2 hosts-allocate   running
 test-armhf-armhf-xl   2 hosts-allocate   running
 test-armhf-armhf-xl-cubietruck  3 host-install(3)  running

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-amd64-xl-pvh-amd   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-intel  1 build-check(1)   blocked  n/a
 build-amd64-rumpuserxen   1 build-check(1)   blocked  n/a
 build-i386-rumpuserxen1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-migrupgrade   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a

[Xen-devel] [linux-linus test] 63107: regressions - trouble: blocked/fail/pass/preparing/queued

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i3865 xen-build fail REGR. vs. 59254
 build-i386-xsm5 xen-build fail REGR. vs. 59254
 build-amd64   5 xen-build fail REGR. vs. 59254
 build-armhf   5 xen-build fail REGR. vs. 59254
 build-amd64-xsm   5 xen-build fail REGR. vs. 59254
 test-armhf-armhf-xl-vhd   queued
 test-armhf-armhf-libvirt  queued
 test-armhf-armhf-libvirt-xsm  queued
 test-armhf-armhf-libvirt-qcow2  queued
 test-armhf-armhf-xl-xsm   queued
 test-armhf-armhf-xl-rtds  queued
 test-armhf-armhf-xl   queued
 test-armhf-armhf-libvirt-raw  queued
 test-armhf-armhf-xl-cubietruck  queued
 test-armhf-armhf-xl-credit2   queued
 test-armhf-armhf-xl-arndale   queued
 test-armhf-armhf-xl-multivcpu  queued
 build-armhf-xsm   2 hosts-allocate   running
 build-armhf-pvops 2 hosts-allocate   running

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  1 build-check(1)   blocked  n/a
 build-amd64-rumpuserxen   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd   1 build-check(1)   blocked  n/a
 build-i386-rumpuserxen1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked

Re: [Xen-devel] [edk2] [PATCH v2] OvmfPkg: XenPvBlkDxe: handle empty cdrom drives

2015-10-21 Thread Fabio Fantoni


Il 21/10/2015 14:45, Laszlo Ersek ha scritto:

On 10/21/15 13:39, Stefano Stabellini wrote:

Empty cdroms are not going to connect, avoid waiting for the backend to
switch to state 4, which is never going to happen, and return
error instead from XenPvBlockFrontInitialization(). Detect an
empty cdrom by looking at the "params" node on xenstore, which is set to
"" or "aio:" for empty drives by libxl.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Stefano Stabellini 

---
Changes in v2:
- better commit message
- return EFI_DEVICE_ERROR instead of EFI_NO_MEDIA
- check the return status of XenBusIo->XsBackendRead
---
  OvmfPkg/XenPvBlkDxe/BlockFront.c |   15 +++
  1 file changed, 15 insertions(+)

diff --git a/OvmfPkg/XenPvBlkDxe/BlockFront.c b/OvmfPkg/XenPvBlkDxe/BlockFront.c
index 256ac55..d07e980 100644
--- a/OvmfPkg/XenPvBlkDxe/BlockFront.c
+++ b/OvmfPkg/XenPvBlkDxe/BlockFront.c
@@ -169,6 +169,7 @@ XenPvBlockFrontInitialization (
XEN_BLOCK_FRONT_DEVICE *Dev;
XenbusState State;
UINT64 Value;
+  CHAR8 *Params;
  
ASSERT (NodeName != NULL);
  
@@ -186,6 +187,20 @@ XenPvBlockFrontInitialization (

}
FreePool (DeviceType);
  
+  if (Dev->MediaInfo.CdRom) {

+Status = XenBusIo->XsBackendRead (XenBusIo, XST_NIL, "params", 
(VOID**));
+if (Status != XENSTORE_STATUS_SUCCESS) {
+  DEBUG ((EFI_D_ERROR, "%a: Failed to read params (%d)\n", __FUNCTION__, 
Status));
+  goto Error;
+}
+if (AsciiStrLen (Params) == 0 || AsciiStrCmp (Params, "aio:") == 0) {
+  FreePool (Params);
+  DEBUG ((EFI_D_INFO, "%a: Empty cdrom\n", __FUNCTION__));
+  goto Error;
+}
+FreePool (Params);
+  }
+
Status = XenBusReadUint64 (XenBusIo, "backend-id", FALSE, );
if (Status != XENSTORE_STATUS_SUCCESS || Value > MAX_UINT16) {
  DEBUG ((EFI_D_ERROR, "XenPvBlk: Failed to get backend-id (%d)\n",


Reviewed-by: Laszlo Ersek 

I test-built this for X64 and Ia32, and then committed it to SVN as rev
18651.

Thanks!
Laszlo


Thanks to both.
I tested it with a git cherry-pick on my tested build of some days ago.
With ide disks it boots correctly and xl cd-insert and xl cd-eject are 
working.
With pvdisk don't start, but this time instead freeze on "tianocore 
logo" but freeze with black screen after initial windows boot.
I retried for take full logs as possibile but it booted correctly and 
with xl cd-insert and xl cd-eject was working.
I retried other 2 reboot without problem but at the third windows freeze 
after arrived to login screen.
I suppose that this patch is ok and the problem is another but I not 
understand exactly what.


In attachment full qemu log and xl dmesg about the latest test where 
windows freezed at login screen, rdp and xl shutdown was not working, 
its qemu process was still active and with near 100% cpu usage.

If you need more informations/tests tell me and I'll post them.

Thanks for any reply and sorry for my bad english.

(d24) HVM Loader
(d24) Detected Xen v4.6.0
(d24) Xenbus rings @0xfeffc000, event channel 1
(d24) System requested OVMF
(d24) CPU speed is 2660 MHz
(d24) Relocating guest memory for lowmem MMIO space disabled
(XEN) irq.c:275: Dom24 PCI link 0 changed 0 -> 5
(d24) PCI-ISA link 0 routed to IRQ5
(XEN) irq.c:275: Dom24 PCI link 1 changed 0 -> 10
(d24) PCI-ISA link 1 routed to IRQ10
(XEN) irq.c:275: Dom24 PCI link 2 changed 0 -> 11
(d24) PCI-ISA link 2 routed to IRQ11
(XEN) irq.c:275: Dom24 PCI link 3 changed 0 -> 5
(d24) PCI-ISA link 3 routed to IRQ5
(d24) pci dev 01:3 INTA->IRQ10
(d24) pci dev 02:0 INTA->IRQ11
(d24) pci dev 03:0 INTA->IRQ5
(d24) pci dev 04:0 INTA->IRQ5
(d24) pci dev 05:0 INTA->IRQ10
(d24) pci dev 06:0 INTA->IRQ11
(d24) pci dev 1d:0 INTA->IRQ10
(d24) pci dev 1d:1 INTB->IRQ11
(d24) pci dev 1d:2 INTC->IRQ5
(d24) pci dev 1d:7 INTD->IRQ5
(d24) RAM in high memory; setting high_mem resource base to 10800
(d24) pci dev 05:0 bar 10 size 00400: 0f000
(d24) pci dev 05:0 bar 14 size 00400: 0f400
(d24) pci dev 02:0 bar 14 size 00100: 0f808
(d24) pci dev 06:0 bar 30 size 4: 0f900
(d24) pci dev 05:0 bar 30 size 1: 0f904
(d24) pci dev 03:0 bar 10 size 04000: 0f905
(d24) pci dev 05:0 bar 18 size 02000: 0f9054000
(d24) pci dev 04:0 bar 14 size 01000: 0f9056000
(d24) pci dev 1d:7 bar 10 size 01000: 0f9057000
(d24) pci dev 02:0 bar 10 size 00100: 0c001
(d24) pci dev 06:0 bar 10 size 00100: 0c101
(d24) pci dev 06:0 bar 14 size 00100: 0f9058000
(d24) pci dev 04:0 bar 10 size 00020: 0c201
(d24) pci dev 05:0 bar 1c size 00020: 0c221
(d24) pci dev 1d:0 bar 20 size 00020: 0c241
(d24) pci dev 1d:1 bar 20 size 00020: 0c261
(d24) pci dev 1d:2 bar 20 size 00020: 0c281
(d24) pci dev 01:1 bar 20 size 00010: 0c2a1
(d24) Multiprocessor initialisation:
(d24)  - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] ...

[Xen-devel] [PATCH] tools: create XEN_DUMP_DIR with mode 0700

That directory is used to store guest memory dump which contains
sensitive information.

Signed-off-by: Wei Liu 
---
 tools/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/Makefile b/tools/Makefile
index 2618559..820ca40 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -58,7 +58,7 @@ build all: subdirs-all
 
 .PHONY: install
 install: subdirs-install
-   $(INSTALL_DIR) $(DESTDIR)$(XEN_DUMP_DIR)
+   $(INSTALL_DIR) -m 700 $(DESTDIR)$(XEN_DUMP_DIR)
$(INSTALL_DIR) $(DESTDIR)/var/log/xen
$(INSTALL_DIR) $(DESTDIR)/var/lib/xen
 
-- 
2.1.4


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

Re: [Xen-devel] [PATCH OSSTEST] Switch to merged qemu-xen{, -traditional}.git trees

On Wed, 2015-10-21 at 14:15 +0100, Ian Campbell wrote:
> >  * Remove the old staging/qemu-upstream-* trees, they are not
> >referenced by anything.
> 
> Done (by move aside a discussed above).

This was premature and I have put them back.

The reason is that all osstest flights prior to the updated patch were
cloning from the staging URL.

This is because ap-print-url doesn't distinguish e.g. flights on qemu
-upstream-4-2-testing from flights on xen-4.2-testing and used staging/
since that would always have all the commits in it.

This ends up in tree_qemuu in the 4.2-testing flight and then tries to be
used for bisections and breaks.

These trees can be removed as part of:

> Including a new step:
> 
>  * Remove non-staging qemu-upstream-unstable.git and qemu-xen-unstable.git
>which can occur once any flights which might use them have been and gone
>(including possible bisect attempts)

I am also going to go an unbless some bisection flights which have failed
due to this.

Ian.

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

[Xen-devel] [PATCH QEMU-XEN v4 3/9] xen: Switch to libxengnttab interface for compat shims.

In Xen 4.7 we are refactoring parts libxenctrl into a number of
separate libraries which will provide backward and forward API and ABI
compatiblity.

One such library will be libxengnttab which provides access to grant
tables.

In preparation for this switch the compatibility layer in xen_common.h
(which support building with older versions of Xen) to use what will
be the new library API. This means that the gnttab shim will disappear
for versions of Xen which include libxengnttab.

To simplify things for the <= 4.0.0 support we wrap the int fd in a
malloc(sizeof int) such that the handle is always a pointer. This
leads to less typedef headaches and the need for
XC_HANDLER_INITIAL_VALUE etc for these interfaces.

Build tested with 4.0 and 4.5.

Note that this patch does not add any support for actually using
libxengnttab, it just adjusts the existing shims.

Signed-off-by: Ian Campbell 
---
v4: Ran checkpatch, fixed all errors
Allocate correct size for handle (i.e. not size of the ptr)
Rebase onto "xen_console: correctly cleanup primary console on
teardown."
---
 hw/block/xen_disk.c  | 38 --
 hw/char/xen_console.c|  4 ++--
 hw/net/xen_nic.c | 16 
 hw/xen/xen_backend.c | 10 +-
 include/hw/xen/xen_backend.h |  2 +-
 include/hw/xen/xen_common.h  | 42 --
 6 files changed, 68 insertions(+), 44 deletions(-)

diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
index 21842a0..15413f6 100644
--- a/hw/block/xen_disk.c
+++ b/hw/block/xen_disk.c
@@ -172,11 +172,11 @@ static gint int_cmp(gconstpointer a, gconstpointer b, 
gpointer user_data)
 static void destroy_grant(gpointer pgnt)
 {
 PersistentGrant *grant = pgnt;
-XenGnttab gnt = grant->blkdev->xendev.gnttabdev;
+xengnttab_handle *gnt = grant->blkdev->xendev.gnttabdev;
 
-if (xc_gnttab_munmap(gnt, grant->page, 1) != 0) {
+if (xengnttab_munmap(gnt, grant->page, 1) != 0) {
 xen_be_printf(>blkdev->xendev, 0,
-  "xc_gnttab_munmap failed: %s\n",
+  "xengnttab_munmap failed: %s\n",
   strerror(errno));
 }
 grant->blkdev->persistent_gnt_count--;
@@ -189,11 +189,11 @@ static void remove_persistent_region(gpointer data, 
gpointer dev)
 {
 PersistentRegion *region = data;
 struct XenBlkDev *blkdev = dev;
-XenGnttab gnt = blkdev->xendev.gnttabdev;
+xengnttab_handle *gnt = blkdev->xendev.gnttabdev;
 
-if (xc_gnttab_munmap(gnt, region->addr, region->num) != 0) {
+if (xengnttab_munmap(gnt, region->addr, region->num) != 0) {
 xen_be_printf(>xendev, 0,
-  "xc_gnttab_munmap region %p failed: %s\n",
+  "xengnttab_munmap region %p failed: %s\n",
   region->addr, strerror(errno));
 }
 xen_be_printf(>xendev, 3,
@@ -328,7 +328,7 @@ err:
 
 static void ioreq_unmap(struct ioreq *ioreq)
 {
-XenGnttab gnt = ioreq->blkdev->xendev.gnttabdev;
+xengnttab_handle *gnt = ioreq->blkdev->xendev.gnttabdev;
 int i;
 
 if (ioreq->num_unmap == 0 || ioreq->mapped == 0) {
@@ -338,8 +338,9 @@ static void ioreq_unmap(struct ioreq *ioreq)
 if (!ioreq->pages) {
 return;
 }
-if (xc_gnttab_munmap(gnt, ioreq->pages, ioreq->num_unmap) != 0) {
-xen_be_printf(>blkdev->xendev, 0, "xc_gnttab_munmap failed: 
%s\n",
+if (xengnttab_munmap(gnt, ioreq->pages, ioreq->num_unmap) != 0) {
+xen_be_printf(>blkdev->xendev, 0,
+  "xengnttab_munmap failed: %s\n",
   strerror(errno));
 }
 ioreq->blkdev->cnt_map -= ioreq->num_unmap;
@@ -349,8 +350,9 @@ static void ioreq_unmap(struct ioreq *ioreq)
 if (!ioreq->page[i]) {
 continue;
 }
-if (xc_gnttab_munmap(gnt, ioreq->page[i], 1) != 0) {
-xen_be_printf(>blkdev->xendev, 0, "xc_gnttab_munmap 
failed: %s\n",
+if (xengnttab_munmap(gnt, ioreq->page[i], 1) != 0) {
+xen_be_printf(>blkdev->xendev, 0,
+  "xengnttab_munmap failed: %s\n",
   strerror(errno));
 }
 ioreq->blkdev->cnt_map--;
@@ -362,7 +364,7 @@ static void ioreq_unmap(struct ioreq *ioreq)
 
 static int ioreq_map(struct ioreq *ioreq)
 {
-XenGnttab gnt = ioreq->blkdev->xendev.gnttabdev;
+xengnttab_handle *gnt = ioreq->blkdev->xendev.gnttabdev;
 uint32_t domids[BLKIF_MAX_SEGMENTS_PER_REQUEST];
 uint32_t refs[BLKIF_MAX_SEGMENTS_PER_REQUEST];
 void *page[BLKIF_MAX_SEGMENTS_PER_REQUEST];
@@ -413,7 +415,7 @@ static int ioreq_map(struct ioreq *ioreq)
 }
 
 if (batch_maps && new_maps) {
-ioreq->pages = xc_gnttab_map_grant_refs
+ioreq->pages = xengnttab_map_grant_refs
 (gnt, new_maps, domids, refs,

[Xen-devel] [PATCH MINI-OS v4 5/5] mini-os: Include libxenforeignmemory with libxc

libxenforeignmemory has just been split out from libxc. From mini-os's
point of view we don't care about the distinction, so keep things
simple by just including libxenforeignmemory if libxc is enabled.

Signed-off-by: Ian Campbell 
---
v2: Adjust for libs/$lib layout.
---
 Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Makefile b/Makefile
index c900540..cfe015a 100644
--- a/Makefile
+++ b/Makefile
@@ -169,6 +169,7 @@ APP_LDLIBS += 
-L$(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/toollog -whole-ar
 APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/evtchn 
-whole-archive -lxenevtchn -no-whole-archive
 APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/gnttab 
-whole-archive -lxengnttab -no-whole-archive
 APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/call 
-whole-archive -lxencall -no-whole-archive
+APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/foreignmemory 
-whole-archive -lxenforeignmemory -no-whole-archive
 APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libxc-$(MINIOS_TARGET_ARCH) -whole-archive 
-lxenguest -lxenctrl -no-whole-archive
 endif
 APP_LDLIBS += -lpci
-- 
2.1.4


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

[Xen-devel] [PATCH MINI-OS v4 2/5] mini-os: Include libxenevtchn with libxc

libxenevtchn has just been split out from libxc. From mini-os's point
of view we don't care about the distinction, so keep things simple by
just including libxenevtchn if libxc is enabled.

Signed-off-by: Ian Campbell 
---
v2: Adjust for libs/$lib layout.
---
 Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Makefile b/Makefile
index daee46c..d1d8dc4 100644
--- a/Makefile
+++ b/Makefile
@@ -166,6 +166,7 @@ OBJS := $(filter-out $(OBJ_DIR)/lwip%.o $(LWO), $(OBJS))
 ifeq ($(libc),y)
 ifeq ($(CONFIG_XC),y)
 APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/toollog 
-whole-archive -lxentoollog -no-whole-archive
+APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/evtchn 
-whole-archive -lxenevtchn -no-whole-archive
 APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libxc-$(MINIOS_TARGET_ARCH) -whole-archive 
-lxenguest -lxenctrl -no-whole-archive
 endif
 APP_LDLIBS += -lpci
-- 
2.1.4


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

[Xen-devel] [PATCH XEN v4 05/23] tools: Arrange to check public headers for ANSI compatiblity

Using the same rune as we use for the Xen public headers, except we do
not need stdint.h here and we use -pedantic too.

Signed-off-by: Ian Campbell 
---
 .gitignore  | 2 ++
 tools/Rules.mk  | 8 
 tools/libs/evtchn/Makefile  | 4 +++-
 tools/libs/toollog/Makefile | 5 -
 4 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/.gitignore b/.gitignore
index bf382e5..b34dc3c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -86,6 +86,8 @@ tools/config.cache
 config/Tools.mk
 config/Stubdom.mk
 config/Docs.mk
+tools/libs/toollog/headers.chk
+tools/libs/evtchn/headers.chk
 tools/blktap2/daemon/blktapctrl
 tools/blktap2/drivers/img2qcow
 tools/blktap2/drivers/lock-util
diff --git a/tools/Rules.mk b/tools/Rules.mk
index 29d01b4..1ca3fcc 100644
--- a/tools/Rules.mk
+++ b/tools/Rules.mk
@@ -176,6 +176,14 @@ INSTALL_PYTHON_PROG = \
 %.opic: %.S
$(CC) $(CPPFLAGS) -DPIC $(CFLAGS) $(CFLAGS.opic) -fPIC -c -o $@ $< 
$(APPEND_CFLAGS)
 
+headers.chk:
+   for i in $(filter %.h,$^); do \
+   $(CC) -x c -ansi -Wall -Werror -pedantic $(CFLAGS_xeninclude) \
+ -S -o /dev/null $$i || exit 1; \
+   echo $$i; \
+   done >$@.new
+   mv $@.new $@
+
 subdirs-all subdirs-clean subdirs-install subdirs-distclean: .phony
@set -e; for subdir in $(SUBDIRS) $(SUBDIRS-y); do \
$(MAKE) subdir-$(patsubst subdirs-%,%,$@)-$$subdir; \
diff --git a/tools/libs/evtchn/Makefile b/tools/libs/evtchn/Makefile
index 85ed6dc..892892c 100644
--- a/tools/libs/evtchn/Makefile
+++ b/tools/libs/evtchn/Makefile
@@ -32,8 +32,9 @@ build:
$(MAKE) libs
 
 .PHONY: libs
-libs: $(LIB)
+libs: headers.chk $(LIB)
 
+headers.chk: $(wildcard include/*.h)
 
 libxenevtchn.a: $(LIB_OBJS)
$(AR) rc $@ $^
@@ -63,3 +64,4 @@ TAGS:
 .PHONY: clean
 clean:
rm -rf *.rpm $(LIB) *~ $(DEPS) $(LIB_OBJS) $(PIC_OBJS)
+   rm -f headers.chk
diff --git a/tools/libs/toollog/Makefile b/tools/libs/toollog/Makefile
index bd12403..72c70c9 100644
--- a/tools/libs/toollog/Makefile
+++ b/tools/libs/toollog/Makefile
@@ -27,7 +27,9 @@ build:
$(MAKE) libs
 
 .PHONY: libs
-libs: $(LIB)
+libs: headers.chk $(LIB)
+
+headers.chk: $(wildcard include/*.h)
 
 libxentoollog.a: $(LIB_OBJS)
$(AR) rc $@ $^
@@ -57,3 +59,4 @@ TAGS:
 .PHONY: clean
 clean:
rm -rf *.rpm $(LIB) *~ $(DEPS) $(LIB_OBJS) $(PIC_OBJS)
+   rm -f headers.chk
-- 
2.1.4


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

[Xen-devel] [PATCH QEMU-XEN-TRADITIONAL v4 3/5] qemu-xen-traditional: Use libxengnttab

/dev/xen/gntdev related wrappers have been moved out of libxenctrl
into their own library.

Signed-off-by: Ian Campbell 
---
v3: Library moved to tools/libs/
---
 hw/xen_backend.c |  4 ++--
 hw/xen_backend.h |  2 +-
 hw/xen_common.h  |  1 +
 hw/xen_console.c |  4 ++--
 hw/xen_disk.c| 24 
 xen-hooks.mak|  2 ++
 6 files changed, 20 insertions(+), 17 deletions(-)

diff --git a/hw/xen_backend.c b/hw/xen_backend.c
index 40f6887..97d25da 100644
--- a/hw/xen_backend.c
+++ b/hw/xen_backend.c
@@ -217,7 +217,7 @@ static struct XenDevice *xen_be_get_xendev(const char 
*type, int dom, int dev,
 fcntl(xenevtchn_fd(xendev->evtchndev), F_SETFD, FD_CLOEXEC);
 
 if (ops->flags & DEVOPS_FLAG_NEED_GNTDEV) {
-   xendev->gnttabdev = xc_gnttab_open(NULL, 0);
+   xendev->gnttabdev = xengnttab_open(NULL, 0);
if (xendev->gnttabdev == NULL) {
xen_be_printf(NULL, 0, "can't open gnttab device\n");
xenevtchn_close(xendev->evtchndev);
@@ -270,7 +270,7 @@ static struct XenDevice *xen_be_del_xendev(int dom, int dev)
if (xendev->evtchndev != NULL)
xenevtchn_close(xendev->evtchndev);
if (xendev->gnttabdev != NULL)
-   xc_gnttab_close(xendev->gnttabdev);
+   xengnttab_close(xendev->gnttabdev);
 
TAILQ_REMOVE(, xendev, next);
qemu_free(xendev);
diff --git a/hw/xen_backend.h b/hw/xen_backend.h
index 60f18f8..ba1e12f 100644
--- a/hw/xen_backend.h
+++ b/hw/xen_backend.h
@@ -45,7 +45,7 @@ struct XenDevice {
 intlocal_port;
 
 xenevtchn_handle   *evtchndev;
-xc_gnttab  *gnttabdev;
+xengnttab_handle  *gnttabdev;
 
 struct XenDevOps   *ops;
 TAILQ_ENTRY(XenDevice) next;
diff --git a/hw/xen_common.h b/hw/xen_common.h
index cee908f..cc48892 100644
--- a/hw/xen_common.h
+++ b/hw/xen_common.h
@@ -5,6 +5,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/hw/xen_console.c b/hw/xen_console.c
index 80beb31..76c4e93 100644
--- a/hw/xen_console.c
+++ b/hw/xen_console.c
@@ -230,7 +230,7 @@ static int con_initialise(struct XenDevice *xendev)
   PROT_READ|PROT_WRITE,
   con->ring_ref);
 else
-con->sring = xc_gnttab_map_grant_ref(xendev->gnttabdev, 
con->xendev.dom,
+con->sring = xengnttab_map_grant_ref(xendev->gnttabdev, 
con->xendev.dom,
  con->ring_ref,
  PROT_READ|PROT_WRITE);
 if (!con->sring)
@@ -263,7 +263,7 @@ static void con_disconnect(struct XenDevice *xendev)
 if (!xendev->gnttabdev)
munmap(con->sring, XC_PAGE_SIZE);
 else
-xc_gnttab_munmap(xendev->gnttabdev, con->sring, 1);
+xengnttab_munmap(xendev->gnttabdev, con->sring, 1);
con->sring = NULL;
 }
 }
diff --git a/hw/xen_disk.c b/hw/xen_disk.c
index 250d806..6ccf073 100644
--- a/hw/xen_disk.c
+++ b/hw/xen_disk.c
@@ -266,7 +266,7 @@ err:
 
 static void ioreq_unmap(struct ioreq *ioreq)
 {
-xc_gnttab *gnt = ioreq->blkdev->xendev.gnttabdev;
+xengnttab_handle *gnt = ioreq->blkdev->xendev.gnttabdev;
 int i;
 
 if (ioreq->v.niov == 0)
@@ -274,8 +274,8 @@ static void ioreq_unmap(struct ioreq *ioreq)
 if (batch_maps) {
if (!ioreq->pages)
return;
-   if (xc_gnttab_munmap(gnt, ioreq->pages, ioreq->v.niov) != 0)
-   xen_be_printf(>blkdev->xendev, 0, "xc_gnttab_munmap failed: 
%s\n",
+   if (xengnttab_munmap(gnt, ioreq->pages, ioreq->v.niov) != 0)
+   xen_be_printf(>blkdev->xendev, 0, "xengnttab_munmap failed: 
%s\n",
  strerror(errno));
ioreq->blkdev->cnt_map -= ioreq->v.niov;
ioreq->pages = NULL;
@@ -283,8 +283,8 @@ static void ioreq_unmap(struct ioreq *ioreq)
for (i = 0; i < ioreq->v.niov; i++) {
if (!ioreq->page[i])
continue;
-   if (xc_gnttab_munmap(gnt, ioreq->page[i], 1) != 0)
-   xen_be_printf(>blkdev->xendev, 0, "xc_gnttab_munmap 
failed: %s\n",
+   if (xengnttab_munmap(gnt, ioreq->page[i], 1) != 0)
+   xen_be_printf(>blkdev->xendev, 0, "xengnttab_munmap 
failed: %s\n",
  strerror(errno));
ioreq->blkdev->cnt_map--;
ioreq->page[i] = NULL;
@@ -294,13 +294,13 @@ static void ioreq_unmap(struct ioreq *ioreq)
 
 static int ioreq_map(struct ioreq *ioreq)
 {
-xc_gnttab *gnt = ioreq->blkdev->xendev.gnttabdev;
+xengnttab_handle *gnt = ioreq->blkdev->xendev.gnttabdev;
 int i;
 
 if (ioreq->v.niov == 0)
 return 0;
 if (batch_maps) {
-   ioreq->pages = xc_gnttab_map_grant_refs
+   ioreq->pages = xengnttab_map_grant_refs
(gnt, ioreq->v.niov, ioreq->domids, ioreq->refs, ioreq->prot);
if (ioreq->pages == NULL) {

[Xen-devel] [PATCH MINI-OS v4 4/5] mini-os: Include libxencall with libxc

libxencall has just been split out from libxc. From mini-os's point
of view we don't care about the distinction, so keep things simple by
just including libxencall if libxc is enabled.

Signed-off-by: Ian Campbell 
---
v2: Adjust for libs/$lib layout.
---
 Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Makefile b/Makefile
index 521f647..c900540 100644
--- a/Makefile
+++ b/Makefile
@@ -168,6 +168,7 @@ ifeq ($(CONFIG_XC),y)
 APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/toollog 
-whole-archive -lxentoollog -no-whole-archive
 APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/evtchn 
-whole-archive -lxenevtchn -no-whole-archive
 APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/gnttab 
-whole-archive -lxengnttab -no-whole-archive
+APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/call 
-whole-archive -lxencall -no-whole-archive
 APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libxc-$(MINIOS_TARGET_ARCH) -whole-archive 
-lxenguest -lxenctrl -no-whole-archive
 endif
 APP_LDLIBS += -lpci
-- 
2.1.4


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

[Xen-devel] [PATCH MINI-OS v4 0/5] Begin to disentangle libxenctrl and provide some stable libraries

We intend to stabilise some parts of the libxenctrl interface by
splitting out some functionality into separate stable libraries.

This is the mini-os part of the first phase of that change.

This mail is (or is intended to be) a reply to a "0/"
super-intro mail covering all of the related patch series and which
contains more details.

Ian Campbell (5):
  mini-os: Include libxentoollog with libxc
  mini-os: Include libxenevtchn with libxc
  mini-os: Include libxengnttab with libxc
  mini-os: Include libxencall with libxc
  mini-os: Include libxenforeignmemory with libxc

 Makefile | 5 +
 1 file changed, 5 insertions(+)

-- 
2.1.4


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

[Xen-devel] [PATCH MINI-OS v4 3/5] mini-os: Include libxengnttab with libxc

libxengnttab has just been split out from libxc. From mini-os's point
of view we don't care about the distinction, so keep things simple by
just including libxengnttab if libxc is enabled.

Signed-off-by: Ian Campbell 
---
v2: Adjust for libs/$lib layout.
---
 Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Makefile b/Makefile
index d1d8dc4..521f647 100644
--- a/Makefile
+++ b/Makefile
@@ -167,6 +167,7 @@ ifeq ($(libc),y)
 ifeq ($(CONFIG_XC),y)
 APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/toollog 
-whole-archive -lxentoollog -no-whole-archive
 APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/evtchn 
-whole-archive -lxenevtchn -no-whole-archive
+APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/gnttab 
-whole-archive -lxengnttab -no-whole-archive
 APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libxc-$(MINIOS_TARGET_ARCH) -whole-archive 
-lxenguest -lxenctrl -no-whole-archive
 endif
 APP_LDLIBS += -lpci
-- 
2.1.4


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

[Xen-devel] [PATCH MINI-OS v4 1/5] mini-os: Include libxentoollog with libxc

libxentoollog has just been split out from libxc. From mini-os's point
of view we don't care about the distinction, so keep things simple by
just including libxentoollog if libxc is enabled.

Signed-off-by: Ian Campbell 
---
v2: Adjust for libs/$lib layout.
---
 Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Makefile b/Makefile
index 2cb5e51..daee46c 100644
--- a/Makefile
+++ b/Makefile
@@ -165,6 +165,7 @@ OBJS := $(filter-out $(OBJ_DIR)/lwip%.o $(LWO), $(OBJS))
 
 ifeq ($(libc),y)
 ifeq ($(CONFIG_XC),y)
+APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/toollog 
-whole-archive -lxentoollog -no-whole-archive
 APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libxc-$(MINIOS_TARGET_ARCH) -whole-archive 
-lxenguest -lxenctrl -no-whole-archive
 endif
 APP_LDLIBS += -lpci
-- 
2.1.4


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

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

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a

version targeted for testing:
 libvirt  1b4de77e852e37c157ad241f9b4ece9a271a43cc
baseline version:
 libvirt  6222a6fee3f01f4fab8b45cacc9776170bf6dcd4

Last test of basis63022  2015-10-17 04:39:57 Z4 days
Testing same since63106  2015-10-21 04:34:52 Z0 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Maxim Nestratov 

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



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 1b4de77e852e37c157ad241f9b4ece9a271a43cc
Author: Andrea Bolognani 
Date:   Tue Oct 13 09:44:13 2015 +0200

NEWS: Fix XSLT stylesheet

This has been broken for a looong

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

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a

version targeted for testing:
 ovmf f4c3c92396c9b146bc99dcba80001591cc45ba3e
baseline version:
 ovmf 47022e82e1e59f59d375dd66847e93cea7b6a771

Last test of basis63081  2015-10-20 02:08:56 Z1 days
Testing same since63109  2015-10-21 07:10:50 Z0 days1 attempts


People who touched revisions under test:
  Eric Dong 

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



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 f4c3c92396c9b146bc99dcba80001591cc45ba3e
Author: Eric Dong 
Date:   Wed Oct 21 06:10:57 2015 +

MdeModulePkg SetupBrowserDxe: Save global variable values before nest 
function called.

The SendForm function can be called nest in it. This function also uses 
some global variables. So we must save global variable values before it been 
called again.

Old implementation miss to save some global variables, this patch fixed it.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Eric Dong 
Reviewed-by: Liming Gao 

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18650 
6f19259b-4bc3-4df7-8a09-765794883524

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

Re: [Xen-devel] [PATCH OSSTEST] Switch to merged qemu-xen{, -traditional}.git trees

On Wed, 2015-10-21 at 15:12 +0100, Ian Campbell wrote:
> On Wed, 2015-10-21 at 14:15 +0100, Ian Campbell wrote:
> > >  * Remove the old staging/qemu-upstream-* trees, they are not
> > >referenced by anything.
> > 
> > Done (by move aside a discussed above).
> 
> This was premature and I have put them back.
> 
> The reason is that all osstest flights prior to the updated patch were
> cloning from the staging URL.
> 
> This is because ap-print-url doesn't distinguish e.g. flights on qemu
> -upstream-4-2-testing from flights on xen-4.2-testing and used staging/
> since that would always have all the commits in it.
> 
> This ends up in tree_qemuu in the 4.2-testing flight and then tries to be
> used for bisections and breaks.

This reasoning also applies to the qemu-xen-trad trees, which end up in
tree_qemu.

Hence I've put those ones back too.

Ian.


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

[Xen-devel] [linux-mingo-tip-master test] 63105: regressions - trouble: blocked/fail

flight 63105 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63105/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-xsm5 xen-build fail REGR. vs. 60684
 build-amd64   5 xen-build fail REGR. vs. 60684
 build-amd64-xsm   5 xen-build fail REGR. vs. 60684
 build-amd64-pvops 5 kernel-build  fail REGR. vs. 60684
 build-i3865 xen-build fail REGR. vs. 60684
 build-i386-pvops  5 kernel-build  fail REGR. vs. 60684

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

Re: [Xen-devel] [PATCH] tools/xenpaging: install directory with default permission

On Wed, 2015-10-21 at 13:10 +0100, Wei Liu wrote:
> There is no need to explicitly ask for 700.

Is the rationale for 0700 explicitly not that the files in here will
contain possibly sensitive date from guest memory?

i.e. the use of something other than the default is deliberate.

If you think that is wrong then I think the changelog should explain why.


> Signed-off-by: Wei Liu 
> ---
>  tools/xenpaging/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/xenpaging/Makefile b/tools/xenpaging/Makefile
> index 2407a30..4badaae 100644
> --- a/tools/xenpaging/Makefile
> +++ b/tools/xenpaging/Makefile
> @@ -24,7 +24,7 @@ xenpaging: $(OBJS)
>   $(CC) $(LDFLAGS) -o $@ $^ $(LDLIBS) $(APPEND_LDFLAGS)
>  
>  install: all
> - $(INSTALL_DIR) -m 0700 $(DESTDIR)$(XEN_PAGING_DIR)
> + $(INSTALL_DIR) $(DESTDIR)$(XEN_PAGING_DIR)
>   $(INSTALL_DIR) $(DESTDIR)$(LIBEXEC_BIN)
>   $(INSTALL_PROG) $(IBINS) $(DESTDIR)$(LIBEXEC_BIN)
>  

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

[Xen-devel] [PATCH XEN v4 13/23] tools: Refactor foreign memory mapping into libxenforeignmemory

libxenforeignmemory will provide a stable API and ABI for mapping
foreign domain memory (subject to appropriate privileges).

The new library exposes an interface equivalent to
xc_map_foreign_memory_bulk, which all the other
xc_map_foreign_memory_* functions (which remain in libxc) are
implemented in terms of.

Upon request (via #define XC_WANT_COMPAT_MAP_FOREIGN_API) libxenctrl
will provide a compat API for the old names. This is used by qemu-xen
and qemu-trad as well as various in tree things (which required
de-dupping various #includes in some too to get the #define before the
first).

Signed-off-by: Ian Campbell 
---
Must be applied with:
  - "qemu-xen-traditional: qemu-xen-traditional: Add
libxenforeignmemory to rpath-link" and a corresponding QEMU_TAG
update folded here.
  - "mini-os: mini-os: Include libxenforeignmemory with libxc" and a
corresponding bump to MINIOS_UPSTREAM_REVISION folded in here.
---
 .gitignore |  2 +
 stubdom/Makefile   | 20 -
 tools/Makefile |  2 +
 tools/Rules.mk | 11 ++-
 tools/console/daemon/utils.c   |  1 -
 tools/console/daemon/utils.h   |  1 +
 tools/libs/Makefile|  1 +
 tools/libs/foreignmemory/Makefile  | 67 +++
 tools/libs/foreignmemory/compat.c  | 72 
 tools/libs/foreignmemory/core.c| 68 
 .../foreignmemory/freebsd.c}   | 33 +++-
 .../libs/foreignmemory/include/xenforeignmemory.h  | 71 
 tools/libs/foreignmemory/libxenforeignmemory.map   |  7 ++
 .../foreignmemory/linux.c} | 70 +++-
 tools/libs/foreignmemory/minios.c  | 62 ++
 tools/libs/foreignmemory/netbsd.c  | 95 ++
 tools/libs/foreignmemory/private.h | 47 +++
 tools/libs/foreignmemory/solaris.c | 94 +
 tools/libxc/Makefile   |  8 +-
 tools/libxc/include/xenctrl.h  | 26 --
 tools/libxc/include/xenctrl_compat.h   | 36 
 tools/libxc/xc_foreign_memory.c| 49 +--
 tools/libxc/xc_minios.c| 29 ---
 tools/libxc/xc_netbsd.c| 73 -
 tools/libxc/xc_private.c   | 13 +--
 tools/libxc/xc_private.h   | 11 ++-
 tools/libxc/xc_solaris.c   | 73 -
 tools/libxc/xc_sr_restore.c|  4 +-
 tools/libxc/xc_sr_save.c   |  4 +-
 tools/libxc/xc_vm_event.c  | 10 ++-
 tools/libxc/xg_private.h   |  3 +-
 tools/libxl/libxl_internal.h   |  1 +
 tools/misc/xen-mfndump.c   |  1 +
 tools/ocaml/libs/xc/xenctrl_stubs.c|  1 +
 tools/python/xen/lowlevel/xc/xc.c  |  2 +-
 tools/xenmon/xenbaked.c|  1 +
 tools/xenpaging/pagein.c   |  1 -
 tools/xenpaging/xenpaging.c|  1 -
 tools/xenpaging/xenpaging.h|  2 +
 tools/xenstore/xenstored_core.c|  1 -
 tools/xenstore/xenstored_core.h|  1 +
 tools/xentrace/xenctx.c|  3 +-
 tools/xentrace/xentrace.c  |  1 +
 43 files changed, 740 insertions(+), 339 deletions(-)
 create mode 100644 tools/libs/foreignmemory/Makefile
 create mode 100644 tools/libs/foreignmemory/compat.c
 create mode 100644 tools/libs/foreignmemory/core.c
 rename tools/{libxc/xc_freebsd_osdep.c => libs/foreignmemory/freebsd.c} (76%)
 create mode 100644 tools/libs/foreignmemory/include/xenforeignmemory.h
 create mode 100644 tools/libs/foreignmemory/libxenforeignmemory.map
 rename tools/{libxc/xc_linux_osdep.c => libs/foreignmemory/linux.c} (83%)
 create mode 100644 tools/libs/foreignmemory/minios.c
 create mode 100644 tools/libs/foreignmemory/netbsd.c
 create mode 100644 tools/libs/foreignmemory/private.h
 create mode 100644 tools/libs/foreignmemory/solaris.c

diff --git a/.gitignore b/.gitignore
index 2899852..2549337 100644
--- a/.gitignore
+++ b/.gitignore
@@ -62,6 +62,7 @@ stubdom/libxentoollog-*
 stubdom/libxenevtchn-*
 stubdom/libxengnttab-*
 stubdom/libxencall-*
+stubdom/libxenforeignmemory-*
 stubdom/libxc-*
 stubdom/lwip-*
 stubdom/mini-os-*
@@ -92,6 +93,7 @@ tools/libs/toollog/headers.chk
 tools/libs/evtchn/headers.chk
 tools/libs/gnttab/headers.chk
 tools/libs/call/headers.chk
+tools/libs/foreignmemory/headers.chk
 tools/blktap2/daemon/blktapctrl
 tools/blktap2/drivers/img2qcow

[Xen-devel] [PATCH XEN v4 16/23] tools/libs/evtchn: Review and update doc comments.

Remove the reference to pre-4.1, since this is now a new library.

Fixup references to xc.

Signed-off-by: Ian Campbell 
---
 tools/libs/evtchn/include/xenevtchn.h | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/tools/libs/evtchn/include/xenevtchn.h 
b/tools/libs/evtchn/include/xenevtchn.h
index 3380fa3..60da2a3 100644
--- a/tools/libs/evtchn/include/xenevtchn.h
+++ b/tools/libs/evtchn/include/xenevtchn.h
@@ -46,11 +46,9 @@ typedef struct xentoollog_logger xentoollog_logger;
  * which case errno will be set appropriately.
  *
  * Note:
- * After fork a child process must not use any opened xc evtchn
+ * After fork a child process must not use any opened evtchn
  * handle inherited from their parent. They must open a new handle if
- * they want to interact with xc.
- *
- * Before Xen pre-4.1 this function would sometimes report errors with perror.
+ * they want to interact with evtchn.
  */
 /* Currently no flags are defined */
 xenevtchn_handle *xenevtchn_open(xentoollog_logger *logger, unsigned 
open_flags);
-- 
2.1.4


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

[Xen-devel] [PATCH QEMU-XEN v4 8/9] xen: domainbuild: reopen libxenctrl interface after forking for domain watcher.

Using an existing libxenctrl handle after a fork was never
particularly safe (especially if foreign mappings existed at the time
of the fork) and the xc fd has been unavailable for many releases.

Reopen the handle after fork and therefore do away with xc_fd().

Signed-off-by: Ian Campbell 
Acked-by: Stefano Stabellini 
---
The fact that xc_fd hasn't been useful since at least Xen 4.1 makes me
question the utility of this domainbuild in QEMU. Perhaps we should
just nuke it?
---
 hw/xenpv/xen_domainbuild.c  |  9 ++---
 include/hw/xen/xen_common.h | 17 -
 2 files changed, 6 insertions(+), 20 deletions(-)

diff --git a/hw/xenpv/xen_domainbuild.c b/hw/xenpv/xen_domainbuild.c
index c0ab753..3e8422f 100644
--- a/hw/xenpv/xen_domainbuild.c
+++ b/hw/xenpv/xen_domainbuild.c
@@ -174,12 +174,15 @@ static int xen_domain_watcher(void)
 for (i = 3; i < n; i++) {
 if (i == fd[0])
 continue;
-if (i == xc_fd(xen_xc)) {
-continue;
-}
 close(i);
 }
 
+/*
+ * Reopen xc interface, since the original is unsafe after fork
+ * and was closed above.
+ */
+xen_xc = xc_interface_open(0, 0, 0);
+
 /* ignore term signals */
 signal(SIGINT,  SIG_IGN);
 signal(SIGTERM, SIG_IGN);
diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
index 38293b4..4b4b50d 100644
--- a/include/hw/xen/xen_common.h
+++ b/include/hw/xen/xen_common.h
@@ -121,12 +121,6 @@ static inline XenXC xen_xc_interface_open(void *logger, 
void *dombuild_logger,
 xc_map_foreign_bulk(*h, d, p, a, e, n)
 #define xenforeignmemory_unmap(h, p, s) munmap(p, s * XC_PAGE_SIZE)
 
-static inline int xc_fd(int xen_xc)
-{
-return xen_xc;
-}
-
-
 static inline int xc_domain_populate_physmap_exact
 (XenXC xc_handle, uint32_t domid, unsigned long nr_extents,
  unsigned int extent_order, unsigned int mem_flags, xen_pfn_t 
*extent_start)
@@ -201,11 +195,6 @@ static inline XenXC xen_xc_interface_open(void *logger, 
void *dombuild_logger,
 xc_map_foreign_bulk(*h, d, p, a, e, n)
 #define xenforeignmemory_unmap(h, p, s) munmap(p, s * XC_PAGE_SIZE)
 
-/* FIXME There is now way to have the xen fd */
-static inline int xc_fd(xc_interface *xen_xc)
-{
-return -1;
-}
 #else /* CONFIG_XEN_CTRL_INTERFACE_VERSION >= 470 */
 
 typedef xc_interface *XenXC;
@@ -223,12 +212,6 @@ static inline XenXC xen_xc_interface_open(void *logger, 
void *dombuild_logger,
 return xc_interface_open(logger, dombuild_logger, open_flags);
 }
 
-/* FIXME There is now way to have the xen fd */
-static inline int xc_fd(xc_interface *xen_xc)
-{
-return -1;
-}
-
 #endif
 
 /* Xen before 4.2 */
-- 
2.1.4


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

[Xen-devel] [PATCH XEN v4 19/23] tools/libs/call: Update some log messages to not refer to xc.

Signed-off-by: Ian Campbell 
---
 tools/libs/call/linux.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/libs/call/linux.c b/tools/libs/call/linux.c
index 906ca7e..80b505c 100644
--- a/tools/libs/call/linux.c
+++ b/tools/libs/call/linux.c
@@ -88,7 +88,7 @@ void *osdep_alloc_pages(xencall_handle *xcall, unsigned int 
npages)
 p = mmap(NULL, size, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_ANONYMOUS|MAP_LOCKED, -1, 0);
 if ( p == MAP_FAILED )
 {
-PERROR("xc_alloc_hypercall_buffer: mmap failed");
+PERROR("alloc_pages: mmap failed");
 return NULL;
 }
 
@@ -97,7 +97,7 @@ void *osdep_alloc_pages(xencall_handle *xcall, unsigned int 
npages)
 rc = madvise(p, npages * PAGE_SIZE, MADV_DONTFORK);
 if ( rc < 0 )
 {
-PERROR("xc_alloc_hypercall_buffer: madvise failed");
+PERROR("alloc_pages: madvise failed");
 goto out;
 }
 
-- 
2.1.4


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

[Xen-devel] [PATCH XEN v4 15/23] foreignmemory: use size_t for size arguments.

Surprisingly it appears no callers need updating.

Signed-off-by: Ian Campbell 
---
v4: New patch
---
 tools/libs/foreignmemory/compat.c  |  2 +-
 tools/libs/foreignmemory/freebsd.c |  4 ++--
 .../libs/foreignmemory/include/xenforeignmemory.h  |  4 ++--
 tools/libs/foreignmemory/linux.c   | 25 +++---
 tools/libs/foreignmemory/minios.c  |  6 +++---
 tools/libs/foreignmemory/netbsd.c  |  2 +-
 tools/libs/foreignmemory/solaris.c |  2 +-
 7 files changed, 23 insertions(+), 22 deletions(-)

diff --git a/tools/libs/foreignmemory/compat.c 
b/tools/libs/foreignmemory/compat.c
index df9702e..46c4b55 100644
--- a/tools/libs/foreignmemory/compat.c
+++ b/tools/libs/foreignmemory/compat.c
@@ -23,7 +23,7 @@
 
 void *xc_map_foreign_bulk(xenforeignmem_handle *fmem,
   uint32_t dom, int prot,
-  const xen_pfn_t *arr, int *err, unsigned int num)
+  const xen_pfn_t *arr, int *err, size_t num)
 {
 xen_pfn_t *pfn;
 unsigned int i;
diff --git a/tools/libs/foreignmemory/freebsd.c 
b/tools/libs/foreignmemory/freebsd.c
index f9e74fa..0d71713 100644
--- a/tools/libs/foreignmemory/freebsd.c
+++ b/tools/libs/foreignmemory/freebsd.c
@@ -85,7 +85,7 @@ int osdep_xenforeignmemory_close(xenforeignmemory_handle 
*fmem)
 void *xenforeignmemory_map(xenforeignmemory_handle *fmem,
uint32_t dom, int prot,
const xen_pfn_t *arr, int *err,
-   unsigned int num)
+   size_t num)
 {
 int fd = fmem->fd;
 privcmd_mmapbatch_t ioctlx;
@@ -119,7 +119,7 @@ void *xenforeignmemory_map(xenforeignmemory_handle *fmem,
 }
 
 int xenforeignmemory_unmap(xenforeignmemory_handle *fmem,
-   void *addr, unsigned int num)
+   void *addr, size_t num)
 {
return munmap(addr, num << PAGE_SHIFT);
 }
diff --git a/tools/libs/foreignmemory/include/xenforeignmemory.h 
b/tools/libs/foreignmemory/include/xenforeignmemory.h
index 1bcdf6a..99ec883 100644
--- a/tools/libs/foreignmemory/include/xenforeignmemory.h
+++ b/tools/libs/foreignmemory/include/xenforeignmemory.h
@@ -56,10 +56,10 @@ int xenforeignmemory_close(xenforeignmemory_handle *xmem);
  */
 void *xenforeignmemory_map(xenforeignmemory_handle *fmem, uint32_t dom,
int prot, const xen_pfn_t *arr, int *err,
-   unsigned int num);
+   size_t pages);
 
 int xenforeignmemory_unmap(xenforeignmemory_handle *fmem,
-   void *addr, unsigned int num);
+   void *addr, size_t pages);
 
 #endif
 
diff --git a/tools/libs/foreignmemory/linux.c b/tools/libs/foreignmemory/linux.c
index 86a5a97..3c08679 100644
--- a/tools/libs/foreignmemory/linux.c
+++ b/tools/libs/foreignmemory/linux.c
@@ -109,10 +109,11 @@ static int map_foreign_batch_single(int fd, uint32_t dom,
  * This will keep the request ring full and avoids delays.
  */
 static int retry_paged(int fd, uint32_t dom, void *addr,
-   const xen_pfn_t *arr, int *err, unsigned int num)
+   const xen_pfn_t *arr, int *err, size_t num)
 {
 privcmd_mmapbatch_v2_t ioctlx;
-int rc, paged = 0, i = 0;
+int rc, paged = 0;
+size_t i = 0;
 
 do
 {
@@ -128,7 +129,7 @@ static int retry_paged(int fd, uint32_t dom, void *addr,
 /* At least one gfn is still in paging state */
 ioctlx.num = 1;
 ioctlx.dom = dom;
-ioctlx.addr = (unsigned long)addr + ((unsigned long)i<fd;
 privcmd_mmapbatch_v2_t ioctlx;
 void *addr;
-unsigned int i;
+size_t i;
 int rc;
 
-addr = mmap(NULL, (unsigned long)num << PAGE_SHIFT, prot, MAP_SHARED,
+addr = mmap(NULL, num << PAGE_SHIFT, prot, MAP_SHARED,
 fd, 0);
 if ( addr == MAP_FAILED )
 {
@@ -206,7 +207,7 @@ void *xenforeignmemory_map(xenforeignmemory_handle *fmem,
 if ( pfn == MAP_FAILED )
 {
 PERROR("mmap of pfn array failed");
-(void)munmap(addr, (unsigned long)num << PAGE_SHIFT);
+(void)munmap(addr, num << PAGE_SHIFT);
 return NULL;
 }
 }
@@ -239,7 +240,7 @@ void *xenforeignmemory_map(xenforeignmemory_handle *fmem,

[Xen-devel] [PATCH XEN v4 22/23] tools: Update CFLAGS for qemu-xen to allow it to use new libraries

This means adding -L for libxen{evtchn,gnttab,foreignmemory} so that
it can link them directly (rather than using the libxenctrl compat
layer exposed via -rpath-link). Also add -I for libxenforeignmemory.

Signed-off-by: Ian Campbell 
---
 tools/Makefile | 4 
 1 file changed, 4 insertions(+)

diff --git a/tools/Makefile b/tools/Makefile
index 269cd3e..ef69b69 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -255,12 +255,16 @@ subdir-all-qemu-xen-dir: qemu-xen-dir-find
-I$(XEN_ROOT)/tools/libs/toollog/include \
-I$(XEN_ROOT)/tools/libs/evtchn/include \
-I$(XEN_ROOT)/tools/libs/gnttab/include \
+   -I$(XEN_ROOT)/tools/libs/foreignmemory/include \
-I$(XEN_ROOT)/tools/libxc/include \
-I$(XEN_ROOT)/tools/xenstore/include \
-I$(XEN_ROOT)/tools/xenstore/compat/include \
$(EXTRA_CFLAGS_QEMU_XEN)" \
--extra-ldflags="-L$(XEN_ROOT)/tools/libxc \
-L$(XEN_ROOT)/tools/xenstore \
+   -L$(XEN_ROOT)/tools/libs/evtchn \
+   -L$(XEN_ROOT)/tools/libs/gnttab \
+   -L$(XEN_ROOT)/tools/libs/foreignmemory \
-Wl,-rpath-link=$(XEN_ROOT)/tools/libs/toollog \
-Wl,-rpath-link=$(XEN_ROOT)/tools/libs/evtchn \
-Wl,-rpath-link=$(XEN_ROOT)/tools/libs/gnttab \
-- 
2.1.4


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

[Xen-devel] [PATCH QEMU-XEN v4 6/9] xen: Switch uses of xc_map_foreign_bulk to use libxenforeignmemory API.

In Xen 4.7 we are refactoring parts libxenctrl into a number of
separate libraries which will provide backward and forward API and ABI
compatiblity.

One such library will be libxenforeignmemory which provides access to
privileged foreign mappings and which will provide an interface
equivalent to xc_map_foreign_bulk.

In preparation for adding support for libxenforeignmemory add support
to the <=4.0 and <=4.6 compat code in xen_common.h to allow us to
switch to using the new API. These shims will disappear for versions
of Xen which include libxenforeignmemory.

Since libxenforeignmemory will have its own handle type but for <= 4.6
the functionality is provided by using a libxenctrl handle we
introduce a new global xen_fmem alongside the existing xen_xc. In fact
we make xen_fmem a pointer to the existing xen_xc, which then works
correctly with both <=4.0 (xc handle is an int) and <=4.6 (xc handle
is a pointer). In the latter case xen_fmem is actually a double
indirect pointer, but it all falls out in the wash.

Unlike libxenctrl libxenforeignmemory has an explicit unmap function,
rather than just specifying that munmap should be used, so the unmap
paths are updated to use xenforeignmemory_unmap, which is a shim for
munmap on these versions of xen. The mappings in xen-hvm.c do not
appear to be unmapped (which makes sense for a qemu-dm process)

In fb_disconnect this results in a change from simply mmap over the
existing mapping (with an implciit munmap) to expliclty unmapping with
xenforeignmemory_unmap and then mapping the required anonymous memory
in the same hole. I don't think this is a problem since any other
thread which was racily touching this region would already be running
the risk of hitting the mapping halfway through the call. If this is
thought to be a problem then we could consider adding an extra API to
the libxenforeignmemory interface to replace a foreign mapping with
anonymous shared memory, but I'd prefer not to.

Build tested with 4.0 and 4.5.

Signed-off-by: Ian Campbell 
---
I noticed in xen_console.c that the decision to use a foreign
privileged memory mapping vs a grant dev is made using different
variables in con_initialise vs con_disconnect. The former uses
xendev->dev while the latter uses xendev->gnttabdev. Is this a latent
bug?

v4: Rebase onto "xen_console: correctly cleanup primary console on
teardown."

xenforeignmemory_unmap takes pages not bytes

Compat wrapper for xenforeignmemory_open instead of ifdef in code.

Run check patch and fix most issues. I did not fix:

ERROR: do not initialise globals to 0 or NULL
+xenforeignmemory_handle *xen_fmem = NULL;

=> This is consistent with all of the existing declarations.

ERROR: need consistent spacing around '*' (ctx:WxV)
+typedef xc_interface *xenforeignmemory_handle;

=> I think this is a false +ve since this is a pointer "*" not a multiple "*".
---
 hw/char/xen_console.c|  8 
 hw/display/xenfb.c   | 15 ---
 hw/xen/xen_backend.c |  3 ++-
 include/hw/xen/xen_backend.h |  1 +
 include/hw/xen/xen_common.h  | 12 
 xen-common.c |  6 ++
 xen-hvm.c| 18 +-
 xen-mapcache.c   |  6 +++---
 8 files changed, 45 insertions(+), 24 deletions(-)

diff --git a/hw/char/xen_console.c b/hw/char/xen_console.c
index 11c6472..24f3a40 100644
--- a/hw/char/xen_console.c
+++ b/hw/char/xen_console.c
@@ -230,9 +230,9 @@ static int con_initialise(struct XenDevice *xendev)
 
 if (!xendev->dev) {
 xen_pfn_t mfn = con->ring_ref;
-con->sring = xc_map_foreign_bulk(xen_xc, con->xendev.dom,
- PROT_READ|PROT_WRITE,
- , , 1);
+con->sring = xenforeignmemory_map(xen_fmem, con->xendev.dom,
+  PROT_READ|PROT_WRITE,
+  , , 1);
 } else {
 con->sring = xengnttab_map_grant_ref(xendev->gnttabdev, 
con->xendev.dom,
  con->ring_ref,
@@ -274,7 +274,7 @@ static void con_disconnect(struct XenDevice *xendev)
 
 if (con->sring) {
 if (!xendev->dev) {
-munmap(con->sring, XC_PAGE_SIZE);
+xenforeignmemory_unmap(xen_fmem, con->sring, 1);
 } else {
 xengnttab_munmap(xendev->gnttabdev, con->sring, 1);
 }
diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c
index b0ac1e6..a5ddb60 100644
--- a/hw/display/xenfb.c
+++ b/hw/display/xenfb.c
@@ -103,8 +103,8 @@ static int common_bind(struct common *c)
 if (xenstore_read_fe_int(>xendev, "event-channel", 
>xendev.remote_port) == -1)
return -1;
 
-c->page = xc_map_foreign_bulk(xen_xc, c->xendev.dom,
-  PROT_READ | PROT_WRITE, , , 1);
+c->page = xenforeignmemory_map(xen_fmem, c->xendev.dom,
+

[Xen-devel] [PATCH QEMU-XEN v4 7/9] xen: Use stable library interfaces when they are available.

In Xen 4.7 we are refactoring parts libxenctrl into a number of
separate libraries which will provide backward and forward API and ABI
compatiblity.

Specifically libxenevtchn, libxengnttab and libxenforeignmemory.

Previous patches have already laid the groundwork for using these by
switching the existing compatibility shims to reflect the intefaces to
these libraries.

So all which remains is to update configure to detect the libraries
and enable their use. Although they are notionally independent we take
an all or nothing approach to the three libraries since they were
added at the same time.

The only non-obvious bit is that we now open a proper xenforeignmemory
handle for xen_fmem instead of reusing the xen_xc handle.

Build tested with 4.0, 4.5 and the patches targetting 4.7 which adds
these libraries.

Signed-off-by: Ian Campbell 
---
v4: xenforeignmemory_open is now a compat wrapper, so no ifdef.

Simplify configury by asserting that interface version 470 will
always have the libraries (lack of them makes it 460).

Ran checkpatch and fixed everything except:

ERROR: need consistent spacing around '*' (ctx:WxV)
+typedef xc_interface *XenXC;

Which I think is a false +ve.

simplify configury
---
 configure   | 55 +
 include/hw/xen/xen_common.h | 38 +--
 2 files changed, 91 insertions(+), 2 deletions(-)

diff --git a/configure b/configure
index 779623a..fe0a39d 100755
--- a/configure
+++ b/configure
@@ -1840,6 +1840,7 @@ fi
 
 if test "$xen" != "no" ; then
   xen_libs="-lxenstore -lxenctrl -lxenguest"
+  xen_stable_libs="-lxenforeignmemory -lxengnttab -lxenevtchn"
 
   # First we test whether Xen headers and libraries are available.
   # If no, we are done and there is no Xen support.
@@ -1862,6 +1863,57 @@ EOF
   # Xen unstable
   elif
   cat > $TMPC <
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#if !defined(HVM_MAX_VCPUS)
+# error HVM_MAX_VCPUS not defined
+#endif
+int main(void) {
+  xc_interface *xc;
+  xenforeignmemory_handle *xfmem;
+  xenevtchn_handle *xe;
+  xengnttab_handle *xg;
+
+  xs_daemon_open();
+
+  xc = xc_interface_open(0, 0, 0);
+  xc_hvm_set_mem_type(0, 0, HVMMEM_ram_ro, 0, 0);
+  xc_domain_add_to_physmap(0, 0, XENMAPSPACE_gmfn, 0, 0);
+  xc_hvm_inject_msi(xc, 0, 0xf000, 0x);
+  xc_hvm_create_ioreq_server(xc, 0, HVM_IOREQSRV_BUFIOREQ_ATOMIC, NULL);
+
+  xfmem = xenforeignmemory_open(0, 0);
+  xenforeignmemory_map(xfmem, 0, 0, 0, 0, 0);
+
+  xe = xenevtchn_open(0, 0);
+  xenevtchn_fd(xe);
+
+  xg = xengnttab_open(0, 0);
+  xengnttab_map_grant_ref(xg, 0, 0, 0);
+
+  return 0;
+}
+EOF
+  compile_prog "" "$xen_libs $xen_stable_libs"
+  then
+xen_ctrl_version=470
+xen=yes
+
+  # Xen 4.6
+  elif
+  cat > $TMPC <
 #include 
 #include 
@@ -2037,6 +2089,9 @@ EOF
   fi
 
   if test "$xen" = yes; then
+if test $xen_ctrl_version -ge 470  ; then
+   libs_softmmu="$xen_stable_libs $libs_softmmu"
+fi
 libs_softmmu="$xen_libs $libs_softmmu"
   fi
 fi
diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
index 2a5f27a..38293b4 100644
--- a/include/hw/xen/xen_common.h
+++ b/include/hw/xen/xen_common.h
@@ -6,6 +6,17 @@
 #include 
 #include 
 
+#if CONFIG_XEN_CTRL_INTERFACE_VERSION >= 470
+/*
+ * If we have new enough libxenctrl then we do not want/need these compat
+ * interfaces, despite what the user supplied cflags might say. They
+ * must be undefined before including xenctrl.h
+ */
+#undef XC_WANT_COMPAT_EVTCHN_API
+#undef XC_WANT_COMPAT_GNTTAB_API
+#undef XC_WANT_COMPAT_MAP_FOREIGN_API
+#endif
+
 #include 
 #if CONFIG_XEN_CTRL_INTERFACE_VERSION < 420
 #  include 
@@ -151,8 +162,8 @@ static inline void xs_close(struct xs_handle *xsh)
 }
 
 
-/* Xen 4.1 */
-#else
+/* Xen 4.1 thru 4.6 */
+#elif CONFIG_XEN_CTRL_INTERFACE_VERSION < 470
 
 typedef xc_interface *XenXC;
 typedef xc_interface *xenforeignmemory_handle;
@@ -195,6 +206,29 @@ static inline int xc_fd(xc_interface *xen_xc)
 {
 return -1;
 }
+#else /* CONFIG_XEN_CTRL_INTERFACE_VERSION >= 470 */
+
+typedef xc_interface *XenXC;
+
+#  define XC_INTERFACE_FMT "%p"
+#  define XC_HANDLER_INITIAL_VALUENULL
+
+#include 
+#include 
+#include 
+
+static inline XenXC xen_xc_interface_open(void *logger, void *dombuild_logger,
+  unsigned int open_flags)
+{
+return xc_interface_open(logger, dombuild_logger, open_flags);
+}
+
+/* FIXME There is now way to have the xen fd */
+static inline int xc_fd(xc_interface *xen_xc)
+{
+return -1;
+}
+
 #endif
 
 /* Xen before 4.2 */
-- 
2.1.4


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

[Xen-devel] [PATCH XEN v4 17/23] tools/libs: Clean up hard tabs.

These were wrong in the context of libxc before this code was
extracted, clean them up.

Also add some emacs magic blocks

Signed-off-by: Ian Campbell 
---
 tools/libs/call/buffer.c  |  4 ++--
 tools/libs/call/core.c|  2 +-
 tools/libs/call/minios.c  |  4 ++--
 tools/libs/evtchn/minios.c| 28 ++--
 tools/libs/evtchn/netbsd.c| 12 ++--
 tools/libs/foreignmemory/freebsd.c|  2 +-
 tools/libs/foreignmemory/minios.c |  6 +++---
 tools/libs/foreignmemory/netbsd.c | 12 +++-
 tools/libs/foreignmemory/private.h|  2 +-
 tools/libs/foreignmemory/solaris.c| 13 +++--
 tools/libs/gnttab/include/xengnttab.h |  4 ++--
 tools/libs/gnttab/linux.c |  6 +++---
 tools/libs/toollog/xtl_logger_stdio.c |  2 +-
 13 files changed, 58 insertions(+), 39 deletions(-)

diff --git a/tools/libs/call/buffer.c b/tools/libs/call/buffer.c
index fbbd7ff..da27135 100644
--- a/tools/libs/call/buffer.c
+++ b/tools/libs/call/buffer.c
@@ -20,7 +20,7 @@
 #include "private.h"
 
 #define DBGPRINTF(_m...) \
-   xtl_log(xcall->logger, XTL_DEBUG, -1, "xencall:buffer", _m)
+xtl_log(xcall->logger, XTL_DEBUG, -1, "xencall:buffer", _m)
 
 #define ROUNDUP(_x,_w) (((unsigned long)(_x)+(1UL<<(_w))-1) & ~((1UL<<(_w))-1))
 
@@ -86,7 +86,7 @@ static int cache_free(xencall_handle *xcall, void *p, int 
nr_pages)
 xcall->buffer_current_allocations--;
 
 if ( nr_pages == 1 &&
-xcall->buffer_cache_nr < BUFFER_CACHE_SIZE )
+ xcall->buffer_cache_nr < BUFFER_CACHE_SIZE )
 {
 xcall->buffer_cache[xcall->buffer_cache_nr++] = p;
 rc = 1;
diff --git a/tools/libs/call/core.c b/tools/libs/call/core.c
index 83f8ddb..c570592 100644
--- a/tools/libs/call/core.c
+++ b/tools/libs/call/core.c
@@ -19,7 +19,7 @@
 
 xencall_handle *xencall_open(xentoollog_logger *logger, unsigned open_flags)
 {
-   xencall_handle *xcall = malloc(sizeof(*xcall));
+xencall_handle *xcall = malloc(sizeof(*xcall));
 int rc;
 
 if (!xcall) return NULL;
diff --git a/tools/libs/call/minios.c b/tools/libs/call/minios.c
index 1cdc073..524fa04 100644
--- a/tools/libs/call/minios.c
+++ b/tools/libs/call/minios.c
@@ -50,8 +50,8 @@ int osdep_hypercall(xencall_handle *xcall, 
privcmd_hypercall_t *hypercall)
 ret = HYPERVISOR_multicall(, 1);
 
 if (ret < 0) {
-   errno = -ret;
-   return -1;
+errno = -ret;
+return -1;
 }
 if ((long) call.result < 0) {
 errno = - (long) call.result;
diff --git a/tools/libs/evtchn/minios.c b/tools/libs/evtchn/minios.c
index b839cd0..b4b5f14 100644
--- a/tools/libs/evtchn/minios.c
+++ b/tools/libs/evtchn/minios.c
@@ -103,8 +103,8 @@ int xenevtchn_notify(xenevtchn_handle *xce, evtchn_port_t 
port)
 ret = notify_remote_via_evtchn(port);
 
 if (ret < 0) {
-   errno = -ret;
-   ret = -1;
+errno = -ret;
+ret = -1;
 }
 return ret;
 }
@@ -138,16 +138,16 @@ evtchn_port_or_error_t 
xenevtchn_bind_unbound_port(xenevtchn_handle *xce, int do
 assert(get_current() == main_thread);
 port_info = port_alloc(fd);
 if (port_info == NULL)
-   return -1;
+return -1;
 
 printf("xenevtchn_bind_unbound_port(%d)", domid);
 ret = evtchn_alloc_unbound(domid, evtchn_handler, (void*)(intptr_t)fd, 
);
 printf(" = %d\n", ret);
 
 if (ret < 0) {
-   port_dealloc(port_info);
-   errno = -ret;
-   return -1;
+port_dealloc(port_info);
+errno = -ret;
+return -1;
 }
 port_info->bound = 1;
 port_info->port = port;
@@ -166,16 +166,16 @@ evtchn_port_or_error_t 
xenevtchn_bind_interdomain(xenevtchn_handle *xce, int dom
 assert(get_current() == main_thread);
 port_info = port_alloc(fd);
 if (port_info == NULL)
-   return -1;
+return -1;
 
 printf("xenevtchn_bind_interdomain(%d, %"PRId32")", domid, remote_port);
 ret = evtchn_bind_interdomain(domid, remote_port, evtchn_handler, 
(void*)(intptr_t)fd, _port);
 printf(" = %d\n", ret);
 
 if (ret < 0) {
-   port_dealloc(port_info);
-   errno = -ret;
-   return -1;
+port_dealloc(port_info);
+errno = -ret;
+return -1;
 }
 port_info->bound = 1;
 port_info->port = local_port;
@@ -208,15 +208,15 @@ evtchn_port_or_error_t 
xenevtchn_bind_virq(xenevtchn_handle *xce, unsigned int v
 assert(get_current() == main_thread);
 port_info = port_alloc(fd);
 if (port_info == NULL)
-   return -1;
+return -1;
 
 printf("xenevtchn_bind_virq(%d)", virq);
 port = bind_virq(virq, evtchn_handler, (void*)(intptr_t)fd);
 
 if (port < 0) {
-   port_dealloc(port_info);
-   errno = -port;
-   return -1;
+port_dealloc(port_info);
+errno = -port;
+return -1;
 }
 port_info->bound = 1;
 port_info->port = port;
diff --git

[Xen-devel] [PATCH XEN v4 23/23] HACK: Update Config.mk to pull all the right bits from my xenbits trees

v4: Config.mk instead of .config
---
 Config.mk | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/Config.mk b/Config.mk
index 114db9a..a72b671 100644
--- a/Config.mk
+++ b/Config.mk
@@ -242,20 +242,20 @@ endif
 
 ifeq ($(GIT_HTTP),y)
 OVMF_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/ovmf.git
-QEMU_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/qemu-xen.git
-QEMU_TRADITIONAL_URL ?= 
http://xenbits.xen.org/git-http/qemu-xen-traditional.git
+QEMU_UPSTREAM_URL ?= 
http://xenbits.xen.org/git-http/people/ianc/libxenctrl-split/qemu-xen.git
+QEMU_TRADITIONAL_URL ?= 
http://xenbits.xen.org/git-http/people/ianc/libxenctrl-split/qemu-xen-traditional.git
 SEABIOS_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/seabios.git
-MINIOS_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/mini-os.git
+MINIOS_UPSTREAM_URL ?= 
http://xenbits.xen.org/git-http/people/ianc/libxenctrl-split/mini-os.git
 else
 OVMF_UPSTREAM_URL ?= git://xenbits.xen.org/ovmf.git
-QEMU_UPSTREAM_URL ?= git://xenbits.xen.org/qemu-xen.git
-QEMU_TRADITIONAL_URL ?= git://xenbits.xen.org/qemu-xen-traditional.git
+QEMU_UPSTREAM_URL ?= 
git://xenbits.xen.org/people/ianc/libxenctrl-split/qemu-xen.git
+QEMU_TRADITIONAL_URL ?= 
git://xenbits.xen.org/people/ianc/libxenctrl-split/qemu-xen-traditional.git
 SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git
-MINIOS_UPSTREAM_URL ?= git://xenbits.xen.org/mini-os.git
+MINIOS_UPSTREAM_URL ?= 
git://xenbits.xen.org/people/ianc/libxenctrl-split/mini-os.git
 endif
 OVMF_UPSTREAM_REVISION ?= cb9a7ebabcd6b8a49dc0854b2f9592d732b5afbd
-QEMU_UPSTREAM_REVISION ?= master
-MINIOS_UPSTREAM_REVISION ?= 256035e01a1aa5739e34f245f3b1e9e8ee204210
+QEMU_UPSTREAM_REVISION ?= origin/v4
+MINIOS_UPSTREAM_REVISION ?= origin/v4
 # Thu Jul 23 11:08:38 2015 +0100
 # arm: interrupt controller
 
@@ -266,7 +266,7 @@ SEABIOS_UPSTREAM_REVISION ?= rel-1.8.2
 ETHERBOOT_NICS ?= rtl8139 8086100e
 
 
-QEMU_TRADITIONAL_REVISION ?= bc00cad75d8bcc3ba696992bec219c21db8406aa
+QEMU_TRADITIONAL_REVISION ?= origin/v4
 # Tue Mar 11 10:19:23 2014 +
 # block-vvfat: fix resource leaks in read_directory()
 
-- 
2.1.4


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

[Xen-devel] [PATCH XEN v4 20/23] tools/libs/call: Avoid xc_memalign in netbsd and solaris backends

These are already arch specific, so just use the appropriate
interfaces (as determined by looking at the xc_memalign backend).

Signed-off-by: Ian Campbell 
---
 tools/libs/call/netbsd.c  | 4 ++--
 tools/libs/call/solaris.c | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/libs/call/netbsd.c b/tools/libs/call/netbsd.c
index 12008fb..c01d3de 100644
--- a/tools/libs/call/netbsd.c
+++ b/tools/libs/call/netbsd.c
@@ -74,8 +74,8 @@ void *osdep_alloc_hypercall_buffer(xencall_handle *xcall, 
unsigned int npages)
 size_t size = npages * XC_PAGE_SIZE;
 void *p;
 
-p = xc_memalign(xcall, XC_PAGE_SIZE, size);
-if (!p)
+ret = posix_memalign(, XC_PAGE_SIZE, size);
+if ( ret != 0 || !p )
 return NULL;
 
 if ( mlock(p, size) < 0 )
diff --git a/tools/libs/call/solaris.c b/tools/libs/call/solaris.c
index 972989d..8d9c9da 100644
--- a/tools/libs/call/solaris.c
+++ b/tools/libs/call/solaris.c
@@ -71,7 +71,7 @@ int osdep_xencall_close(xencall_handle *xcall)
 
 void *osdep_alloc_hypercall_buffer(xencall_handle *xcall, unsigned int npages)
 {
-return xc_memalign(xcall, XC_PAGE_SIZE, npages * XC_PAGE_SIZE);
+return memalign(XC_PAGE_SIZE, npages * XC_PAGE_SIZE);
 }
 
 void osdep_free_hypercall_buffer(xencall_handle *xcall, void *ptr,
-- 
2.1.4


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

[Xen-devel] [PATCH XEN v4 14/23] tools: foreignmemory: provide xenforeignmemory_unmap.

And require it be used instead of direct munmap.

This will allow e.g. Valgrind hooks to help track incorrect use of
foreign mappings.

Switch all uses of xenforeignmemory_map to use
xenforeignmemory_unmap, not that foreign mappings via the libxc compat
xc_map_foreign_* interface will not take advantage of this and will
need converting.

Signed-off-by: Ian Campbell 
---
v4: xenforeignmemory_unmap takes pages not bytes, adjust callers.
---
 tools/libs/foreignmemory/freebsd.c  | 6 ++
 tools/libs/foreignmemory/include/xenforeignmemory.h | 7 +--
 tools/libs/foreignmemory/libxenforeignmemory.map| 1 +
 tools/libs/foreignmemory/linux.c| 6 ++
 tools/libs/foreignmemory/minios.c   | 6 ++
 tools/libs/foreignmemory/netbsd.c   | 6 ++
 tools/libs/foreignmemory/solaris.c  | 6 ++
 tools/libxc/xc_sr_restore.c | 2 +-
 tools/libxc/xc_sr_save.c| 2 +-
 tools/libxc/xc_vm_event.c   | 2 +-
 10 files changed, 39 insertions(+), 5 deletions(-)

diff --git a/tools/libs/foreignmemory/freebsd.c 
b/tools/libs/foreignmemory/freebsd.c
index a7e0f6b..f9e74fa 100644
--- a/tools/libs/foreignmemory/freebsd.c
+++ b/tools/libs/foreignmemory/freebsd.c
@@ -118,6 +118,12 @@ void *xenforeignmemory_map(xenforeignmemory_handle *fmem,
 return addr;
 }
 
+int xenforeignmemory_unmap(xenforeignmemory_handle *fmem,
+   void *addr, unsigned int num)
+{
+   return munmap(addr, num << PAGE_SHIFT);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libs/foreignmemory/include/xenforeignmemory.h 
b/tools/libs/foreignmemory/include/xenforeignmemory.h
index 0909585..1bcdf6a 100644
--- a/tools/libs/foreignmemory/include/xenforeignmemory.h
+++ b/tools/libs/foreignmemory/include/xenforeignmemory.h
@@ -44,8 +44,8 @@ int xenforeignmemory_close(xenforeignmemory_handle *xmem);
 
 /*
  * Maps a range within one domain to a local address range.  Mappings
- * should be unmapped with munmap and should follow the same rules as mmap
- * regarding page alignment.
+ * must be unmapped with xenforeignmemory_unmap and should follow the
+ * same rules as mmap regarding page alignment.
  *
  * prot is as for mmap(2).
  *
@@ -58,6 +58,9 @@ void *xenforeignmemory_map(xenforeignmemory_handle *fmem, 
uint32_t dom,
int prot, const xen_pfn_t *arr, int *err,
unsigned int num);
 
+int xenforeignmemory_unmap(xenforeignmemory_handle *fmem,
+   void *addr, unsigned int num);
+
 #endif
 
 /*
diff --git a/tools/libs/foreignmemory/libxenforeignmemory.map 
b/tools/libs/foreignmemory/libxenforeignmemory.map
index 11f0d2b..df206b3 100644
--- a/tools/libs/foreignmemory/libxenforeignmemory.map
+++ b/tools/libs/foreignmemory/libxenforeignmemory.map
@@ -3,5 +3,6 @@ VERS_1.0 {
xenforeignmemory_open;
xenforeignmemory_close;
xenforeignmemory_map;
+   xenforeignmemory_unmap;
local: *; /* Do not expose anything by default */
 };
diff --git a/tools/libs/foreignmemory/linux.c b/tools/libs/foreignmemory/linux.c
index 01cd42e..86a5a97 100644
--- a/tools/libs/foreignmemory/linux.c
+++ b/tools/libs/foreignmemory/linux.c
@@ -276,6 +276,12 @@ void *xenforeignmemory_map(xenforeignmemory_handle *fmem,
 return addr;
 }
 
+int xenforeignmemory_unmap(xenforeignmemory_handle *fmem,
+   void *addr, unsigned int num)
+{
+return munmap(addr, (unsigned long)num << PAGE_SHIFT);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libs/foreignmemory/minios.c 
b/tools/libs/foreignmemory/minios.c
index 981d801..dbb152f 100644
--- a/tools/libs/foreignmemory/minios.c
+++ b/tools/libs/foreignmemory/minios.c
@@ -51,6 +51,12 @@ void *xenforeignmemory_map(xenforeignmemory_handle *fmem,
 return map_frames_ex(arr, num, 1, 0, 1, dom, err, pt_prot);
 }
 
+int xenforeignmemory_unmap(xenforeignmemory_handle *fmem,
+   void *addr, unsigned int num)
+{
+   return munmap(addr, num << PAGE_SHIFT);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libs/foreignmemory/netbsd.c 
b/tools/libs/foreignmemory/netbsd.c
index e84d5ec..4d68b52 100644
--- a/tools/libs/foreignmemory/netbsd.c
+++ b/tools/libs/foreignmemory/netbsd.c
@@ -93,3 +93,9 @@ void *compat_mapforeign_batch(xenforeignmem_handle *fmem, 
uint32_t dom,
 return addr;
 
 }
+
+int xenforeignmemory_unmap(xenforeignmemory_handle *fmem,
+   void *addr, unsigned int num)
+{
+   return munmap(addr, num*XC_PAGE_SIZE);
+}
diff --git a/tools/libs/foreignmemory/solaris.c 
b/tools/libs/foreignmemory/solaris.c
index 1d27b50..3f8e705 100644
--- a/tools/libs/foreignmemory/solaris.c
+++ b/tools/libs/foreignmemory/solaris.c
@@ -92,3 +92,9 @@ void *compat_mapforeign_batch(xenforeignmem_handle *fmem,

[Xen-devel] [PATCH XEN v4 21/23] tools/libs/foreignmemory: Mention restrictions on fork in docs.

Signed-off-by: Ian Campbell 
---
 tools/libs/foreignmemory/include/xenforeignmemory.h | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/tools/libs/foreignmemory/include/xenforeignmemory.h 
b/tools/libs/foreignmemory/include/xenforeignmemory.h
index 99ec883..3f52417 100644
--- a/tools/libs/foreignmemory/include/xenforeignmemory.h
+++ b/tools/libs/foreignmemory/include/xenforeignmemory.h
@@ -32,7 +32,12 @@ typedef struct xentoollog_logger xentoollog_logger;
 typedef struct xenforeignmemory_handle xenforeignmemory_handle;
 
 /*
- * Return a handle onto the hypercall driver.  Logs errors.
+ * Return a handle onto the foreign memory mapping driver.  Logs errors.
+ *
+ * Note: After fork a child process must not use any opened handle
+ * inherited from their parent. Any existing mappings should be
+ * assumed to become invalid. Therefore children must open a new
+ * handle and make new mappings if necessary.
  */
 xenforeignmemory_handle *xenforeignmemory_open(xentoollog_logger *logger,
unsigned open_flags);
-- 
2.1.4


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

[Xen-devel] [PATCH QEMU-XEN-TRADITIONAL v4 1/5] qemu-xen-traditional: Use xentoollog as a separate library

This has been split out of libxenctrl, so the build needs to be able
to find the header and the library. QEMU does not use xtl_* itself so
-rpath-link is sufficient to allow linking to libxenctrl.so (which
links against libxentoollog).

Signed-off-by: Ian Campbell 
Acked-by: Ian Jackson 

---
v3: Library moved to tools/libs/
---
 xen-hooks.mak | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/xen-hooks.mak b/xen-hooks.mak
index bc7f1f1..bf7f027 100644
--- a/xen-hooks.mak
+++ b/xen-hooks.mak
@@ -1,3 +1,4 @@
+CPPFLAGS+= -I$(XEN_ROOT)/tools/libs/toollog/include
 CPPFLAGS+= -I$(XEN_ROOT)/tools/libxc/include
 CPPFLAGS+= -I$(XEN_ROOT)/tools/xenstore/include
 CPPFLAGS+= -I$(XEN_ROOT)/tools/include
@@ -19,6 +20,7 @@ CFLAGS += $(CMDLINE_CFLAGS)
 
 LIBS += -L$(XEN_ROOT)/tools/libxc -lxenctrl -lxenguest
 LIBS += -L$(XEN_ROOT)/tools/xenstore -lxenstore
+LIBS += -Wl,-rpath-link=$(XEN_ROOT)/tools/libs/toollog
 
 LDFLAGS := $(CFLAGS) $(LDFLAGS)
 
-- 
2.1.4


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

[Xen-devel] [PATCH XEN v4 02/23] tools: Refactor "xentoollog" into its own library

In attempting to disaggregate libxenctrl I found that many of the
pieces were going to want access to this library, so split it out (as
it probably should always have been).

Various build adjustments are needed. In particular things which use
xtl_* themselves now need to explicity link against the library.

This has a nice side effect which is that users of libxl no longer
need to link against libxenctrl just to create a logger, which was
counter to the principal that applications using libxl shouldn't be
required to look behind the curtain. This means that xl no longer
links against libxenctrl.

The new library uses a version script to ensure that only expected
symbols are exported and to version them such that ABI guarantees can
be kept in the future.

Signed-off-by: Ian Campbell 
Acked-by: Ian Jackson 
---
Must be applied with:

- "qemu-xen-traditional: Use xentoollog as a separate library" and a
  corresponding QEMU_TAG update folded here.
- "mini-os: Include libxentoollog with libxc" and a corresponding bump
  to MINIOS_UPSTREAM_REVISION folded in here.

v2: Update doc at same time
v3: Move into tools/libs/toollog.
---
 .gitignore |  1 +
 stubdom/Makefile   | 24 -
 stubdom/grub/Makefile  |  1 +
 tools/Makefile |  3 ++
 tools/Rules.mk | 14 +++--
 tools/libs/Makefile|  7 +++
 tools/libs/toollog/Makefile| 59 ++
 tools/{libxc => libs/toollog}/include/xentoollog.h |  0
 tools/libs/toollog/libxentoollog.map   | 12 +
 tools/{libxc => libs/toollog}/xtl_core.c   |  0
 tools/{libxc => libs/toollog}/xtl_logger_stdio.c   |  0
 tools/libxc/Makefile   |  7 ++-
 tools/libxl/Makefile   | 15 +++---
 tools/ocaml/Makefile.rules | 26 +-
 tools/ocaml/libs/xentoollog/Makefile   |  6 +--
 tools/ocaml/libs/xentoollog/genlevels.py   |  2 +-
 tools/python/setup.py  |  5 +-
 tools/xenpaging/Makefile   |  2 +-
 18 files changed, 148 insertions(+), 36 deletions(-)
 create mode 100644 tools/libs/Makefile
 create mode 100644 tools/libs/toollog/Makefile
 rename tools/{libxc => libs/toollog}/include/xentoollog.h (100%)
 create mode 100644 tools/libs/toollog/libxentoollog.map
 rename tools/{libxc => libs/toollog}/xtl_core.c (100%)
 rename tools/{libxc => libs/toollog}/xtl_logger_stdio.c (100%)

diff --git a/.gitignore b/.gitignore
index 91e1430..a2c85e1 100644
--- a/.gitignore
+++ b/.gitignore
@@ -58,6 +58,7 @@ stubdom/gcc-*
 stubdom/include
 stubdom/ioemu
 stubdom/xenstore
+stubdom/libxentoollog-*
 stubdom/libxc-*
 stubdom/lwip-*
 stubdom/mini-os-*
diff --git a/stubdom/Makefile b/stubdom/Makefile
index e1359cf..9c923dd 100644
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -313,6 +313,11 @@ mk-headers-$(XEN_TARGET_ARCH): $(IOEMU_LINKFARM_TARGET)
  ln -sf $(wildcard $(XEN_ROOT)/tools/include/xen-foreign/*) 
include/xen-foreign/ && \
  $(MAKE) DESTDIR= -C include/xen-foreign/ && \
  ( [ -h include/xen/foreign ] || ln -sf ../xen-foreign 
include/xen/foreign )
+   mkdir -p libs-$(XEN_TARGET_ARCH)/toollog
+   [ -h libs-$(XEN_TARGET_ARCH)/toollog/Makefile ] || ( cd 
libs-$(XEN_TARGET_ARCH)/toollog && \
+ ln -sf $(XEN_ROOT)/tools/libs/toollog/include/*.h . && \
+ ln -sf $(XEN_ROOT)/tools/libs/toollog/*.c . && \
+ ln -sf $(XEN_ROOT)/tools/libs/toollog/Makefile . )
mkdir -p libxc-$(XEN_TARGET_ARCH)
[ -h libxc-$(XEN_TARGET_ARCH)/Makefile ] || ( cd 
libxc-$(XEN_TARGET_ARCH) && \
  ln -sf $(XEN_ROOT)/tools/libxc/*.h . && \
@@ -336,12 +341,23 @@ $(TARGETS_MINIOS): mini-os-%:
done
 
 ###
+# libxentoollog
+###
+
+.PHONY: libxentoollog
+libxentoollog: libs-$(XEN_TARGET_ARCH)/toollog/libxentoollog.a
+libs-$(XEN_TARGET_ARCH)/toollog/libxentoollog.a: $(NEWLIB_STAMPFILE)
+   $(MAKE) -C $(XEN_ROOT)/tools/include
+   $(MAKE) DESTDIR= -C $(MINI_OS) links
+   CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(MAKE) 
DESTDIR= -C libs-$(XEN_TARGET_ARCH)/toollog
+
+###
 # libxc
 ###
 
 .PHONY: libxc
 libxc: libxc-$(XEN_TARGET_ARCH)/libxenctrl.a 
libxc-$(XEN_TARGET_ARCH)/libxenguest.a
-libxc-$(XEN_TARGET_ARCH)/libxenctrl.a: cross-zlib
+libxc-$(XEN_TARGET_ARCH)/libxenctrl.a: libxentoollog cross-zlib
$(MAKE) -C $(XEN_ROOT)/tools/include
$(MAKE) DESTDIR= -C $(MINI_OS) links
CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(MAKE) 
DESTDIR= CONFIG_LIBXC_MINIOS=y -C libxc-$(XEN_TARGET_ARCH)
@@ -515,6 +531,11 @@ clean:
$(MAKE) -C vtpmmgr clean
rm -fr grub-$(XEN_TARGET_ARCH)
rm -f $(STUBDOMPATH)
+   [ !

[Xen-devel] [PATCH XEN v4 18/23] tools/libs/gnttab: Review and update doc comments.

Remove some stray xc references.

While I'm not convinced by javadoc/doxygen cause the existing comments
which appear to use that syntax to have the appropriate /** marker.

Also fix a typo in a code comment.

Signed-off-by: Ian Campbell 
---
 tools/libs/gnttab/include/xengnttab.h | 21 +++--
 tools/libs/gnttab/linux.c |  2 +-
 2 files changed, 12 insertions(+), 11 deletions(-)

diff --git a/tools/libs/gnttab/include/xengnttab.h 
b/tools/libs/gnttab/include/xengnttab.h
index c810c07..e091fa6 100644
--- a/tools/libs/gnttab/include/xengnttab.h
+++ b/tools/libs/gnttab/include/xengnttab.h
@@ -38,9 +38,9 @@ typedef struct xengntdev_handle xengnttab_handle;
 
 /*
  * Note:
- * After fork a child process must not use any opened xc gnttab
+ * After fork a child process must not use any opened gnttab
  * handle inherited from their parent. They must open a new handle if
- * they want to interact with xc.
+ * they want to interact with gnttab.
  *
  * Return an fd onto the grant table driver.  Logs errors.
  */
@@ -52,7 +52,7 @@ xengnttab_handle *xengnttab_open(xentoollog_logger *logger, 
unsigned open_flags)
  */
 int xengnttab_close(xengnttab_handle *xgt);
 
-/*
+/**
  * Memory maps a grant reference from one domain to a local address range.
  * Mappings should be unmapped with xengnttab_munmap.  Logs errors.
  *
@@ -124,7 +124,7 @@ void *xengnttab_map_grant_ref_notify(xengnttab_handle *xgt,
  uint32_t notify_offset,
  evtchn_port_t notify_port);
 
-/*
+/**
  * Unmaps the @count pages starting at @start_address, which were mapped by a
  * call to xengnttab_map_grant_ref or xengnttab_map_grant_refs. Never logs.
  */
@@ -132,7 +132,7 @@ int xengnttab_munmap(xengnttab_handle *xgt,
  void *start_address,
  uint32_t count);
 
-/*
+/**
  * Sets the maximum number of grants that may be mapped by the given instance
  * to @count.  Never logs.
  *
@@ -156,9 +156,9 @@ typedef struct xengntdev_handle xengntshr_handle;
  * Return an fd onto the grant sharing driver.  Logs errors.
  *
  * Note:
- * After fork a child process must not use any opened xc gntshr
+ * After fork a child process must not use any opened gntshr
  * handle inherited from their parent. They must open a new handle if
- * they want to interact with xc.
+ * they want to interact with gntshr.
  *
  */
 xengntshr_handle *xengntshr_open(xentoollog_logger *logger,
@@ -170,7 +170,7 @@ xengntshr_handle *xengntshr_open(xentoollog_logger *logger,
  */
 int xengntshr_close(xengntshr_handle *xgs);
 
-/*
+/**
  * Creates and shares pages with another domain.
  *
  * @parm xgs a handle to an open grant sharing instance
@@ -183,7 +183,7 @@ int xengntshr_close(xengntshr_handle *xgs);
 void *xengntshr_share_pages(xengntshr_handle *xgs, uint32_t domid,
 int count, uint32_t *refs, int writable);
 
-/*
+/**
  * Creates and shares a page with another domain, with unmap notification.
  *
  * @parm xgs a handle to an open grant sharing instance
@@ -199,7 +199,8 @@ void *xengntshr_share_page_notify(xengntshr_handle *xgs, 
uint32_t domid,
   uint32_t *ref, int writable,
   uint32_t notify_offset,
   evtchn_port_t notify_port);
-/*
+
+/**
  * Unmaps the @count pages starting at @start_address, which were mapped by a
  * call to xengntshr_share_*. Never logs.
  */
diff --git a/tools/libs/gnttab/linux.c b/tools/libs/gnttab/linux.c
index a76f17f..bdf2a42 100644
--- a/tools/libs/gnttab/linux.c
+++ b/tools/libs/gnttab/linux.c
@@ -136,7 +136,7 @@ void *osdep_gnttab_grant_map(xengnttab_handle *xgt,
  * swapped out. Since the paging daemon may be in the same domain, the
  * hypercall cannot block without causing a deadlock.
  *
- * Because there are no notificaitons when the page is swapped in, wait
+ * Because there are no notifications when the page is swapped in, wait
  * a bit before retrying, and hope that the page will arrive 
eventually.
  */
 usleep(1000);
-- 
2.1.4


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

[Xen-devel] Changing the voting model, Was: Survey Results - Part 3 : Improving Xen Project Governance and Conventions

On Fri, 16 Oct 2015, Lars Kurth wrote:
>  * Blocking Votes
>
>We had several cases, where a voter wanted to express disagreement with a
>proposal, but did not want to block a vote. I wanted to suggest an
>approach that we used very successfully in Event Program Management
>Committees.
>
>It is based on splitting -1 into
> -1 : disagree, but don’t care enough to argue against it
> -2 : disagree, but feel strongly enough to argue against it
>and +1 into
> +1: agree, but don’t care enough to argue for it
> +2: agree, but care strongly enough to argue for it
>
>Note that the -2, ... +2 is merely a shorthand and is not intended for
>counting and could be replaced by some other shorthand.
>
> Q3.2: Do you think such a proposal makes sense and is workable?
>
> | 11 / 12 Agree
> | 0 / 12 Disagree
> | 1 / 12 Don't know or have no opinion

[...]

> ! = Summary =
> !
> ! There seems to be a clear consensus against the current veto model. From
> ! the comments there was no clear case for a simple majority, but for a higher
> ! bar of consensus (2/3, 75% or <20% objections) depending on the size
> ! of the group.
> !
> ! So I suppose again, I will let this run for a bit and then get some
> ! feedback to be incorporated into a proposal.

This seems to be a good place to start to make changes based on the
results from the survey.

Everybody seems to agree on changing the voting model from consensus to
some kind of majority vote among committers. I agree with Lars: we
should gather a few proposals then call a vote to see which one is the
best for us.

I think we should avoid counting abstentions and blank votes, only
positive and negative votes by committers count, and go with a simple
majority.

What do you think?___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [linux-4.1 baseline-only test] 38187: regressions - trouble: blocked/fail/pass/preparing/running

2015-10-21 Thread Platform Team regression test user

This run is configured for baseline tests only.

flight 38187 linux-4.1 running [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38187/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-xsm   5 xen-build fail REGR. vs. 38058
 test-amd64-i386-xl-qemuu-win7-amd64  2 hosts-allocate   running
 test-amd64-amd64-xl-qemut-win7-amd64 12 guest-saverestorerunning
 test-amd64-amd64-libvirt-xsm  2 hosts-allocate   running
 test-amd64-amd64-xl-qemuu-winxpsp3  9 windows-install  running
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop   running
 test-amd64-i386-qemut-rhel6hvm-amd  5 xen-install  running
 test-amd64-i386-xl-xsm2 hosts-allocate   running
 test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeatrunning
 test-armhf-armhf-xl-multivcpu  2 hosts-allocate   running
 test-amd64-i386-freebsd10-amd64 19 guest-start.2running
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  2 hosts-allocate running
 test-armhf-armhf-xl   2 hosts-allocate   running
 test-armhf-armhf-xl-credit2   2 hosts-allocate   running
 test-amd64-i386-xl-qemuu-ovmf-amd64  2 hosts-allocate   running
 test-amd64-amd64-xl-rtds 21 guest-start/debian.repeatrunning
 test-amd64-i386-qemuu-rhel6hvm-intel  3 host-install(3)  running
 test-amd64-i386-xl-qemut-debianhvm-amd64  9 debian-hvm-install running
 test-amd64-i386-qemuu-rhel6hvm-amd  2 hosts-allocate   running
 test-armhf-armhf-libvirt-raw  2 hosts-allocate   running
 test-armhf-armhf-xl-midway2 hosts-allocate   running
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 19 
guest-start/debianhvm.repeat running
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  2 hosts-allocate running
 test-amd64-i386-xl-qemut-winxpsp3  2 hosts-allocate   running
 test-amd64-i386-freebsd10-i386  2 hosts-allocate   running
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 16 guest-localmigrate/x10 running
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  2 hosts-allocate running
 test-amd64-i386-xl-qemut-win7-amd64  2 hosts-allocate   running
 test-amd64-i386-xl-qemuu-winxpsp3  2 hosts-allocate   running
 test-armhf-armhf-libvirt-qcow2  2 hosts-allocate   running
 test-armhf-armhf-libvirt  2 hosts-allocate   running
 test-amd64-i386-xl2 hosts-allocate   running
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  2 hosts-allocate running
 test-armhf-armhf-xl-vhd   2 hosts-allocate   running
 test-armhf-armhf-xl-rtds  2 hosts-allocate   running
 test-amd64-i386-qemut-rhel6hvm-intel  2 hosts-allocate   running
 test-amd64-i386-xl-qemuu-debianhvm-amd64  2 hosts-allocate running
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm  2 hosts-allocate running
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm   running
 test-amd64-i386-xl-raw2 hosts-allocate   running

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-rumpuserxen-amd64 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail like 38058

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass

version targeted for testing:
 linux27f1b7fed9c305ef46f8708f1bdde9cdb5f166bd
baseline version:
 linux36311a9ec4904c080bbdfcefc0f3d609ed508224

Last test of basis38058  2015-09-25 17:07:25 Z   25 days
Testing same since0  1970-01-01 00:00:00 Z 16729 days0 attempts


People who touched revisions under test:
  "Eric W. Biederman" 
  Aaron Brown 
  Adam Lee 
  Adrien Schildknecht 
  Alex Deucher 
  Alexander Drozdov 
  Alexander Duyck

[Xen-devel] [qemu-upstream-unstable baseline-only test] 38189: regressions - trouble: blocked/fail/pass/preparing/queued/running

2015-10-21 Thread Platform Team regression test user

This run is configured for baseline tests only.

flight 38189 qemu-upstream-unstable running [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38189/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   5 xen-build fail REGR. vs. 37993
 build-i386-xsm5 xen-build fail REGR. vs. 37993
 build-amd64-xsm   5 xen-build fail REGR. vs. 37993
 build-i3865 xen-build fail REGR. vs. 37993
 test-armhf-armhf-xl-rtds  queued
 test-armhf-armhf-xl-vhd   queued
 test-armhf-armhf-xl-multivcpu  queued
 test-armhf-armhf-libvirt-xsm  queued
 test-armhf-armhf-xl-xsm   queued
 test-armhf-armhf-libvirt  queued
 test-armhf-armhf-libvirt-qcow2  queued
 test-armhf-armhf-xl-midwayqueued
 build-armhf-libvirt   queued
 test-armhf-armhf-xl-credit2   queued
 test-armhf-armhf-xl   queued
 test-armhf-armhf-libvirt-raw  queued
 build-armhf-xsm   2 hosts-allocate   running
 build-armhf   5 xen-buildrunning
 build-armhf-pvops 2 hosts-allocate   running

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

version targeted for testing:
 qemuu816609b2841297925a223ec377c336360e044ee5
baseline version:
 qemuu8ad9e71fc937439730fa68e82d6da11a50eb5c04

Last test of basis37993  2015-09-20 01:57:57 Z   31 days
Testing same since0

[Xen-devel] [xen-4.5-testing baseline-only test] 38190: regressions - trouble: blocked/fail/pass/preparing/queued

2015-10-21 Thread Platform Team regression test user

This run is configured for baseline tests only.

flight 38190 xen-4.5-testing running [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38190/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf   5 xen-build fail REGR. vs. 38155
 build-i386-rumpuserxenqueued
 build-i386-libvirtqueued
 build-amd64-rumpuserxen   queued
 test-amd64-amd64-xl-pvh-amd   queued
 test-amd64-amd64-xl-pvh-intel  queued
 build-amd64-libvirt   queued
 test-amd64-amd64-xl-credit2   queued
 test-amd64-amd64-xl-rtds  queued
 test-amd64-i386-migrupgrade   queued
 test-amd64-amd64-libvirt  queued
 test-amd64-i386-pair  queued
 test-amd64-i386-libvirt-pair  queued
 test-amd64-amd64-xl   queued
 test-amd64-amd64-rumpuserxen-amd64  queued
 test-amd64-i386-qemut-rhel6hvm-intel  queued
 test-amd64-i386-rumpuserxen-i386  queued
 test-amd64-amd64-xl-multivcpu  queued
 test-amd64-i386-libvirt   queued
 test-amd64-amd64-xl-qcow2 queued
 test-amd64-amd64-xl-qemuu-debianhvm-amd64queued
 test-amd64-i386-qemuu-rhel6hvm-intel  queued
 test-amd64-i386-qemut-rhel6hvm-amd  queued
 test-amd64-amd64-i386-pvgrub  queued
 test-amd64-i386-qemuu-rhel6hvm-amd  queued
 test-amd64-amd64-pygrub   queued
 test-amd64-i386-xl-qemuu-ovmf-amd64  queued
 test-amd64-i386-xlqueued
 test-amd64-amd64-pair queued
 test-amd64-amd64-libvirt-pair  queued
 test-amd64-amd64-migrupgrade  queued
 test-amd64-amd64-libvirt-vhd  queued
 test-amd64-i386-freebsd10-amd64  queued
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 queued
 test-amd64-i386-xl-rawqueued
 test-amd64-i386-xl-qemut-debianhvm-amd64 queued
 test-amd64-amd64-xl-qemuu-win7-amd64  queued
 test-amd64-amd64-xl-qemuu-ovmf-amd64  queued
 test-amd64-i386-freebsd10-i386  queued
 test-amd64-i386-xl-qemuu-debianhvm-amd64 queued
 test-amd64-i386-xl-qemuu-win7-amd64  queued
 test-amd64-amd64-xl-qemut-win7-amd64  queued
 test-amd64-i386-xl-qemut-winxpsp3  queued
 test-amd64-amd64-amd64-pvgrub  queued
 test-amd64-i386-xl-qemut-win7-amd64  queued
 test-amd64-i386-xl-qemuu-winxpsp3  queued
 test-amd64-amd64-xl-qemut-debianhvm-amd64queued
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 queued
 test-amd64-amd64-xl-qemuu-winxpsp3  queued
 test-amd64-amd64-xl-qemut-winxpsp3  queued
 build-i386-pvops  2 hosts-allocate   running
 build-i386-prev   2 hosts-allocate   running
 build-amd64-pvops 2 hosts-allocate   running
 build-amd64   2 hosts-allocate   running
 build-i3862 hosts-allocate   running
 build-amd64-prev  2 hosts-allocate   running

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-midway1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a

version targeted for testing:
 xen  80e9f5624f9d1ef2e7bbd9b9b185e96b45e1bb17
baseline version:
 xen  db0f474646878b0e91fd14f53eec6adcacc4b5ba

Last test of basis38155  2015-10-11 21:34:32 Z9 days
Testing same since0  1970-01-01 00:00:00 Z 16729 days0 attempts


People who touched revisions under test:
  Anthony PERARD 
  George Dunlap 
  Ian Campbell 
  Wei Liu 

jobs:
 build-amd64

[Xen-devel] [xen-4.3-testing test] 63115: regressions - trouble: blocked/fail/pass/preparing/queued

flight 63115 xen-4.3-testing running [real]
http://logs.test-lab.xenproject.org/osstest/logs/63115/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i3865 xen-build fail REGR. vs. 62742
 build-amd64   5 xen-build fail REGR. vs. 62742
 test-amd64-amd64-rumpuserxen-amd64  queued
 test-amd64-amd64-xl-qemuu-ovmf-amd64  queued
 build-armhf-libvirt   queued
 test-amd64-amd64-pv   queued
 test-amd64-amd64-migrupgrade  queued
 test-amd64-amd64-xl   queued
 test-amd64-amd64-xl-multivcpu  queued
 test-amd64-amd64-pair queued
 test-amd64-i386-migrupgrade   queued
 test-armhf-armhf-xl   queued
 test-armhf-armhf-xl-arndale   queued
 test-armhf-armhf-libvirt-qcow2  queued
 test-armhf-armhf-xl-vhd   queued
 test-amd64-amd64-xl-credit2   queued
 test-armhf-armhf-libvirt  queued
 test-amd64-amd64-libvirt  queued
 test-amd64-amd64-pygrub   queued
 test-amd64-amd64-i386-pvgrub  queued
 test-amd64-amd64-xl-qemuu-debianhvm-amd64queued
 test-amd64-amd64-amd64-pvgrub  queued
 test-armhf-armhf-libvirt-raw  queued
 test-armhf-armhf-xl-multivcpu  queued
 test-armhf-armhf-xl-cubietruck  queued
 test-armhf-armhf-xl-credit2   queued
 test-amd64-amd64-xl-qemut-debianhvm-amd64queued
 test-amd64-amd64-libvirt-vhd  queued
 test-amd64-amd64-xl-qcow2 queued
 test-amd64-amd64-xl-qemuu-win7-amd64  queued
 test-amd64-amd64-xl-qemut-win7-amd64  queued
 test-amd64-amd64-xl-qemuu-winxpsp3  queued
 test-amd64-amd64-xl-qemut-winxpsp3  queued
 build-amd64-prev  2 hosts-allocate   running
 build-amd64-pvops 2 hosts-allocate   running
 build-armhf   2 hosts-allocate   running
 build-armhf-pvops 2 hosts-allocate   running

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 build-amd64-rumpuserxen   1 build-check(1)   blocked  n/a
 build-i386-rumpuserxen1 build-check(1)   blocked  n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-xend-qemut-winxpsp3  1 build-check(1)  blocked n/a

version targeted for testing:
 xen  8c5d8c049dad890965124ae4e169e274a693c8fa
baseline version:
 xen  998424e33db121270690586320e899a03c88b4aa

Last test of basis62742  2015-10-09 07:58:29 Z   12 days
Testing same since63098  2015-10-20 17:42:44 Z0 days1 attempts


People who touched revisions under test:
  Anthony PERARD 
  George Dunlap 
  Ian Campbell 
  Ian Jackson 
  Wei Liu 

jobs:
 build-amd64

[Xen-devel] Killed osstest flights (Was: Re: [ANNOUNCE] Switching to qemu-xen.git and qemu-xen-traditional.git)

On Wed, 2015-10-21 at 14:16 +0100, Ian Campbell wrote:
> I have just completed the switch to use a single qemu tree for each of the
> versions we support (qemu-xen AKA upstream and qemu-xen-traditional AKA our
> historical fork).

Some flights which were active during the transition have been killed since
their build phase failed. I should have stopped everything and not just the
qemu flights, sorry.

The affected flights are 63102 63107 63113 and 63115 from the main colo
instance.

Also 38187, 38189 and 38190 from the Cambridge instance.

Sorry for the noise.

Ian.

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

Re: [Xen-devel] [V7 1/4] x86/xsaves: add basic definitions/helpers to support xsaves

2015-10-21 Thread Shuai Ruan

On Tue, Oct 20, 2015 at 02:26:46PM +0100, Andrew Cooper wrote:
> On 20/10/15 09:21, Shuai Ruan wrote:
> > This patch add basic definitions/helpers which will be used in
> > later patches.
> >
> *this_xss = xss;
> 
> Using this_cpu() multiple times cannot be optimised by compiler (because
> of the underlying definition), which is why the optimisation is
> performed manually by pulling the value out as a pointer.
> 
Ok. I will fix this in next version.
> ~Andrew
> 

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

Re: [Xen-devel] [ANNOUNCE] Switching to qemu-xen.git and qemu-xen-traditional.git

On Wed, 2015-10-21 at 16:52 +0100, Ian Campbell wrote:
> On Wed, 2015-10-21 at 17:26 +0200, Olaf Hering wrote:
> > On Wed, Oct 21, Ian Campbell wrote:
> > 
> > > http://xenbits.xen.org/gitweb/?p=qemu-xen.git
> > 
> > Is the HEAD warning expected?
> 
> No it is not.

Apparently it actually is, it's a short coming of the git:// protocol that
the client only sees the sha which HEAD points to and has to reverse
engineer which branch it was, which is ambiguous if there are two such
branches (as there is in this repo right now).

Ian J found this which explains things a bit better:

http://stackoverflow.com/questions/13061364/why-git-remote-show-name-display-remote-head-is-ambiguous-may-be-one-of-the

> 
> Both trees contain a file HEAD containing:
> ref: refs/heads/master
> which is the same as xen.git does.

> I see the same thing as you for the qemu-xen tree, but not for xen.git.

In xen.git staging and master happen to differ right now, so we don't see
this there.

> I shall consult around and see if I can figure out what I'm supposed to do
> here.

a) Nothing, sorry.

Maybe one day a) will be "update git on xenbits", I don't intend to even
investigate that right now, for hopefully obvious reasons...

Ian.

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

Re: [Xen-devel] Wiki for automatic reports / fixes

2015-10-21 Thread Luis R. Rodriguez

On Mon, Oct 12, 2015 at 12:55 PM, Luis R. Rodriguez
 wrote:
> On Mon, Oct 5, 2015 at 10:03 AM, Luis R. Rodriguez
>  wrote:
>> On Mon, Oct 5, 2015 at 9:56 AM, Ian Jackson  
>> wrote:
>>> Luis R. Rodriguez writes ("Wiki for automatic reports / fixes"):
>>> [...]
  While discussing expectations and information about
 reports over these with Valentin it occurred to me information about
 all these may be scattered separately and some developers may be
 surprised when they first get reports / fixes from these sorts of
 testing systems and that perhaps it may be useful if we had a single
 wiki entry point where we could refer folks to the different ongoing
 testing infrastructures out there working upstream.

 If we could piggy back off of an already existing wiki then great, but
 if not I was thinking something off of wiki.kernel.org might be good.
 How about tests.wiki.kernel.org ? If such projects don't have a wiki
 they could perhaps use pages off of tests.wiki.kernel.org to elaborate
 and set expectations straight. Thoughts?
>>>
>>> To clarify what I think you are suggesting, is to create a new wiki or
>>> wiki page which gives information about automatic tests that are
>>> performed on upstream (or going-upstream) Linux branches ?
>>
>> That's right, as it stands we have a slew of folks doing a series of
>> battery of tests on either linux-next or other branches, and
>> developers / maintainers get e-mails about this. Typically one becomes
>> aware of these tests through experience and in dealing with reports
>> but other times one may not even be aware of ongoing effort on this
>> front, such was the case of Valentin's dead code analysis with
>> undertaker. Knowing what existing work is being done can and could be
>> used can also save people from re-inventing the wheel, but also and
>> most importantly collaborate.
>>
>>> I think this is a good idea.  I'm not sure how much information we
>>> need for each tester, but a page for each would be about right.
>>
>> Sure, I figure if each tester framework has its own dedicated page we
>> can at least refer to it, but a basic page which describes general
>> coverage / mailing lists / contact info / and what to expect might be
>> useful. As it stands most of this is just tribal knowledge.
>
> OK I'll poke and see if we can get this created.

OK we have a page up now to help track and document (if no
documentation exists) or refer to existing testing efforts for Linux:

https://bottest.wiki.kernel.org/

I went ahead and provided references for those projects that I was
aware of that had a page, otherwise I added some boiler plate
documentation page for them with some initial documentation I just
wrote. Please feel free to use this for your own documentation of your
test suite or refer to your own project if you have one from the top
level page.

 Luis

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

Re: [Xen-devel] Dom0 kernel for Xen4.6 on R-Car H2 (LAGER)

2015-10-21 Thread Ferger, Max

Hi!

Thanks for both DT fixes, the "add ranges;", and the "complete memory map".

Here are some findings:

* Linus' most recent version of the kernel [1] (configured with a mix of 
Xen/OMAP description [2] and lager_defconfig [3]) needs the 'add 
"ranges;"'-fixes, but does not access the otherwise unmapped address regions.
* Renesas' Yocto/Poky 

Unfortunately, neither gives any message on the console, so I don't know their 
status.

[1] git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
[2] 
http://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/OMAP5432_uEVM
[3] git clone https://github.com/renesas-devel/lager-config

As I see it, Xen issues no further warnings, but still Dom0 remains silent.

I'm somewhat at a loss.  :-(

Greetings from Germany!

Max Ferger

Latest log with both above fixes, applied by the appended DTS:
- 8< -

LAGER SPI_LOADER V0.28 2014.09.29
DEVICE S25FL512


U-Boot 2014.10-00441-gf7ca1f7-dirty (Oct 19 2015 - 12:32:17)

CPU: Renesas Electronics R8A7790 rev 2.0
Board: Lager
I2C:   ready
DRAM:  2 GiB
SF: Detected S25FL512S_256K with page size 512 Bytes, erase size 256 KiB, total 
64 MiB
In:serial
Out:   serial
Err:   serial
Net:   sh_eth
Hit any key to stop autoboot:  0
sh_eth Waiting for PHY auto negotiation to complete... done
sh_eth: 100Base/Half
Using sh_eth device
TFTP from server 192.168.0.15; our IP address is 192.168.0.5
Filename 'r8a7790-lager-xen.dtb'.
Load address: 0x70f0
Loading: #
 439.5 KiB/s
done
Bytes transferred = 44589 (ae2d hex)
sh_eth:1 is connected to sh_eth.  Reconnecting to sh_eth
sh_eth Waiting for PHY auto negotiation to complete... done
sh_eth: 100Base/Half
Using sh_eth device
TFTP from server 192.168.0.15; our IP address is 192.168.0.5
Filename 'dom0-zImage'.
Load address: 0x7200
Loading: #
 #
 #
 ##
 710 KiB/s
done
Bytes transferred = 1273096 (136d08 hex)
sh_eth:1 is connected to sh_eth.  Reconnecting to sh_eth
sh_eth Waiting for PHY auto negotiation to complete done
sh_eth: 100Base/Half
Using sh_eth device
TFTP from server 192.168.0.15; our IP address is 192.168.0.5
Filename 'xenpolicy'.
Load address: 0x7400
Loading: ##
 321.3 KiB/s
done
Bytes transferred = 9561 (2559 hex)
sh_eth:1 is connected to sh_eth.  Reconnecting to sh_eth
sh_eth Waiting for PHY auto negotiation to complete... done
sh_eth: 100Base/Half
Using sh_eth device
TFTP from server 192.168.0.15; our IP address is 192.168.0.5
Filename 'xen-uImage'.
Load address: 0x70007fc0
Loading: #
 #
 #
 697.3 KiB/s
done
Bytes transferred = 852948 (d03d4 hex)
## Booting kernel from Legacy Image at 70007fc0 ...
   Image Name:   XEN4.6-LAGER
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:852884 Bytes = 832.9 KiB
   Load Address: 9000
   Entry Point:  9000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 70f0
   Booting using the fdt blob at 0x70f0
   Loading Kernel Image ... OK
   reserving fdt memory region: addr=70f0 size=b000
   Loading Device Tree to 407f2000, end 407f ... OK

Starting kernel ...

- UART enabled -
- CPU  booting -
- Xen starting in Hyp mode -
- Zero BSS -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) Checking for initrd in /chosen
(XEN) RAM: 4000 - 7fff
(XEN) RAM: 00014000 - 0001
(XEN)
(XEN) MODULE[0]: 407f2000 - 407fd000 Device Tree
(XEN) MODULE[1]: 7200 - 72136d08 Kernel
(XEN) MODULE[2]: 7400 - 74002559 XSM
(XEN)  RESVD[0]: 70f0 - 70f0b000
(XEN)  RESVD[1]: 7ff9a000 - 7ff9a120
(XEN)  RESVD[2]: 407f2000 - 407fd000
(XEN)
(XEN) Command line: console=dtuart dom0_mem=1G
(XEN) Placing Xen at 0x7fc0-0x7fe0
(XEN) Update BOOTMOD_XEN from 9000-9011b701 => 
7fc0-7fd1b701
(XEN) Xen heap: 0001f800-0002 (32768 pages)
(XEN) Dom heap: 1015808 pages
(XEN) Domain heap initialised
(XEN) Platform: Renesas R-Car Gen2
(XEN) Taking dtuart configuration from /chosen/stdout-path
(XEN) Looking for dtuart at "/serial@e6c4", options ""
(XEN) Unable to initialize dtuart: -9
(XEN) Bad console= option 'dtuart'
 __  ___  ______
 \ \/ /___ _ __   | || |  / /_  / _ \
  \  // _ \ '_ \  | || |_| '_ \| | | |
  /  \  __/ | | | |__   _| (_) | |_| |
 /_/\_\___|_| |_||_|(_)___(_)___/

(XEN) Xen version 4.6.0 (aen@)

Re: [Xen-devel] [Minios-devel] [PATCH v4 0/] Begin to disentangle libxenctrl and provide some stable libraries

(Trimming CCs a bit)

On Wed, 2015-10-21 at 16:22 +0100, Ian Campbell wrote:
> 
[...]
> Still to come would be libraries for specific out of tree purposes
> (device model, kexec), which would be adding new library at the same
> level as libxc I think, rather than underneath, i.e. also using the
> libraries split out here, but hopefully not libxenctrl itself.

Next steps for qemu-xen, with reference to:

http://xenbits.xen.org/people/ianc/libxenctrl-split/v4.html#by-functional-area

First the two simple cases:

The PV backend support now only (I think) uses got from these new libraries.

The PV domain builder is now configured off by default, I don't intend to
make this
use a stable API so when enabling this qemu will then be linked against the
unstable
libxen{guest,ctrl} libraries.

Now the more complex cases.

The actual DM functionality looks in reasonably good shape, from the
pandoc
source to the above (the "S" columns represent whether the column to the
left is a stable interface or not):

Interface  S Underlying Interface   S Other 
users
-- - -- - 
---
`xenevtchn_bind_interdomain`   Y
`xenevtchn_close`  Y
`xenevtchn_fd` Y
`xenevtchn_notify` Y
`xenevtchn_open`   Y
`xenevtchn_pending`Y
`xenevtchn_unmask` Y
`xenforeignmemory_map` Y
`xenforeignmemory_open`Y
`xenforeignmemory_unmap`   Y
`xc_domain_add_to_physmap` N `XENMEM_add_to_physmap`Y libxc 
(dombuilder)
`xc_domain_populate_physmap_exact` N `XENMEM_populate_physmap`  Y libxc 
(several)
`xc_domain_pin_memory_cacheattr`   N `XEN_DOMCTL_pin_mem_cacheattr` N None
`xc_domain_shutdown`   N `SCHEDOP_remote_shutdown`  Y libxl
`xc_set_hvm_param` N `HVM_PARAM_ACPI_S_STATE`   Y None
`xc_hvm_inject_msi`N `HVMOP_inject_msi` Y None
`xc_hvm_modified_memory`   N `HVMOP_modified_memory`Y None
`xc_hvm_set_isa_irq_level` N `HVMOP_set_isa_irq_level`  Y None
`xc_hvm_set_mem_type`  N `HVMOP_set_mem_type`   Y None
`xc_hvm_set_pci_intx_level`N `HVMOP_set_pci_intx_level` Y None
`xc_hvm_set_pci_link_route`N `HVMOP_set_pci_link_route` Y None
`xc_hvm_track_dirty_vram`  N `HVMOP_track_dirty_vram`   Y None
`xc_hvm_unmap_io_range_from_ir...` N `HVMOP_IO_RANGE_(PORT|MEM...)` Y None
`xc_hvm_unmap_pcidev_from_iore...` N `HVMOP_unmap_io_range_from...` Y None

I think it would be reasonable to add a new library (say, libxendevicemodel, 
for arguments sake) with a stable ABI and to move all of the xc_hvm_* above 
into it. They are not used for anything else and are based on HVMOP which is a 
stable interface (AFAIK).

Within qemu xc_domain_add_to_physmap and xc_domain_pin_memory_cacheattr are
used in tandem solely to populate VRAM with WB memory and to remove again.

xc_domain_populate_physmap_exact is used only to populate RAM and
xc_domain_shutdown is used on shutdown.

I think having three or four functions in libxendevicemodel which offer
these exact facilities while retaining the underlying (possibly more
flexible) functionality in libxenctrl for other users (dombuilder, other in
tree tools) would be tolerable.

Three or four functions depends on whether the uses of
xc_domain_add_to_physmap+xc_domain_pin_memory_cacheattr and
xc_domain_populate_physmap_exact can be satisfied with a single API or not.
I don't know that yet.

The main question would then be whether libxendevicemodel should wrap
libxenctrl in a stable layer or whether it should actually duplicate the
functionality in the thin wrappers.

Wrapping libxenctrl would mean that libxendevicemodel would need to be
built by all releases with a fixed ABI such that the corresponding one
(linking against the correct libxenctrl) can be flipped into place on boot.
I think that is going to be too tricky for distros and users a like and
that the small amount of duplication is therefore more tolerable.

The only blocker for that is that xc_domain_pin_memory_cacheattr is
XEN_DOMCTL_pin_mem_cacheattr (i.e. not stable), but this route would either
require it to move to a stable hypercall interface or for the library to
DTRT for all versions. I think moving to a stable h/call interface is more
feasible.

In terms of deprivileging QEMU (one of the end goals of this work) I think
all the xen* libraries could very easily gain a xen???_set_target_domain
which would make an appropriate ioctl to lock the underlying fd into
operating only on that domain (another argument in finding a way to do
pin_mem_cacheattr as a stable API). This would require support from all the
underlying drivers, but could be added right away with errno=ENOTTY +
return -1 and then plumbed in later. Obviously qemu would need to check the
return values.

The PCI

Re: [Xen-devel] [linux-4.1 test] 63030: regressions - FAIL

On Tue, 2015-10-20 at 16:34 +0100, Ian Jackson wrote:
> Wei Liu writes ("Re: [Xen-devel] [linux-4.1 test] 63030: regressions 
> - FAIL"):
> > From mere code inspection and document of lwip 1.3.0 I think mini
> -os
> > does send gratuitous ARP.
> 
> The guest is using the PVHVM drivers at this point, with the backend
> directly in dom0, so it is the guest's gratuitous arp which is needed,
> I think.

It would be worth investigating whether mini-os's gratuitous ARP might
also be occurring and confusing things, e.g. by coming after and
therefore taking precedence over the one coming from the guest.

Ian.

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

Re: [Xen-devel] Dom0 kernel for Xen4.6 on R-Car H2 (LAGER)

2015-10-21 Thread Julien Grall

On 21/10/15 17:05, Ferger, Max wrote:
> Hi!

Hello,

> Thanks for both DT fixes, the "add ranges;", and the "complete memory map".
> 
> Here are some findings:
> 
> * Linus' most recent version of the kernel [1] (configured with a mix of 
> Xen/OMAP description [2] and lager_defconfig [3]) needs the 'add 
> "ranges;"'-fixes, but does not access the otherwise unmapped address regions.
> * Renesas' Yocto/Poky 
> 
> Unfortunately, neither gives any message on the console, so I don't know 
> their status.
> 
> [1] git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> [2] 
> http://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/OMAP5432_uEVM
> [3] git clone https://github.com/renesas-devel/lager-config
> 
> As I see it, Xen issues no further warnings, but still Dom0 remains silent.

The console parameter in "xen,dom0-bootargs" seems to be wrong.
It should be console=hvc0

If it still doesn't work, you can apply the patch [1] to Linux
(it's based on the latest version). It will print everything on Xen
console even if the HVC console is not ready.

> I'm somewhat at a loss.  :-(
> 
> Greetings from Germany!

Regards,


[1]
diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
index fa816b7..b57ace0 100644
--- a/drivers/tty/hvc/hvc_xen.c
+++ b/drivers/tty/hvc/hvc_xen.c
@@ -638,7 +638,7 @@ void xen_raw_console_write(const char *str)
ssize_t len = strlen(str);
int rc = 0;
 
-   if (xen_domain()) {
+   if (1 || xen_domain()) {
rc = dom0_write_console(0, str, len);
 #ifdef CONFIG_X86
if (rc == -ENOSYS && xen_hvm_domain())
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 8f0324e..29a19af 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -1652,6 +1652,8 @@ static size_t cont_print_text(char *text, size_t size)
return textlen;
 }
 
+#include 
+
 asmlinkage int vprintk_emit(int facility, int level,
const char *dict, size_t dictlen,
const char *fmt, va_list args)
@@ -1719,6 +1721,7 @@ asmlinkage int vprintk_emit(int facility, int level,
 * prefix which might be passed-in as a parameter.
 */
text_len = vscnprintf(text, sizeof(textbuf), fmt, args);
+   xen_raw_console_write(text);
 
/* mark and strip a trailing newline */
if (text_len && text[text_len-1] == '\n') {




-- 
Julien Grall

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

[Xen-devel] More benchmarks with flatten topology in the Linux kernel

2015-10-21 Thread Dario Faggioli

Hi everyone,

I managed running again the benchmarks I had already showed off here:

[PATCH RFC] xen: if on Xen, "flatten" the scheduling domain hierarchy
https://lkml.org/lkml/2015/8/18/302

Basically, this is about Linux guests using topology information for
scheduling, while they just don't make any sense when on Xen as (unless
static and guest-lifetime long pinning is used) vCPUs do move around!

Some more context is also available here:

http://lists.xen.org/archives/html/xen-devel/2015-07/msg03241.html

This email is still about numbers obtained by running things in Dom0,
and without overloading the host pCPUs at the Xen level (i.e., I'm
using nr. dom0 vCPUs == nr. host pCPUs).

With respect to previous round:
- I've added results for hackbench
- I've run the benches with both my patch[0] and Juergen's patch[1].
My patch is 'dariof', in the spreadsheet; Juergen's is 'jgross'.

Here are the numbers:

https://docs.google.com/spreadsheets/d/17djcVV3FkmHmv1FKFBe9CQFnNgVumnM2U64MNvjzAn8/edit?usp=sharing

(If anyone has issues with googledocs, tell me, and I'll try
cutting-&-pasting in email, as I did the other time.)

A few comments:
* both the patches bring performance improvements. The only
regression seems to happen in hackbench, when running with -g1.
That is certainly not the typical use case of the benchmark, but we
certainly can try figuring out better what happens in that case;
* the two patches were supposed to provide almost identical results,
and they actually do that, in most cases (e.g., all the instances
of Unixbench);
* when there are differences, it is hard to see a trend, or, in
general, to identify a possible reason by looking at differences
between the patches themselves, at least as far as these data are
concerned. In fact, in the "make xen" case, for instance, 'jgross'
is better when building with -j20 and -j24, while 'dariof' is
better when building with -j48 and -j62 (the host having 48 pCPUs).
In the hackbench case, 'dariof' is better in the least concurrent
case, 'jgross' is better in the other three.
This all may well be due to some different and independent
factor... Perhaps, a little bit more of investigation is necessary
(and I'm up for it).

IMO, future steps are:
a) running benchmarks in a guest
b) running benchmarks in more guests, and when overloading at the Xen
level (i.e., having more vCPUs around than the host has pCPUs)
c) tracing and/or collecting stats (e.g., from perf and xenalyze)

I'm already working on a) and b).

As far as which approach (mine or Juergen's) to adopt, I'm not sure,
and it does not seem to make much difference, at least from the
performance point of view. I don't have any particular issues with
Juergen's patch, apart from the fact that I'm not yet sure how it makes
the scheduling domains creation code behave. I can look into that and
report.

Also, this is all for PV guests. Any thoughts on what the best route
would be for HVM ones?

[0] http://pastebin.com/KF5WyPKz
[1] http://pastebin.com/xSFLbLwn

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

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

Re: [Xen-devel] [ANNOUNCE] Switching to qemu-xen.git and qemu-xen-traditional.git

On Wed, 2015-10-21 at 17:26 +0200, Olaf Hering wrote:
> On Wed, Oct 21, Ian Campbell wrote:
> 
> > http://xenbits.xen.org/gitweb/?p=qemu-xen.git
> 
> Is the HEAD warning expected?

No it is not.

Both trees contain a file HEAD containing:
ref: refs/heads/master
which is the same as xen.git does.

I see the same thing as you for the qemu-xen tree, but not for xen.git. I'm
not sure what I'm supposed to do about this.

Strangely I don't see this on my http based clone of qemu-xen.git (this is
not a solution though!).

I shall consult around and see if I can figure out what I'm supposed to do
here.

Ian.

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

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

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-winxpsp3 15 guest-localmigrate.2 fail REGR. vs. 62811

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 62811
 test-armhf-armhf-xl-multivcpu 16 guest-start/debian.repeatfail  like 62811

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
 build-amd64-rumpuserxen   6 xen-buildfail   never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 build-i386-rumpuserxen6 xen-buildfail   never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 11 guest-start  fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 21 leak-check/checkfail never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass

version targeted for testing:
 xen  e321898a39222ad1feef352d65f71cef362b4a16
baseline version:
 xen  5c94f9630bf735f19df51c61817cfc6a3aebc994

Last test of basis62811  2015-10-11 03:23:52 Z   10 days
Testing same since63097  2015-10-20 17:43:00 Z0 days1 attempts


People who touched revisions under test:
  Anthony PERARD 
  George Dunlap 
  Ian Campbell 
  Ian Jackson 
  Wei Liu 

jobs:
 build-amd64-xend pass
 build-i386-xend  pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  fail
 build-i386-rumpuserxen   fail
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64pass
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64

Re: [Xen-devel] [edk2] [PATCH v2] OvmfPkg: XenPvBlkDxe: handle empty cdrom drives

On Wed, 21 Oct 2015, Fabio Fantoni wrote:
> Il 21/10/2015 14:45, Laszlo Ersek ha scritto:
> > On 10/21/15 13:39, Stefano Stabellini wrote:
> > > Empty cdroms are not going to connect, avoid waiting for the backend to
> > > switch to state 4, which is never going to happen, and return
> > > error instead from XenPvBlockFrontInitialization(). Detect an
> > > empty cdrom by looking at the "params" node on xenstore, which is set to
> > > "" or "aio:" for empty drives by libxl.
> > > 
> > > Contributed-under: TianoCore Contribution Agreement 1.0
> > > Signed-off-by: Stefano Stabellini 
> > > 
> > > ---
> > > Changes in v2:
> > > - better commit message
> > > - return EFI_DEVICE_ERROR instead of EFI_NO_MEDIA
> > > - check the return status of XenBusIo->XsBackendRead
> > > ---
> > >   OvmfPkg/XenPvBlkDxe/BlockFront.c |   15 +++
> > >   1 file changed, 15 insertions(+)
> > > 
> > > diff --git a/OvmfPkg/XenPvBlkDxe/BlockFront.c
> > > b/OvmfPkg/XenPvBlkDxe/BlockFront.c
> > > index 256ac55..d07e980 100644
> > > --- a/OvmfPkg/XenPvBlkDxe/BlockFront.c
> > > +++ b/OvmfPkg/XenPvBlkDxe/BlockFront.c
> > > @@ -169,6 +169,7 @@ XenPvBlockFrontInitialization (
> > > XEN_BLOCK_FRONT_DEVICE *Dev;
> > > XenbusState State;
> > > UINT64 Value;
> > > +  CHAR8 *Params;
> > >   ASSERT (NodeName != NULL);
> > >   @@ -186,6 +187,20 @@ XenPvBlockFrontInitialization (
> > > }
> > > FreePool (DeviceType);
> > >   +  if (Dev->MediaInfo.CdRom) {
> > > +Status = XenBusIo->XsBackendRead (XenBusIo, XST_NIL, "params",
> > > (VOID**));
> > > +if (Status != XENSTORE_STATUS_SUCCESS) {
> > > +  DEBUG ((EFI_D_ERROR, "%a: Failed to read params (%d)\n",
> > > __FUNCTION__, Status));
> > > +  goto Error;
> > > +}
> > > +if (AsciiStrLen (Params) == 0 || AsciiStrCmp (Params, "aio:") == 0) {
> > > +  FreePool (Params);
> > > +  DEBUG ((EFI_D_INFO, "%a: Empty cdrom\n", __FUNCTION__));
> > > +  goto Error;
> > > +}
> > > +FreePool (Params);
> > > +  }
> > > +
> > > Status = XenBusReadUint64 (XenBusIo, "backend-id", FALSE, );
> > > if (Status != XENSTORE_STATUS_SUCCESS || Value > MAX_UINT16) {
> > >   DEBUG ((EFI_D_ERROR, "XenPvBlk: Failed to get backend-id (%d)\n",
> > > 
> > Reviewed-by: Laszlo Ersek 
> > 
> > I test-built this for X64 and Ia32, and then committed it to SVN as rev
> > 18651.
> > 
> > Thanks!
> > Laszlo
> 
> Thanks to both.
> I tested it with a git cherry-pick on my tested build of some days ago.
> With ide disks it boots correctly and xl cd-insert and xl cd-eject are
> working.
> With pvdisk don't start, but this time instead freeze on "tianocore logo" but
> freeze with black screen after initial windows boot.
> I retried for take full logs as possibile but it booted correctly and with xl
> cd-insert and xl cd-eject was working.
> I retried other 2 reboot without problem but at the third windows freeze after
> arrived to login screen.
> I suppose that this patch is ok and the problem is another but I not
> understand exactly what.
> 
> In attachment full qemu log and xl dmesg about the latest test where windows
> freezed at login screen, rdp and xl shutdown was not working, its qemu process
> was still active and with near 100% cpu usage.
> If you need more informations/tests tell me and I'll post them.

Yes, that's likely a completely different bug. Does it only happen using
OVMF as guest firmare? I am saying this because it looks like the guest
PV drivers were loaded at the time of the freeze.

In any case it might be good to repost it as a separate bug report to xen-devel.

Thanks again for testing,

Stefano

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

[Xen-devel] [PATCH QEMU-XEN-TRADITIONAL v4 4/5] qemu-xen-traditional: Add libxencall to rpath-link

libxenctrl links against this library

Signed-off-by: Ian Campbell 
---
v3: Library moved to tools/libs
---
 xen-hooks.mak | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen-hooks.mak b/xen-hooks.mak
index 179a6b7..229d642 100644
--- a/xen-hooks.mak
+++ b/xen-hooks.mak
@@ -25,6 +25,7 @@ LIBS += -L$(XEN_ROOT)/tools/libs/gnttab -lxengnttab
 LIBS += -L$(XEN_ROOT)/tools/libxc -lxenctrl -lxenguest
 LIBS += -L$(XEN_ROOT)/tools/xenstore -lxenstore
 LIBS += -Wl,-rpath-link=$(XEN_ROOT)/tools/libs/toollog
+LIBS += -Wl,-rpath-link=$(XEN_ROOT)/tools/libs/call
 
 LDFLAGS := $(CFLAGS) $(LDFLAGS)
 
-- 
2.1.4


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

Re: [Xen-devel] [PATCH v4 1/3] xen/arm: Enable cpu_hotplug.c

On Wed, 21 Oct 2015, Boris Ostrovsky wrote:
> On 10/21/2015 09:00 AM, Stefano Stabellini wrote:
> > > 
> > > diff --git a/arch/x86/include/asm/xen/hypervisor.h
> > > b/arch/x86/include/asm/xen/hypervisor.h
> > > index d866959..8b2d4be 100644
> > > --- a/arch/x86/include/asm/xen/hypervisor.h
> > > +++ b/arch/x86/include/asm/xen/hypervisor.h
> > > @@ -57,4 +57,9 @@ static inline bool xen_x2apic_para_available(void)
> > >   }
> > >   #endif
> > >   +#ifdef CONFIG_HOTPLUG_CPU
> > > +void xen_arch_register_cpu(int num);
> > > +void xen_arch_unregister_cpu(int num);
> > > +#endif
> 
> Why not inline them here, just like you did for ARM?

I don't think is good practice to define static inline functions under
arch/something, then use them under drivers/something_else. It is
tolerable if the static inline functions are empty and the driver in
question cannot be compiled as module, like in this case for the arm.

In addition the x86 implementation calls arch_(un)register_cpu, which
requires #include , which doesn't compile if added to
arch/x86/include/asm/xen/hypervisor.h.

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

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

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

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  e08f3834c2f375153f104c827dd7c2fea93b288e
baseline version:
 xen  5a3ce8f85e7e7bdd339d259daa19f6bc5cb4735f

Last test of basis63112  2015-10-21 09:03:50 Z0 days
Testing same since63137  2015-10-21 14:01:05 Z0 days1 attempts


People who touched revisions under test:
  Ian Campbell 
  Ian Jackson 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 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=e08f3834c2f375153f104c827dd7c2fea93b288e
+ . ./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 
e08f3834c2f375153f104c827dd7c2fea93b288e
+ branch=xen-unstable-smoke
+ revision=e08f3834c2f375153f104c827dd7c2fea93b288e
+ . ./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-unstable
+ : 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

Re: [Xen-devel] [PATCH] tools/xenpaging: install directory with default permission

On Wed, Oct 21, 2015 at 02:46:54PM +0100, Ian Campbell wrote:
> On Wed, 2015-10-21 at 13:10 +0100, Wei Liu wrote:
> > There is no need to explicitly ask for 700.
> 
> Is the rationale for 0700 explicitly not that the files in here will
> contain possibly sensitive date from guest memory?
> 
> i.e. the use of something other than the default is deliberate.
> 

You're right. Please ignore this patch.

Wei.

> If you think that is wrong then I think the changelog should explain why.
> 
> 
> > Signed-off-by: Wei Liu 
> > ---
> >  tools/xenpaging/Makefile | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/tools/xenpaging/Makefile b/tools/xenpaging/Makefile
> > index 2407a30..4badaae 100644
> > --- a/tools/xenpaging/Makefile
> > +++ b/tools/xenpaging/Makefile
> > @@ -24,7 +24,7 @@ xenpaging: $(OBJS)
> > $(CC) $(LDFLAGS) -o $@ $^ $(LDLIBS) $(APPEND_LDFLAGS)
> >  
> >  install: all
> > -   $(INSTALL_DIR) -m 0700 $(DESTDIR)$(XEN_PAGING_DIR)
> > +   $(INSTALL_DIR) $(DESTDIR)$(XEN_PAGING_DIR)
> > $(INSTALL_DIR) $(DESTDIR)$(LIBEXEC_BIN)
> > $(INSTALL_PROG) $(IBINS) $(DESTDIR)$(LIBEXEC_BIN)
> >  

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

[Xen-devel] [PATCH XEN v4 11/23] tools: Remove xc_map_foreign_batch

It can trivially be replaced by xc_map_foreign_bulk which is the
interface I want to move to going forward. All in tree users are
trivially converted by supplying the appropriate error array and
adjusting the what error handling exists (which in many cases is not
much).

This reduces the twist maze of xc_map_foreign_* by one, which will be
useful when trying to come up with an underlying stable interface.

NetBSD and Solaris implemented xc_map_foreign_bulk in terms of
xc_map_foreign_batch via a compat layer, so xc_map_foreign_batch
becomes an internal osdep for them. New OS ports should always
implement xc_map_foreign_bulk instead.

Signed-off-by: Ian Campbell 
Acked-by: George Dunlap 
Cc: George Dunlap 
---
 tools/libxc/include/xenctrl.h   | 10 ---
 tools/libxc/xc_foreign_memory.c |  4 ++-
 tools/libxc/xc_linux_osdep.c| 59 +++--
 tools/libxc/xc_minios.c | 22 ---
 tools/libxc/xc_netbsd.c | 10 +++
 tools/libxc/xc_solaris.c|  6 ++---
 tools/libxc/xc_vm_event.c   | 25 -
 tools/xenmon/xenbaked.c | 19 ++---
 tools/xenpaging/pagein.c|  4 ++-
 tools/xenpaging/xenpaging.c | 12 +
 tools/xentrace/xentrace.c   | 10 ---
 11 files changed, 63 insertions(+), 118 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 0c6b36b..44d0496 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1395,16 +1395,6 @@ void *xc_map_foreign_pages(xc_interface *xch, uint32_t 
dom, int prot,
const xen_pfn_t *arr, int num );
 
 /**
- * DEPRECATED - use xc_map_foreign_bulk() instead.
- *
- * Like xc_map_foreign_pages(), except it can succeeed partially.
- * When a page cannot be mapped, its PFN in @arr is or'ed with
- * 0xF000 to indicate the error.
- */
-void *xc_map_foreign_batch(xc_interface *xch, uint32_t dom, int prot,
-   xen_pfn_t *arr, int num );
-
-/**
  * Like xc_map_foreign_pages(), except it can succeed partially.
  * When a page cannot be mapped, its respective field in @err is
  * set to the corresponding errno value.
diff --git a/tools/libxc/xc_foreign_memory.c b/tools/libxc/xc_foreign_memory.c
index b205bca..2413e75 100644
--- a/tools/libxc/xc_foreign_memory.c
+++ b/tools/libxc/xc_foreign_memory.c
@@ -55,6 +55,8 @@ void *xc_map_foreign_pages(xc_interface *xch, uint32_t dom, 
int prot,
  * just implement xc_map_foreign_bulk.
  */
 #if defined(__NetBSD__) || defined(__sun__)
+void *osdep_map_foreign_batch(xc_interface *xch, uint32_t dom, int prot,
+  xen_pfn_t *arr, int num );
 void *xc_map_foreign_bulk(xc_interface *xch,
   uint32_t dom, int prot,
   const xen_pfn_t *arr, int *err, unsigned int num)
@@ -75,7 +77,7 @@ void *xc_map_foreign_bulk(xc_interface *xch,
 }
 
 memcpy(pfn, arr, num * sizeof(*arr));
-ret = xc_map_foreign_batch(xch, dom, prot, pfn, num);
+ret = osdep_map_foreign_batch(xch, dom, prot, pfn, num);
 
 if (ret) {
 for (i = 0; i < num; ++i)
diff --git a/tools/libxc/xc_linux_osdep.c b/tools/libxc/xc_linux_osdep.c
index 7f27966..1404790 100644
--- a/tools/libxc/xc_linux_osdep.c
+++ b/tools/libxc/xc_linux_osdep.c
@@ -85,8 +85,8 @@ int osdep_privcmd_close(xc_interface *xch)
 return close(fd);
 }
 
-static int xc_map_foreign_batch_single(int fd, uint32_t dom,
-   xen_pfn_t *mfn, unsigned long addr)
+static int map_foreign_batch_single(int fd, uint32_t dom,
+xen_pfn_t *mfn, unsigned long addr)
 {
 privcmd_mmapbatch_t ioctlx;
 int rc;
@@ -107,59 +107,6 @@ static int xc_map_foreign_batch_single(int fd, uint32_t 
dom,
 return rc;
 }
 
-void *xc_map_foreign_batch(xc_interface *xch,
-   uint32_t dom, int prot,
-   xen_pfn_t *arr, int num)
-{
-int fd = xch->privcmdfd;
-privcmd_mmapbatch_t ioctlx;
-void *addr;
-int rc;
-
-addr = mmap(NULL, num << XC_PAGE_SHIFT, prot, MAP_SHARED, fd, 0);
-if ( addr == MAP_FAILED )
-{
-PERROR("xc_map_foreign_batch: mmap failed");
-return NULL;
-}
-
-ioctlx.num = num;
-ioctlx.dom = dom;
-ioctlx.addr = (unsigned long)addr;
-ioctlx.arr = arr;
-
-rc = ioctl(fd, IOCTL_PRIVCMD_MMAPBATCH, );
-if ( (rc < 0) && (errno == ENOENT) )
-{
-int i;
-
-for ( i = 0; i < num; i++ )
-{
-if ( (arr[i] & PRIVCMD_MMAPBATCH_MFN_ERROR) ==
-   PRIVCMD_MMAPBATCH_PAGED_ERROR )
-{
-unsigned long paged_addr = (unsigned long)addr + (i << 
XC_PAGE_SHIFT);
-rc = xc_map_foreign_batch_single(fd, dom, [i],
- paged_addr);

[Xen-devel] [PATCH QEMU-XEN v4 4/9] xen: Switch uses of xc_map_foreign_range into xc_map_foreign_bulk

In Xen 4.7 we are refactoring parts libxenctrl into a number of
separate libraries which will provide backward and forward API and ABI
compatiblity.

One such library will be libxenforeignmemory which provides access to
privileged foreign mappings and which will provide an interface
equivalent to xc_map_foreign_bulk.

In preparation for this switch all uses of xc_map_foreign_range to
xc_map_foreign_bulk. This is trivial because size was always
XC_PAGE_SIZE so the necessary adjustments are trivial:

  * Pass  (an array of length 1) instead of mfn. The function
takes a pointer to const, so there is no possibily of mfn changing
due to this change.
  * Add a local err variable to receive the errors and pass 
(again, an array of length 1)
  * Adjust any existing logging to include err too
  * Pass nr_pages=1 instead of size=XC_PAGE_SIZE

There is one wrinkle in xen_console.c:con_initialise() where
con->ring_ref is an int but can in some code paths (when !xendev->dev)
be treated as an mfn. I think this is an existing latent truncation
hazard on platforms where xen_pfn_t is 64-bit and int is 32-bit (e.g.
amd64, both arm* variants). I'm unsure under what circumstances
xendev->dev can be NULL or if anything elsewhere ensures the value
fits into an int. For now I just use a temporary xen_pfn_t to in
effect upcast the pointer from int* to xen_pfn_t*.

Build tested with 4.0 and 4.5.

Signed-off-by: Ian Campbell 
---
v4: Ran checkpatch, fixed all errors
Mention the const-ness of the mfn array in the commit log
---
 hw/char/xen_console.c |  9 +
 hw/display/xenfb.c|  6 +++---
 xen-hvm.c | 30 --
 3 files changed, 24 insertions(+), 21 deletions(-)

diff --git a/hw/char/xen_console.c b/hw/char/xen_console.c
index 8c06c19..11c6472 100644
--- a/hw/char/xen_console.c
+++ b/hw/char/xen_console.c
@@ -219,6 +219,7 @@ static int con_initialise(struct XenDevice *xendev)
 {
 struct XenConsole *con = container_of(xendev, struct XenConsole, xendev);
 int limit;
+int err;
 
 if (xenstore_read_int(con->console, "ring-ref", >ring_ref) == -1)
return -1;
@@ -228,10 +229,10 @@ static int con_initialise(struct XenDevice *xendev)
con->buffer.max_capacity = limit;
 
 if (!xendev->dev) {
-con->sring = xc_map_foreign_range(xen_xc, con->xendev.dom,
-  XC_PAGE_SIZE,
-  PROT_READ|PROT_WRITE,
-  con->ring_ref);
+xen_pfn_t mfn = con->ring_ref;
+con->sring = xc_map_foreign_bulk(xen_xc, con->xendev.dom,
+ PROT_READ|PROT_WRITE,
+ , , 1);
 } else {
 con->sring = xengnttab_map_grant_ref(xendev->gnttabdev, 
con->xendev.dom,
  con->ring_ref,
diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c
index 8a61e95..10cefed 100644
--- a/hw/display/xenfb.c
+++ b/hw/display/xenfb.c
@@ -94,6 +94,7 @@ struct XenFB {
 static int common_bind(struct common *c)
 {
 uint64_t mfn;
+int err;
 
 if (xenstore_read_fe_uint64(>xendev, "page-ref", ) == -1)
return -1;
@@ -102,9 +103,8 @@ static int common_bind(struct common *c)
 if (xenstore_read_fe_int(>xendev, "event-channel", 
>xendev.remote_port) == -1)
return -1;
 
-c->page = xc_map_foreign_range(xen_xc, c->xendev.dom,
-  XC_PAGE_SIZE,
-  PROT_READ | PROT_WRITE, mfn);
+c->page = xc_map_foreign_bulk(xen_xc, c->xendev.dom,
+  PROT_READ | PROT_WRITE, , , 1);
 if (c->page == NULL)
return -1;
 
diff --git a/xen-hvm.c b/xen-hvm.c
index 4470d58..0c84e30 100644
--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -1167,7 +1167,7 @@ static void xen_wakeup_notifier(Notifier *notifier, void 
*data)
 int xen_hvm_init(ram_addr_t *below_4g_mem_size, ram_addr_t *above_4g_mem_size,
  MemoryRegion **ram_memory)
 {
-int i, rc;
+int i, rc, map_err;
 xen_pfn_t ioreq_pfn;
 xen_pfn_t bufioreq_pfn;
 evtchn_port_t bufioreq_evtchn;
@@ -1214,33 +1214,35 @@ int xen_hvm_init(ram_addr_t *below_4g_mem_size, 
ram_addr_t *above_4g_mem_size,
 DPRINTF("buffered io page at pfn %lx\n", bufioreq_pfn);
 DPRINTF("buffered io evtchn is %x\n", bufioreq_evtchn);
 
-state->shared_page = xc_map_foreign_range(xen_xc, xen_domid, XC_PAGE_SIZE,
-  PROT_READ|PROT_WRITE, ioreq_pfn);
+state->shared_page = xc_map_foreign_bulk(xen_xc, xen_domid,
+ PROT_READ|PROT_WRITE,
+ _pfn, _err, 1);
 if (state->shared_page == NULL) {
-hw_error("map shared IO page returned error %d handle=" 
XC_INTERFACE_FMT,
- errno, xen_xc);
+hw_error(
+

[Xen-devel] [PATCH QEMU-XEN-TRADITIONAL v4 2/5] qemu-xen-traditional: Use libxenevtchn

/dev/xen/evtchn related wrappers have been moved out of libxenctrl
into their own library.

Note that i386-dm/helper2.c's xc_interface * was always really an
xc_evtchn *, it's just they used to be typedefs to the same thing...

Signed-off-by: Ian Campbell 
---
v3: Library moved to tools/libs/
---
 hw/xen_backend.c  | 26 +-
 hw/xen_backend.h  |  2 +-
 hw/xen_common.h   |  1 +
 i386-dm/helper2.c | 19 ++-
 xen-hooks.mak |  2 ++
 5 files changed, 27 insertions(+), 23 deletions(-)

diff --git a/hw/xen_backend.c b/hw/xen_backend.c
index 92b3506..40f6887 100644
--- a/hw/xen_backend.c
+++ b/hw/xen_backend.c
@@ -208,19 +208,19 @@ static struct XenDevice *xen_be_get_xendev(const char 
*type, int dom, int dev,
 xendev->debug  = debug;
 xendev->local_port = -1;
 
-xendev->evtchndev = xc_evtchn_open(NULL, 0);
+xendev->evtchndev = xenevtchn_open(NULL, 0);
 if (xendev->evtchndev == NULL) {
xen_be_printf(NULL, 0, "can't open evtchn device\n");
qemu_free(xendev);
return NULL;
 }
-fcntl(xc_evtchn_fd(xendev->evtchndev), F_SETFD, FD_CLOEXEC);
+fcntl(xenevtchn_fd(xendev->evtchndev), F_SETFD, FD_CLOEXEC);
 
 if (ops->flags & DEVOPS_FLAG_NEED_GNTDEV) {
xendev->gnttabdev = xc_gnttab_open(NULL, 0);
if (xendev->gnttabdev == NULL) {
xen_be_printf(NULL, 0, "can't open gnttab device\n");
-   xc_evtchn_close(xendev->evtchndev);
+   xenevtchn_close(xendev->evtchndev);
qemu_free(xendev);
return NULL;
}
@@ -268,7 +268,7 @@ static struct XenDevice *xen_be_del_xendev(int dom, int dev)
}
 
if (xendev->evtchndev != NULL)
-   xc_evtchn_close(xendev->evtchndev);
+   xenevtchn_close(xendev->evtchndev);
if (xendev->gnttabdev != NULL)
xc_gnttab_close(xendev->gnttabdev);
 
@@ -630,13 +630,13 @@ static void xen_be_evtchn_event(void *opaque)
 struct XenDevice *xendev = opaque;
 evtchn_port_t port;
 
-port = xc_evtchn_pending(xendev->evtchndev);
+port = xenevtchn_pending(xendev->evtchndev);
 if (port != xendev->local_port) {
-   xen_be_printf(xendev, 0, "xc_evtchn_pending returned %d (expected 
%d)\n",
+   xen_be_printf(xendev, 0, "xenevtchn_pending returned %d (expected 
%d)\n",
  port, xendev->local_port);
return;
 }
-xc_evtchn_unmask(xendev->evtchndev, port);
+xenevtchn_unmask(xendev->evtchndev, port);
 
 if (xendev->ops->event)
xendev->ops->event(xendev);
@@ -683,14 +683,14 @@ int xen_be_bind_evtchn(struct XenDevice *xendev)
 {
 if (xendev->local_port != -1)
return 0;
-xendev->local_port = xc_evtchn_bind_interdomain
+xendev->local_port = xenevtchn_bind_interdomain
(xendev->evtchndev, xendev->dom, xendev->remote_port);
 if (xendev->local_port == -1) {
-   xen_be_printf(xendev, 0, "xc_evtchn_bind_interdomain failed\n");
+   xen_be_printf(xendev, 0, "xenevtchn_bind_interdomain failed\n");
return -1;
 }
 xen_be_printf(xendev, 2, "bind evtchn port %d\n", xendev->local_port);
-qemu_set_fd_handler(xc_evtchn_fd(xendev->evtchndev),
+qemu_set_fd_handler(xenevtchn_fd(xendev->evtchndev),
xen_be_evtchn_event, NULL, xendev);
 return 0;
 }
@@ -699,15 +699,15 @@ void xen_be_unbind_evtchn(struct XenDevice *xendev)
 {
 if (xendev->local_port == -1)
return;
-qemu_set_fd_handler(xc_evtchn_fd(xendev->evtchndev), NULL, NULL, NULL);
-xc_evtchn_unbind(xendev->evtchndev, xendev->local_port);
+qemu_set_fd_handler(xenevtchn_fd(xendev->evtchndev), NULL, NULL, NULL);
+xenevtchn_unbind(xendev->evtchndev, xendev->local_port);
 xen_be_printf(xendev, 2, "unbind evtchn port %d\n", xendev->local_port);
 xendev->local_port = -1;
 }
 
 int xen_be_send_notify(struct XenDevice *xendev)
 {
-return xc_evtchn_notify(xendev->evtchndev, xendev->local_port);
+return xenevtchn_notify(xendev->evtchndev, xendev->local_port);
 }
 
 /*
diff --git a/hw/xen_backend.h b/hw/xen_backend.h
index e421391..60f18f8 100644
--- a/hw/xen_backend.h
+++ b/hw/xen_backend.h
@@ -44,7 +44,7 @@ struct XenDevice {
 intremote_port;
 intlocal_port;
 
-xc_evtchn  *evtchndev;
+xenevtchn_handle   *evtchndev;
 xc_gnttab  *gnttabdev;
 
 struct XenDevOps   *ops;
diff --git a/hw/xen_common.h b/hw/xen_common.h
index a615052..cee908f 100644
--- a/hw/xen_common.h
+++ b/hw/xen_common.h
@@ -4,6 +4,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 #include 
diff --git a/i386-dm/helper2.c b/i386-dm/helper2.c
index ede3105..2706f2e 100644
--- a/i386-dm/helper2.c
+++ b/i386-dm/helper2.c
@@ -48,6 +48,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 #include 
@@ -104,7 +105,7 @@ buffered_iopage_t *buffered_io_page = NULL;
 QEMUTimer *buffered_io_timer;
 
 /* the evtchn

[Xen-devel] [PATCH XEN v4 09/23] tools: Refactor hypercall calling wrappers into libxencall.

libxencall will provide a stable API and ABI for calling hypercalls
(although those hypercalls themselves may not have a stable API). As
well as the hypercall buffer infrastructure needed in order to safely
provide pointer arguments to hypercalls.

libxenctrl encapsulates a instance of this interface, so users of that
library are not currently subjected to any actual changes. However all
hypercalls made internally by libxc now use the correct interface. It
is expected that most users of this library will be other libraries
providing a higher level interface, rather than applications directly.

Only the basic functionality to allocate hypercall safe memory is
moved, the type safe stuff and bounce buffers remain in libxc.

Note that the functionality to map foreign pages using privcmd is not
yet moved, meaning that an xc_interface will now contain two open
privcmd file descriptors. Foreign memory mapping is logically separate
functionality and will be moved into its own library.

The new library uses a version script to ensure that only expected
symbols are exported and to version them such that ABI guarantees can
be kept in the future.

Signed-off-by: Ian Campbell 
---

Must be applied with:
  - "qemu-xen-traditional: Add libxencall to rpath-link" and a
corresponding QEMU_TAG update folded here.
  - "mini-os: Include libxencall with libxc" and a corresponding bump
to MINIOS_UPSTREAM_REVISION folded in here.

v3: Moved to tools/libs/call
Ported new wrappers (altp2m)

fixup! port altp2m to libxencall
---
 .gitignore|   2 +
 stubdom/Makefile  |  20 +++-
 tools/Makefile|   1 +
 tools/Rules.mk|   7 +-
 tools/libs/Makefile   |   1 +
 tools/libs/call/Makefile  |  67 +
 tools/libs/call/buffer.c  | 192 ++
 tools/libs/call/core.c| 144 
 tools/libs/call/freebsd.c | 140 +++
 tools/libs/call/include/xencall.h |  84 +
 tools/libs/call/libxencall.map|  19 
 tools/libs/call/linux.c   | 132 ++
 tools/libs/call/minios.c  |  81 
 tools/libs/call/netbsd.c  | 121 
 tools/libs/call/private.h |  68 ++
 tools/libs/call/solaris.c |  97 +++
 tools/libxc/Makefile  |   7 +-
 tools/libxc/xc_altp2m.c   |  64 -
 tools/libxc/xc_domain.c   | 105 +++--
 tools/libxc/xc_evtchn.c   |   9 +-
 tools/libxc/xc_flask.c|   8 +-
 tools/libxc/xc_freebsd_osdep.c|  47 --
 tools/libxc/xc_gnttab.c   |   9 +-
 tools/libxc/xc_hcall_buf.c| 138 ++-
 tools/libxc/xc_kexec.c|  36 +++
 tools/libxc/xc_linux_osdep.c  |  49 --
 tools/libxc/xc_minios.c   |  32 ---
 tools/libxc/xc_misc.c |  79 ++--
 tools/libxc/xc_netbsd.c   |  40 
 tools/libxc/xc_private.c  |  64 +
 tools/libxc/xc_private.h  |  76 +--
 tools/libxc/xc_solaris.c  |  16 
 tools/libxc/xc_tmem.c |   7 +-
 tools/misc/Makefile   |   4 +-
 tools/xcutils/Makefile|   2 +-
 tools/xenpaging/Makefile  |   2 +-
 36 files changed, 1338 insertions(+), 632 deletions(-)
 create mode 100644 tools/libs/call/Makefile
 create mode 100644 tools/libs/call/buffer.c
 create mode 100644 tools/libs/call/core.c
 create mode 100644 tools/libs/call/freebsd.c
 create mode 100644 tools/libs/call/include/xencall.h
 create mode 100644 tools/libs/call/libxencall.map
 create mode 100644 tools/libs/call/linux.c
 create mode 100644 tools/libs/call/minios.c
 create mode 100644 tools/libs/call/netbsd.c
 create mode 100644 tools/libs/call/private.h
 create mode 100644 tools/libs/call/solaris.c

diff --git a/.gitignore b/.gitignore
index 9241c54..2899852 100644
--- a/.gitignore
+++ b/.gitignore
@@ -61,6 +61,7 @@ stubdom/xenstore
 stubdom/libxentoollog-*
 stubdom/libxenevtchn-*
 stubdom/libxengnttab-*
+stubdom/libxencall-*
 stubdom/libxc-*
 stubdom/lwip-*
 stubdom/mini-os-*
@@ -90,6 +91,7 @@ config/Docs.mk
 tools/libs/toollog/headers.chk
 tools/libs/evtchn/headers.chk
 tools/libs/gnttab/headers.chk
+tools/libs/call/headers.chk
 tools/blktap2/daemon/blktapctrl
 tools/blktap2/drivers/img2qcow
 tools/blktap2/drivers/lock-util
diff --git a/stubdom/Makefile b/stubdom/Makefile
index d4576eb..24f0e0f 100644
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -330,6 +330,12 @@ mk-headers-$(XEN_TARGET_ARCH): $(IOEMU_LINKFARM_TARGET)
  ln -sf $(XEN_ROOT)/tools/libs/gnttab/include/*.h include/ && \
  ln -sf $(XEN_ROOT)/tools/libs/gnttab/*.c . && \
  ln -sf $(XEN_ROOT)/tools/libs/gnttab/Makefile . )
+   mkdir -p

[Xen-devel] [PATCH XEN v4 01/23] tools/Rules.mk: Properly handle libraries with recursive dependencies.

In tree libraries which link against other in tree libraries in a way
which is opaque to their callers need special handling, specifically
correct use of -Wl,-rpath-link for the recusively used libraries.

Currently this is rather simple, but up coming changes are going to
introduce transitive dependencies more than 1 step deep.

Introduce a SHDEPS idiom to contain all the recursive deps for a
library and include those in both LDLIBS (for linking) and SHLIB (for
recursive uses).

Try and document the whole thing.

Signed-off-by: Ian Campbell 
Acked-by: Ian Jackson 
---
v4: Unmanged description of libbaz.
---
 tools/Rules.mk | 74 --
 1 file changed, 62 insertions(+), 12 deletions(-)

diff --git a/tools/Rules.mk b/tools/Rules.mk
index 2c422bd..24dc56b 100644
--- a/tools/Rules.mk
+++ b/tools/Rules.mk
@@ -34,25 +34,72 @@ INSTALL_SHLIB = : install-shlib-unsupported-fail
 SYMLINK_SHLIB = : symlink-shlib-unsupported-fail
 endif
 
+# Compiling and linking against in tree libraries.
+#
+# In order to compile and link against an in-tree library various
+# cpp/compiler/linker options are required.
+#
+# For example consider a library "libfoo" which itself uses two other
+# libraries:
+#  libbar - whose use is entirely internal to libfoo and not exposed
+#   to users of libfoo at all.
+#  libbaz - whose use is entirely internal to libfoo but libfoo's
+#   public headers include one or more of libbaz's
+#   public headers. Users of libfoo are therefore transitively
+#   using libbaz's header but not linking against libbaz.
+#
+# SHDEPS_libfoo: Flags for linking recursive dependencies of
+#libfoo. Must contain SHLIB for every library which
+#libfoo links against. So must contain both
+#$(SHLIB_libbar) and $(SHLIB_libbaz).
+#
+# SHLIB_libfoo: Flags for recursively linking against libfoo. Must
+#   contains SHDEPS_libfoo and:
+#   -Wl,-rpath-link=
+#
+# CFLAGS_libfoo: Flags for compiling against libfoo. Must add the
+#directories containing libfoo's headers to the
+#include path. Must recursively include
+#$(CFLAGS_libbaz), to satisfy the transitive inclusion
+#of the headers but not $(CFLAGS_libbar) since none of
+#libbar's headers are required to build against
+#libfoo.
+#
+# LDLIBS_libfoo: Flags for linking against libfoo. Must contain
+#$(SHDEPS_libfoo) and the path to libfoo.so
+#
+# Consumers of libfoo should include $(CFLAGS_libfoo) and
+# $(LDLIBS_libfoo) in their appropriate directories. They should not
+# include any CFLAGS or LDLIBS relating to libbar or libbaz unless
+# they use those libraries directly (not via libfoo) too.
+#
+# Consumers of libfoo should not directly use $(SHDEPS_libfoo) or
+# $(SHLIB_libfoo)
+
 CFLAGS_libxenctrl = -I$(XEN_LIBXC)/include $(CFLAGS_xeninclude)
+SHDEPS_libxenctrl =
 LDLIBS_libxenctrl = $(XEN_LIBXC)/libxenctrl$(libextension)
 SHLIB_libxenctrl  = -Wl,-rpath-link=$(XEN_LIBXC)
 
 CFLAGS_libxenguest = -I$(XEN_LIBXC)/include $(CFLAGS_xeninclude)
-LDLIBS_libxenguest = $(XEN_LIBXC)/libxenguest$(libextension)
-SHLIB_libxenguest  = -Wl,-rpath-link=L$(XEN_LIBXC)
+SHDEPS_libxenguest =
+LDLIBS_libxenguest = $(SHDEPS_libxenguest) 
$(XEN_LIBXC)/libxenguest$(libextension)
+SHLIB_libxenguest  = $(SHDEPS_libxenguest) -Wl,-rpath-link=L$(XEN_LIBXC)
 
 CFLAGS_libxenstore = -I$(XEN_XENSTORE)/include $(CFLAGS_xeninclude)
-LDLIBS_libxenstore = $(XEN_XENSTORE)/libxenstore$(libextension)
-SHLIB_libxenstore  = -Wl,-rpath-link=$(XEN_XENSTORE)
+SHDEPS_libxenstore =
+LDLIBS_libxenstore = $(SHDEPS_libxenguest) 
$(XEN_XENSTORE)/libxenstore$(libextension)
+SHLIB_libxenstore  = $(SHDEPS_libxenguest) -Wl,-rpath-link=$(XEN_XENSTORE)
 
 CFLAGS_libxenstat  = -I$(XEN_LIBXENSTAT)
-LDLIBS_libxenstat  = $(SHLIB_libxenctrl) $(SHLIB_libxenstore) 
$(XEN_LIBXENSTAT)/libxenstat$(libextension)
-SHLIB_libxenstat  = -Wl,-rpath-link=$(XEN_LIBXENSTAT)
+SHDEPS_libxenstat  = $(SHLIB_libxenctrl) $(SHLIB_libxenstore)
+LDLIBS_libxenstat  = $(SHDEPS_libxenstat) 
$(XEN_LIBXENSTAT)/libxenstat$(libextension)
+SHLIB_libxenstat   = $(SHDEPS_libxenstat) -Wl,-rpath-link=$(XEN_LIBXENSTAT)
 
 CFLAGS_libxenvchan = -I$(XEN_LIBVCHAN)
-LDLIBS_libxenvchan = $(SHLIB_libxenctrl) $(SHLIB_libxenstore) 
$(XEN_LIBVCHAN)/libxenvchan$(libextension)
-SHLIB_libxenvchan  = -Wl,-rpath-link=$(XEN_LIBVCHAN)
+SHDEPS_libxenvchan = $(SHLIB_libxenctrl) $(SHLIB_libxenstore)
+LDLIBS_libxenvchan = $(SHDEPS_libxenvchan) 
$(XEN_LIBVCHAN)/libxenvchan$(libextension)
+SHLIB_libxenvchan  = $(SHDEPS_libxenvchan) -Wl,-rpath-link=$(XEN_LIBVCHAN)
 
 ifeq ($(debug),y)
 # Disable optimizations and enable debugging information for macros
@@ -65,17 +112,20 @@ LIBXL_BLKTAP ?= $(CONFIG_BLKTAP2)
 
 ifeq ($(LIBXL_BLKTAP),y)
 CFLAGS_libblktapctl =

[Xen-devel] [PATCH XEN v4 07/23] tools: Refactor /dev/xen/gnt{dev, shr} wrappers into libxengnttab.

libxengnttab will provide a stable API and ABI for accessing the
grant table devices.

The functions are moved into the xengnt{tab,shr} namespace to make a
clean break from libxc and avoid ambiguity regarding which interfaces
are stable.

XXX consider combining into a single namespace (i.e. with
xengnttab_handle having two open fd's in it on Linux)

All in-tree users are updated to use the new names.

Upon request (via #define XC_WANT_COMPAT_GNTTAB_API) libxenctrl will
provide a compat API for the old names. This is used by qemu-xen for
the time being. qemu-xen-traditional is updated in lockstep.

This leaves a few grant table related functions which go via privcmd
(EVTCHNOP) rather than ioctls on the /dev/xen/gnt* devices in
libxenctrl. Specifically:

  - xc_gnttab_get_version
  - xc_gnttab_map_table_v1
  - xc_gnttab_map_table_v2
  - xc_gnttab_op

These functions do not appear to be needed by qemu-dm, qemu-pv
(provision of device model to HVM guests and PV backends respectively)
or by libvchan suggesting they are not needed by non-toolstack uses of
event channels.

The new library uses a version script to ensure that only expected
symbols are exported and to version them such that ABI guarantees can
be kept in the future.

After this change libxenvchan no longer needs to link against
libxenctrl. It still needs xenctrl.h in one file for xen_mb and
friends.

Signed-off-by: Ian Campbell 
---

Must be applied with:

 - "qemu-xen-traditional: Use libxengnttab" and a corresponding
   QEMU_TAG update folded here.
 - "mini-os: Include libxengnttab with libxc"" and a corresponding
   bump to MINIOS_UPSTREAM_REVISION folded in here.

v3:
 - Remove SHLIB_libxenctrl from SHDEPS_libxenvchan, and replace with
   SHLIB_libxentoollog.
 - Move to tools/libs/gnttab
 - Adjust for rebase over 31cf2ca75181 "tools/libxc: linux: Don't use
   getpagesize() when unmapping the grants"
---
 .gitignore |   2 +
 stubdom/Makefile   |  19 +-
 tools/Makefile |   3 +
 tools/Rules.mk |  14 +-
 tools/console/Makefile |   5 +-
 tools/console/daemon/io.c  |  21 +-
 tools/libs/Makefile|   1 +
 tools/libs/evtchn/minios.c |   5 +-
 tools/libs/gnttab/Makefile |  69 +
 tools/libs/gnttab/gntshr_core.c|  92 ++
 .../xc_nognttab.c => libs/gnttab/gntshr_unimp.c}   |  34 ++-
 tools/libs/gnttab/gnttab_core.c| 121 
 tools/libs/gnttab/gnttab_unimp.c   |  89 ++
 tools/libs/gnttab/include/xengnttab.h  | 218 ++
 tools/libs/gnttab/libxengnttab.map |  23 ++
 tools/libs/gnttab/linux.c  | 329 +
 tools/libs/gnttab/minios.c | 117 
 tools/libs/gnttab/private.h|  47 +++
 tools/libvchan/Makefile|   8 +-
 tools/libvchan/init.c  |  24 +-
 tools/libvchan/io.c|   8 +-
 tools/libvchan/libxenvchan.h   |   6 +-
 tools/libxc/Makefile   |  15 +-
 tools/libxc/include/xenctrl.h  | 168 ---
 tools/libxc/include/xenctrl_compat.h   |  48 +++
 tools/libxc/xc_gnttab.c|  53 
 tools/libxc/xc_gnttab_compat.c | 111 +++
 tools/libxc/xc_linux_osdep.c   | 280 --
 tools/libxc/xc_minios.c|  73 -
 tools/libxc/xc_nogntshr.c  |  46 ---
 tools/libxc/xc_private.c   |  80 -
 tools/libxc/xc_private.h   |  24 --
 tools/xenstore/Makefile|   4 +-
 tools/xenstore/xenstored_core.h|   4 +-
 tools/xenstore/xenstored_domain.c  |  24 +-
 tools/xenstore/xenstored_minios.c  |   5 +-
 36 files changed, 1390 insertions(+), 800 deletions(-)
 create mode 100644 tools/libs/gnttab/Makefile
 create mode 100644 tools/libs/gnttab/gntshr_core.c
 rename tools/{libxc/xc_nognttab.c => libs/gnttab/gntshr_unimp.c} (52%)
 create mode 100644 tools/libs/gnttab/gnttab_core.c
 create mode 100644 tools/libs/gnttab/gnttab_unimp.c
 create mode 100644 tools/libs/gnttab/include/xengnttab.h
 create mode 100644 tools/libs/gnttab/libxengnttab.map
 create mode 100644 tools/libs/gnttab/linux.c
 create mode 100644 tools/libs/gnttab/minios.c
 create mode 100644 tools/libs/gnttab/private.h
 create mode 100644 tools/libxc/xc_gnttab_compat.c
 delete mode 100644 tools/libxc/xc_nogntshr.c

diff --git a/.gitignore b/.gitignore
index b34dc3c..9241c54 100644
--- a/.gitignore
+++ b/.gitignore
@@

[Xen-devel] [PATCH QEMU-XEN-TRADITIONAL v4 5/5] qemu-xen-traditional: Add libxenforeignmemory to rpath-link

libxenctrl links against this library.

Also, request the compat xc_map_foreign API from libxc.

Signed-off-by: Ian Campbell 
---
v3: Library moved to tools/libs/
---
 xen-hooks.mak | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/xen-hooks.mak b/xen-hooks.mak
index 229d642..c1ea4be 100644
--- a/xen-hooks.mak
+++ b/xen-hooks.mak
@@ -1,6 +1,7 @@
 CPPFLAGS+= -I$(XEN_ROOT)/tools/libs/toollog/include
 CPPFLAGS+= -I$(XEN_ROOT)/tools/libs/evtchn/include
 CPPFLAGS+= -I$(XEN_ROOT)/tools/libs/gnttab/include
+CPPFLAGS+= -DXC_WANT_COMPAT_MAP_FOREIGN_API
 CPPFLAGS+= -I$(XEN_ROOT)/tools/libxc/include
 CPPFLAGS+= -I$(XEN_ROOT)/tools/xenstore/include
 CPPFLAGS+= -I$(XEN_ROOT)/tools/include
@@ -26,6 +27,7 @@ LIBS += -L$(XEN_ROOT)/tools/libxc -lxenctrl -lxenguest
 LIBS += -L$(XEN_ROOT)/tools/xenstore -lxenstore
 LIBS += -Wl,-rpath-link=$(XEN_ROOT)/tools/libs/toollog
 LIBS += -Wl,-rpath-link=$(XEN_ROOT)/tools/libs/call
+LIBS += -Wl,-rpath-link=$(XEN_ROOT)/tools/libs/foreignmemory
 
 LDFLAGS := $(CFLAGS) $(LDFLAGS)
 
-- 
2.1.4


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

[Xen-devel] [PATCH QEMU-XEN v4 2/9] xen: Switch to libxenevtchn interface for compat shims.

In Xen 4.7 we are refactoring parts libxenctrl into a number of
separate libraries which will provide backward and forward API and ABI
compatiblity.

One such library will be libxenevtchn which provides access to event
channels.

In preparation for this switch the compatibility layer in xen_common.h
(which support building with older versions of Xen) to use what will
be the new library API. This means that the evtchn shim will disappear
for versions of Xen which include libxenevtchn.

To simplify things for the <= 4.0.0 support we wrap the int fd in a
malloc(sizeof int) such that the handle is always a pointer. This
leads to less typedef headaches and the need for
XC_HANDLER_INITIAL_VALUE etc for these interfaces.

Build tested with 4.0 and 4.5.

Note that this patch does not add any support for actually using
libxenevtchn, it just adjusts the existing shims.

Note that xc_evtchn_alloc_unbound functionality remains in libxenctrl,
since that functionality is not exposed by /dev/xen/evtchn.

Signed-off-by: Ian Campbell 
---
v4: Ran checkpatch, fixed all errors
Allocate correct size for handle (i.e. not size of the ptr)
---
 hw/xen/xen_backend.c | 31 ---
 include/hw/xen/xen_backend.h |  2 +-
 include/hw/xen/xen_common.h  | 44 ++--
 xen-hvm.c| 25 +
 4 files changed, 64 insertions(+), 38 deletions(-)

diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
index b2cb22b..342ec9b 100644
--- a/hw/xen/xen_backend.c
+++ b/hw/xen/xen_backend.c
@@ -243,19 +243,19 @@ static struct XenDevice *xen_be_get_xendev(const char 
*type, int dom, int dev,
 xendev->debug  = debug;
 xendev->local_port = -1;
 
-xendev->evtchndev = xen_xc_evtchn_open(NULL, 0);
-if (xendev->evtchndev == XC_HANDLER_INITIAL_VALUE) {
+xendev->evtchndev = xenevtchn_open(NULL, 0);
+if (xendev->evtchndev == NULL) {
 xen_be_printf(NULL, 0, "can't open evtchn device\n");
 g_free(xendev);
 return NULL;
 }
-fcntl(xc_evtchn_fd(xendev->evtchndev), F_SETFD, FD_CLOEXEC);
+fcntl(xenevtchn_fd(xendev->evtchndev), F_SETFD, FD_CLOEXEC);
 
 if (ops->flags & DEVOPS_FLAG_NEED_GNTDEV) {
 xendev->gnttabdev = xen_xc_gnttab_open(NULL, 0);
 if (xendev->gnttabdev == XC_HANDLER_INITIAL_VALUE) {
 xen_be_printf(NULL, 0, "can't open gnttab device\n");
-xc_evtchn_close(xendev->evtchndev);
+xenevtchn_close(xendev->evtchndev);
 g_free(xendev);
 return NULL;
 }
@@ -306,8 +306,8 @@ static struct XenDevice *xen_be_del_xendev(int dom, int dev)
 g_free(xendev->fe);
 }
 
-if (xendev->evtchndev != XC_HANDLER_INITIAL_VALUE) {
-xc_evtchn_close(xendev->evtchndev);
+if (xendev->evtchndev != NULL) {
+xenevtchn_close(xendev->evtchndev);
 }
 if (xendev->gnttabdev != XC_HANDLER_INITIAL_VALUE) {
 xc_gnttab_close(xendev->gnttabdev);
@@ -691,13 +691,14 @@ static void xen_be_evtchn_event(void *opaque)
 struct XenDevice *xendev = opaque;
 evtchn_port_t port;
 
-port = xc_evtchn_pending(xendev->evtchndev);
+port = xenevtchn_pending(xendev->evtchndev);
 if (port != xendev->local_port) {
-xen_be_printf(xendev, 0, "xc_evtchn_pending returned %d (expected 
%d)\n",
+xen_be_printf(xendev, 0,
+  "xenevtchn_pending returned %d (expected %d)\n",
   port, xendev->local_port);
 return;
 }
-xc_evtchn_unmask(xendev->evtchndev, port);
+xenevtchn_unmask(xendev->evtchndev, port);
 
 if (xendev->ops->event) {
 xendev->ops->event(xendev);
@@ -742,14 +743,14 @@ int xen_be_bind_evtchn(struct XenDevice *xendev)
 if (xendev->local_port != -1) {
 return 0;
 }
-xendev->local_port = xc_evtchn_bind_interdomain
+xendev->local_port = xenevtchn_bind_interdomain
 (xendev->evtchndev, xendev->dom, xendev->remote_port);
 if (xendev->local_port == -1) {
-xen_be_printf(xendev, 0, "xc_evtchn_bind_interdomain failed\n");
+xen_be_printf(xendev, 0, "xenevtchn_bind_interdomain failed\n");
 return -1;
 }
 xen_be_printf(xendev, 2, "bind evtchn port %d\n", xendev->local_port);
-qemu_set_fd_handler(xc_evtchn_fd(xendev->evtchndev),
+qemu_set_fd_handler(xenevtchn_fd(xendev->evtchndev),
 xen_be_evtchn_event, NULL, xendev);
 return 0;
 }
@@ -759,15 +760,15 @@ void xen_be_unbind_evtchn(struct XenDevice *xendev)
 if (xendev->local_port == -1) {
 return;
 }
-qemu_set_fd_handler(xc_evtchn_fd(xendev->evtchndev), NULL, NULL, NULL);
-xc_evtchn_unbind(xendev->evtchndev, xendev->local_port);
+qemu_set_fd_handler(xenevtchn_fd(xendev->evtchndev), NULL, NULL, NULL);
+xenevtchn_unbind(xendev->evtchndev, xendev->local_port);

[Xen-devel] [PATCH QEMU-XEN v4 9/9] xen: make it possible to build without the Xen PV domain builder

Until the previous patch this relied on xc_fd(), which was only
implemented for Xen 4.0 and earlier.

Given this wasn't working since Xen 4.0 I have marked this as disabled
by default.

Removing this support drops the use of a bunch of symbols from
libxenctrl, specifically:

  - xc_domain_create
  - xc_domain_destroy
  - xc_domain_getinfo
  - xc_domain_max_vcpus
  - xc_domain_setmaxmem
  - xc_domain_unpause
  - xc_evtchn_alloc_unbound
  - xc_linux_build

This is another step towards only using Xen libraries which provide a
stable inteface.

Signed-off-by: Ian Campbell 
---
v4: Fixed all checkpatch errors.
Disabled by default.
---
 configure | 17 +
 hw/xenpv/Makefile.objs|  4 +++-
 hw/xenpv/xen_machine_pv.c | 14 ++
 3 files changed, 30 insertions(+), 5 deletions(-)

diff --git a/configure b/configure
index fe0a39d..9eab587 100755
--- a/configure
+++ b/configure
@@ -910,6 +910,10 @@ for opt do
   ;;
   --enable-xen-pci-passthrough) xen_pci_passthrough="yes"
   ;;
+  --disable-xen-pv-domain-build) xen_pv_domain_build="no"
+  ;;
+  --enable-xen-pv-domain-build) xen_pv_domain_build="yes"
+  ;;
   --disable-brlapi) brlapi="no"
   ;;
   --enable-brlapi) brlapi="yes"
@@ -2113,6 +2117,15 @@ if test "$xen_pci_passthrough" != "no"; then
   fi
 fi
 
+if test "$xen_pv_domain_build" != "no"; then
+  if test "$xen_pv_domain_build" = "yes" &&
+ test "$xen" != "yes"; then
+  error_exit "User requested Xen PV domain builder support" \
+"which requires Xen support."
+  fi
+  xen_pv_domain_build=no
+fi
+
 ##
 # libtool probe
 
@@ -4393,6 +4406,7 @@ fi
 echo "xen support   $xen"
 if test "$xen" = "yes" ; then
   echo "xen ctrl version  $xen_ctrl_version"
+  echo "pv dom build $xen_pv_domain_build"
 fi
 echo "brlapi support$brlapi"
 echo "bluez  support$bluez"
@@ -4725,6 +4739,9 @@ fi
 if test "$xen" = "yes" ; then
   echo "CONFIG_XEN_BACKEND=y" >> $config_host_mak
   echo "CONFIG_XEN_CTRL_INTERFACE_VERSION=$xen_ctrl_version" >> 
$config_host_mak
+  if test "$xen_pv_domain_build" = "yes" ; then
+echo "CONFIG_XEN_PV_DOMAIN_BUILD=y" >> $config_host_mak
+  fi
 fi
 if test "$linux_aio" = "yes" ; then
   echo "CONFIG_LINUX_AIO=y" >> $config_host_mak
diff --git a/hw/xenpv/Makefile.objs b/hw/xenpv/Makefile.objs
index 49f6e9e..bbf5873 100644
--- a/hw/xenpv/Makefile.objs
+++ b/hw/xenpv/Makefile.objs
@@ -1,2 +1,4 @@
 # Xen PV machine support
-obj-$(CONFIG_XEN) += xen_domainbuild.o xen_machine_pv.o
+obj-$(CONFIG_XEN) += xen_machine_pv.o
+# Xen PV machine builder support
+obj-$(CONFIG_XEN_PV_DOMAIN_BUILD) += xen_domainbuild.o
diff --git a/hw/xenpv/xen_machine_pv.c b/hw/xenpv/xen_machine_pv.c
index 2e545d2..e5b3698 100644
--- a/hw/xenpv/xen_machine_pv.c
+++ b/hw/xenpv/xen_machine_pv.c
@@ -30,9 +30,6 @@
 
 static void xen_init_pv(MachineState *machine)
 {
-const char *kernel_filename = machine->kernel_filename;
-const char *kernel_cmdline = machine->kernel_cmdline;
-const char *initrd_filename = machine->initrd_filename;
 DriveInfo *dinfo;
 int i;
 
@@ -46,13 +43,22 @@ static void xen_init_pv(MachineState *machine)
 case XEN_ATTACH:
 /* nothing to do, xend handles everything */
 break;
-case XEN_CREATE:
+case XEN_CREATE: {
+#ifdef CONFIG_XEN_PV_DOMAIN_BUILD
+const char *kernel_filename = machine->kernel_filename;
+const char *kernel_cmdline = machine->kernel_cmdline;
+const char *initrd_filename = machine->initrd_filename;
 if (xen_domain_build_pv(kernel_filename, initrd_filename,
 kernel_cmdline) < 0) {
 fprintf(stderr, "xen pv domain creation failed\n");
 exit(1);
 }
+#else
+fprintf(stderr, "xen pv domain creation not supported\n");
+exit(1);
+#endif
 break;
+}
 case XEN_EMULATE:
 fprintf(stderr, "xen emulation not implemented (yet)\n");
 exit(1);
-- 
2.1.4


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

[Xen-devel] [PATCH XEN v4 08/23] tools/libxc: Remove osdep indirection for privcmd

The alternative backend (a xen-api/xapi shim) is no longer around and
so this stuff is now just baggage which is getting in the way of
refactoring libxenctrl.

Nested virt probably suffices for this use case now.

This was the last component of the osdep infrastructure, so all the
dynamic loading etc stuff all falls away too.

As part of this I was forced to investigate the twisty
xc_map_foreign_* maze, which I have added to the
toolstack-library-apis doc in the hopes of doing something sensible.

NetBSD and Solaris now call xc_map_foreign_bulk_compat directly from
their xc_map_foreign_bulk, which could have been achieved by using
some ifdefs around a renamed function. This will fall out in the wash
when these functions move to their own library.

Signed-off-by: Ian Campbell 
Acked-by: David Scott 
Cc: David Scott 
---
 config/FreeBSD.mk   |   2 -
 config/NetBSD.mk|   3 -
 config/NetBSDRump.mk|   1 -
 config/StdGNU.mk|   1 -
 config/SunOS.mk |   1 -
 tools/libxc/Makefile|  27 ++
 tools/libxc/include/xenctrl.h   |   9 --
 tools/libxc/include/xenctrlosdep.h  | 133 ---
 tools/libxc/xc_foreign_memory.c |  31 +--
 tools/libxc/xc_freebsd_osdep.c  | 100 ++---
 tools/libxc/xc_hcall_buf.c  |   6 +-
 tools/libxc/xc_linux_osdep.c|  88 ++
 tools/libxc/xc_minios.c |  82 +
 tools/libxc/xc_netbsd.c |  90 +++
 tools/libxc/xc_private.c| 174 ++--
 tools/libxc/xc_private.h|  19 ++--
 tools/libxc/xc_solaris.c|  90 +++
 tools/libxc/xenctrl_osdep_ENOSYS.c  | 123 -
 tools/ocaml/libs/xc/xenctrl.ml  |   2 -
 tools/ocaml/libs/xc/xenctrl.mli |   1 -
 tools/ocaml/libs/xc/xenctrl_stubs.c |   7 --
 tools/ocaml/xenstored/domains.ml|   6 +-
 tools/ocaml/xenstored/xenstored.ml  |   5 +-
 23 files changed, 178 insertions(+), 823 deletions(-)
 delete mode 100644 tools/libxc/include/xenctrlosdep.h
 delete mode 100644 tools/libxc/xenctrl_osdep_ENOSYS.c

diff --git a/config/FreeBSD.mk b/config/FreeBSD.mk
index 5a13d607..bb3a5d0 100644
--- a/config/FreeBSD.mk
+++ b/config/FreeBSD.mk
@@ -1,6 +1,4 @@
 include $(XEN_ROOT)/config/StdGNU.mk
 
-DLOPEN_LIBS =
-
 # No wget on FreeBSD base system
 WGET = ftp
diff --git a/config/NetBSD.mk b/config/NetBSD.mk
index 21318d6..cf766e5 100644
--- a/config/NetBSD.mk
+++ b/config/NetBSD.mk
@@ -1,6 +1,3 @@
 include $(XEN_ROOT)/config/StdGNU.mk
 
-# Override settings for this OS
-DLOPEN_LIBS =
-
 WGET = ftp
diff --git a/config/NetBSDRump.mk b/config/NetBSDRump.mk
index 2a87218..74755a1 100644
--- a/config/NetBSDRump.mk
+++ b/config/NetBSDRump.mk
@@ -1,6 +1,5 @@
 include $(XEN_ROOT)/config/StdGNU.mk
 
-DLOPEN_LIBS =
 PTHREAD_LIBS =
 
 WGET = ftp
diff --git a/config/StdGNU.mk b/config/StdGNU.mk
index 129d5c8..39d36b2 100644
--- a/config/StdGNU.mk
+++ b/config/StdGNU.mk
@@ -31,7 +31,6 @@ DEBUG_DIR ?= /usr/lib/debug
 
 SOCKET_LIBS =
 UTIL_LIBS = -lutil
-DLOPEN_LIBS = -ldl
 
 SONAME_LDFLAG = -soname
 SHLIB_LDFLAGS = -shared
diff --git a/config/SunOS.mk b/config/SunOS.mk
index db5e898..86a384d 100644
--- a/config/SunOS.mk
+++ b/config/SunOS.mk
@@ -27,7 +27,6 @@ SunOS_LIBDIR_x86_64 = /usr/sfw/lib/amd64
 SOCKET_LIBS = -lsocket
 PTHREAD_LIBS = -lpthread
 UTIL_LIBS =
-DLOPEN_LIBS = -ldl
 
 SONAME_LDFLAG = -h
 SHLIB_LDFLAGS = -R $(SunOS_LIBDIR) -shared
diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index 33d18db..3305fdd 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -101,8 +101,6 @@ GUEST_SRCS-y += 
xc_dom_decompress_unsafe_lzo1x.c
 GUEST_SRCS-y += xc_dom_decompress_unsafe_xz.c
 endif
 
-OSDEP_SRCS-y += xenctrl_osdep_ENOSYS.c
-
 -include $(XEN_TARGET_ARCH)/Makefile
 
 CFLAGS   += -Werror -Wmissing-prototypes
@@ -121,11 +119,8 @@ CTRL_PIC_OBJS := $(patsubst %.c,%.opic,$(CTRL_SRCS-y))
 GUEST_LIB_OBJS := $(patsubst %.c,%.o,$(GUEST_SRCS-y))
 GUEST_PIC_OBJS := $(patsubst %.c,%.opic,$(GUEST_SRCS-y))
 
-OSDEP_LIB_OBJS := $(patsubst %.c,%.o,$(OSDEP_SRCS-y))
-OSDEP_PIC_OBJS := $(patsubst %.c,%.opic,$(OSDEP_SRCS-y))
-
-$(CTRL_LIB_OBJS) $(GUEST_LIB_OBJS) $(OSDEP_LIB_OBJS) \
-$(CTRL_PIC_OBJS) $(GUEST_PIC_OBJS) $(OSDEP_PIC_OBJS) : CFLAGS += -include 
$(XEN_ROOT)/tools/config.h
+$(CTRL_LIB_OBJS) $(GUEST_LIB_OBJS) \
+$(CTRL_PIC_OBJS) $(GUEST_PIC_OBJS): CFLAGS += -include 
$(XEN_ROOT)/tools/config.h
 
 $(CTRL_LIB_OBJS) $(CTRL_PIC_OBJS): CFLAGS += $(CFLAGS_libxengnttab) 
$(CFLAGS_libxengntshr)
 
@@ -139,17 +134,13 @@ ifneq ($(nosharedlibs),y)
 LIB += libxenguest.so libxenguest.so.$(MAJOR) libxenguest.so.$(MAJOR).$(MINOR)
 endif
 
-ifneq ($(nosharedlibs),y)
-LIB += xenctrl_osdep_ENOSYS.so
-endif
-
 genpath-target = $(call

[Xen-devel] [PATCH QEMU-XEN v4 5/9] xen: Switch uses of xc_map_foreign_pages into xc_map_foreign_bulk

In Xen 4.7 we are refactoring parts libxenctrl into a number of
separate libraries which will provide backward and forward API and ABI
compatiblity.

One such library will be libxenforeignmemory which provides access to
privileged foreign mappings and which will provide an interface
equivalent to xc_map_foreign_bulk.

In preparation for this switch both uses of xc_map_foreign_pages
(which both happen to be in xenfb_map_fb) to xc_map_foreign_bulk. This
simply requires allocating and passing a new err array (the same one
for both calls).

Build tested with 4.0 and 4.5.

Signed-off-by: Ian Campbell 
Acked-by: Stefano Stabellini 
---
v4: Fix indentation
---
 hw/display/xenfb.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c
index 10cefed..b0ac1e6 100644
--- a/hw/display/xenfb.c
+++ b/hw/display/xenfb.c
@@ -428,6 +428,7 @@ static int xenfb_map_fb(struct XenFB *xenfb)
 int n_fbdirs;
 xen_pfn_t *pgmfns = NULL;
 xen_pfn_t *fbmfns = NULL;
+int *errs = NULL;
 void *map, *pd;
 int mode, ret = -1;
 
@@ -487,17 +488,18 @@ static int xenfb_map_fb(struct XenFB *xenfb)
 
 pgmfns = g_malloc0(sizeof(xen_pfn_t) * n_fbdirs);
 fbmfns = g_malloc0(sizeof(xen_pfn_t) * xenfb->fbpages);
+errs = g_malloc0(sizeof(int) * n_fbdirs);
 
 xenfb_copy_mfns(mode, n_fbdirs, pgmfns, pd);
-map = xc_map_foreign_pages(xen_xc, xenfb->c.xendev.dom,
-  PROT_READ, pgmfns, n_fbdirs);
+map = xc_map_foreign_bulk(xen_xc, xenfb->c.xendev.dom,
+  PROT_READ, pgmfns, errs, n_fbdirs);
 if (map == NULL)
goto out;
 xenfb_copy_mfns(mode, xenfb->fbpages, fbmfns, map);
 munmap(map, n_fbdirs * XC_PAGE_SIZE);
 
-xenfb->pixels = xc_map_foreign_pages(xen_xc, xenfb->c.xendev.dom,
-PROT_READ, fbmfns, xenfb->fbpages);
+xenfb->pixels = xc_map_foreign_bulk(xen_xc, xenfb->c.xendev.dom,
+PROT_READ, fbmfns, errs, xenfb->fbpages);
 if (xenfb->pixels == NULL)
goto out;
 
@@ -506,6 +508,7 @@ static int xenfb_map_fb(struct XenFB *xenfb)
 out:
 g_free(pgmfns);
 g_free(fbmfns);
+g_free(errs);
 return ret;
 }
 
-- 
2.1.4


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

[Xen-devel] [PATCH XEN v4 03/23] tools/libxc: Remove osdep indirection for xc_evtchn

The alternative backend (a xen-api/xapi shim) is no longer around and
so this stuff is now just baggage which is getting in the way of
refactoring libxenctrl.

Note that the intention is to move this into a separate library
shortly.

Nested virt probably suffices for this use case now.

One incorrect instance of using xc_interface where xc_evtchn (in ocaml
stubs) is removed, this used to work because they were typedefs to the
same struct, but is no longer permitted.

Signed-off-by: Ian Campbell 
---
 tools/libxc/include/xenctrl.h |  2 +-
 tools/libxc/include/xenctrlosdep.h| 16 -
 tools/libxc/xc_evtchn.c   | 45 --
 tools/libxc/xc_freebsd_osdep.c| 79 
 tools/libxc/xc_linux_osdep.c  | 76 +--
 tools/libxc/xc_minios.c   | 63 ---
 tools/libxc/xc_netbsd.c   | 72 --
 tools/libxc/xc_private.c  | 37 +---
 tools/libxc/xc_private.h  | 17 ++
 tools/libxc/xc_solaris.c  | 71 --
 tools/libxc/xenctrl_osdep_ENOSYS.c| 87 ---
 tools/ocaml/libs/eventchn/xeneventchn_stubs.c |  4 +-
 12 files changed, 180 insertions(+), 389 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 3bfa00b..4a71af3 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -117,7 +117,7 @@
  */
 
 typedef struct xc_interface_core xc_interface;
-typedef struct xc_interface_core xc_evtchn;
+typedef struct xenevtchn_handle xc_evtchn;
 typedef struct xc_interface_core xc_gnttab;
 typedef struct xc_interface_core xc_gntshr;
 
diff --git a/tools/libxc/include/xenctrlosdep.h 
b/tools/libxc/include/xenctrlosdep.h
index 5121d9b..89564e1 100644
--- a/tools/libxc/include/xenctrlosdep.h
+++ b/tools/libxc/include/xenctrlosdep.h
@@ -51,7 +51,6 @@
 
 enum xc_osdep_type {
 XC_OSDEP_PRIVCMD,
-XC_OSDEP_EVTCHN,
 XC_OSDEP_GNTTAB,
 XC_OSDEP_GNTSHR,
 };
@@ -90,21 +89,6 @@ struct xc_osdep_ops
 int nentries);
 } privcmd;
 struct {
-int (*fd)(xc_evtchn *xce, xc_osdep_handle h);
-
-int (*notify)(xc_evtchn *xce, xc_osdep_handle h, evtchn_port_t 
port);
-
-evtchn_port_or_error_t (*bind_unbound_port)(xc_evtchn *xce, 
xc_osdep_handle h, int domid);
-evtchn_port_or_error_t (*bind_interdomain)(xc_evtchn *xce, 
xc_osdep_handle h, int domid,
-   evtchn_port_t 
remote_port);
-evtchn_port_or_error_t (*bind_virq)(xc_evtchn *xce, 
xc_osdep_handle h, unsigned int virq);
-
-int (*unbind)(xc_evtchn *xce, xc_osdep_handle h, evtchn_port_t 
port);
-
-evtchn_port_or_error_t (*pending)(xc_evtchn *xce, xc_osdep_handle 
h);
-int (*unmask)(xc_evtchn *xce, xc_osdep_handle h, evtchn_port_t 
port);
-} evtchn;
-struct {
 #define XC_GRANT_MAP_SINGLE_DOMAIN 0x1
 void *(*grant_map)(xc_gnttab *xcg, xc_osdep_handle h,
uint32_t count, int flags, int prot,
diff --git a/tools/libxc/xc_evtchn.c b/tools/libxc/xc_evtchn.c
index 15f0580..ae2fe1a 100644
--- a/tools/libxc/xc_evtchn.c
+++ b/tools/libxc/xc_evtchn.c
@@ -77,51 +77,6 @@ int xc_evtchn_status(xc_interface *xch, xc_evtchn_status_t 
*status)
 sizeof(*status), 1);
 }
 
-int xc_evtchn_fd(xc_evtchn *xce)
-{
-return xce->ops->u.evtchn.fd(xce, xce->ops_handle);
-}
-
-int xc_evtchn_notify(xc_evtchn *xce, evtchn_port_t port)
-{
-return xce->ops->u.evtchn.notify(xce, xce->ops_handle, port);
-}
-
-evtchn_port_or_error_t
-xc_evtchn_bind_unbound_port(xc_evtchn *xce, int domid)
-{
-return xce->ops->u.evtchn.bind_unbound_port(xce, xce->ops_handle, domid);
-}
-
-evtchn_port_or_error_t
-xc_evtchn_bind_interdomain(xc_evtchn *xce, int domid,
-   evtchn_port_t remote_port)
-{
-return xce->ops->u.evtchn.bind_interdomain(xce, xce->ops_handle, domid, 
remote_port);
-}
-
-evtchn_port_or_error_t
-xc_evtchn_bind_virq(xc_evtchn *xce, unsigned int virq)
-{
-return xce->ops->u.evtchn.bind_virq(xce, xce->ops_handle, virq);
-}
-
-int xc_evtchn_unbind(xc_evtchn *xce, evtchn_port_t port)
-{
-return xce->ops->u.evtchn.unbind(xce, xce->ops_handle, port);
-}
-
-evtchn_port_or_error_t
-xc_evtchn_pending(xc_evtchn *xce)
-{
-return xce->ops->u.evtchn.pending(xce, xce->ops_handle);
-}
-
-int xc_evtchn_unmask(xc_evtchn *xce, evtchn_port_t port)
-{
-return xce->ops->u.evtchn.unmask(xce, xce->ops_handle, port);
-}
-
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxc/xc_freebsd_osdep.c b/tools/libxc/xc_freebsd_osdep.c
index 4d31a1e..4323e16 100644
--- a/tools/libxc/xc_freebsd_osdep.c
+++

[Xen-devel] [PATCH XEN v4 06/23] tools/libxc: Remove osdep indirection for xc_gnt{shr, tab}

The alternative backend (a xen-api/xapi shim) is no longer around and
so this stuff is now just baggage which is getting in the way of
refactoring libxenctrl.

Nested virt probably suffices for this use case now.

It is now necessary to provide explicit versions of things for
platforms which do not implement this functionality, since the osdep
dispatcher cannot fulfil this need any more. These are provided by
appropriate xc_nognt???.c files which are compiled and linked on the
appropriate platforms. In them open and close return failure and
everything else aborts, since if open fails they should never be
called.

Signed-off-by: Ian Campbell 
---
 tools/libxc/Makefile   |  10 ++--
 tools/libxc/include/xenctrl.h  |   4 +-
 tools/libxc/include/xenctrlosdep.h |  23 ---
 tools/libxc/xc_gnttab.c|  57 --
 tools/libxc/xc_linux_osdep.c   | 119 +++--
 tools/libxc/xc_minios.c|  51 ++--
 tools/libxc/xc_nogntshr.c  |  46 ++
 tools/libxc/xc_nognttab.c  |  50 
 tools/libxc/xc_private.c   |  83 +-
 tools/libxc/xc_private.h   |  24 
 10 files changed, 274 insertions(+), 193 deletions(-)
 create mode 100644 tools/libxc/xc_nogntshr.c
 create mode 100644 tools/libxc/xc_nognttab.c

diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index b8fc6a5..184cbb7 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -43,11 +43,11 @@ CTRL_SRCS-y   += xc_resource.c
 CTRL_SRCS-$(CONFIG_X86) += xc_psr.c
 CTRL_SRCS-$(CONFIG_X86) += xc_pagetab.c
 CTRL_SRCS-$(CONFIG_Linux) += xc_linux.c xc_linux_osdep.c
-CTRL_SRCS-$(CONFIG_FreeBSD) += xc_freebsd.c xc_freebsd_osdep.c
-CTRL_SRCS-$(CONFIG_SunOS) += xc_solaris.c
-CTRL_SRCS-$(CONFIG_NetBSD) += xc_netbsd.c
-CTRL_SRCS-$(CONFIG_NetBSDRump) += xc_netbsd.c
-CTRL_SRCS-$(CONFIG_MiniOS) += xc_minios.c
+CTRL_SRCS-$(CONFIG_FreeBSD) += xc_freebsd.c xc_freebsd_osdep.c xc_nognttab.c 
xc_nogntshr.c
+CTRL_SRCS-$(CONFIG_SunOS) += xc_solaris.c xc_nognttab.c xc_nogntshr.c
+CTRL_SRCS-$(CONFIG_NetBSD) += xc_netbsd.c xc_nognttab.c xc_nogntshr.c
+CTRL_SRCS-$(CONFIG_NetBSDRump) += xc_netbsd.c xc_nognttab.c xc_nogntshr.c
+CTRL_SRCS-$(CONFIG_MiniOS) += xc_minios.c xc_nogntshr.c
 CTRL_SRCS-y   += xc_evtchn_compat.c
 
 GUEST_SRCS-y :=
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index e4ec52d..3ea939f 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -117,8 +117,8 @@
  */
 
 typedef struct xc_interface_core xc_interface;
-typedef struct xc_interface_core xc_gnttab;
-typedef struct xc_interface_core xc_gntshr;
+typedef struct xengntdev_handle xc_gnttab;
+typedef struct xengntdev_handle xc_gntshr;
 
 enum xc_error_code {
   XC_ERROR_NONE = 0,
diff --git a/tools/libxc/include/xenctrlosdep.h 
b/tools/libxc/include/xenctrlosdep.h
index 89564e1..423660d 100644
--- a/tools/libxc/include/xenctrlosdep.h
+++ b/tools/libxc/include/xenctrlosdep.h
@@ -51,8 +51,6 @@
 
 enum xc_osdep_type {
 XC_OSDEP_PRIVCMD,
-XC_OSDEP_GNTTAB,
-XC_OSDEP_GNTSHR,
 };
 
 /* Opaque handle internal to the backend */
@@ -88,27 +86,6 @@ struct xc_osdep_ops
 size_t chunksize, privcmd_mmap_entry_t 
entries[],
 int nentries);
 } privcmd;
-struct {
-#define XC_GRANT_MAP_SINGLE_DOMAIN 0x1
-void *(*grant_map)(xc_gnttab *xcg, xc_osdep_handle h,
-   uint32_t count, int flags, int prot,
-   uint32_t *domids, uint32_t *refs,
-   uint32_t notify_offset,
-   evtchn_port_t notify_port);
-int (*munmap)(xc_gnttab *xcg, xc_osdep_handle h,
-  void *start_address,
-  uint32_t count);
-int (*set_max_grants)(xc_gnttab *xcg, xc_osdep_handle h, uint32_t 
count);
-} gnttab;
-struct {
-void *(*share_pages)(xc_gntshr *xcg, xc_osdep_handle h,
- uint32_t domid, int count,
- uint32_t *refs, int writable,
- uint32_t notify_offset,
- evtchn_port_t notify_port);
-int (*munmap)(xc_gntshr *xcg, xc_osdep_handle h,
-  void *start_address, uint32_t count);
-} gntshr;
 } u;
 };
 typedef struct xc_osdep_ops xc_osdep_ops;
diff --git a/tools/libxc/xc_gnttab.c b/tools/libxc/xc_gnttab.c
index 60335d8..a51f405 100644
--- a/tools/libxc/xc_gnttab.c
+++ b/tools/libxc/xc_gnttab.c
@@ -143,68 +143,48 @@ grant_entry_v2_t *xc_gnttab_map_table_v2(xc_interface 
*xch, int domid,
 return _gnttab_map_table(xch, domid, gnt_num);
 }
 
-void *xc_gnttab_map_grant_ref(xc_gnttab *xcg,
+void

[Xen-devel] [PATCH QEMU-XEN-TRADITIONAL v4 0/5] Begin to disentangle libxenctrl and provide some stable libraries

We intend to stabilise some parts of the libxenctrl interface by
splitting out some functionality into separate stable libraries.

This is the qemu-xen-traditional part of the first phase of that change.

This mail is (or is intended to be) a reply to a "0/"
super-intro mail covering all of the related patch series and which
contains more details.

Ian Campbell (5):
  qemu-xen-traditional: Use xentoollog as a separate library
  qemu-xen-traditional: Use libxenevtchn
  qemu-xen-traditional: Use libxengnttab
  qemu-xen-traditional: Add libxencall to rpath-link
  qemu-xen-traditional: Add libxenforeignmemory to rpath-link

 hw/xen_backend.c  | 30 +++---
 hw/xen_backend.h  |  4 ++--
 hw/xen_common.h   |  2 ++
 hw/xen_console.c  |  4 ++--
 hw/xen_disk.c | 24 
 i386-dm/helper2.c | 19 ++-
 xen-hooks.mak |  9 +
 7 files changed, 52 insertions(+), 40 deletions(-)

-- 
2.1.4


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

[Xen-devel] [PATCH QEMU-XEN v4 0/9] Begin to disentangle libxenctrl and provide some stable libraries

We intend to stabilise some parts of the libxenctrl interface by
splitting out some functionality into separate stable libraries.

This is the qemu-xen part of the first phase of that change.

This mail is (or is intended to be) a reply to a "0/"
super-intro mail covering all of the related patch series and which
contains more details.

Ian Campbell (9):
  xen_console: correctly cleanup primary console on teardown.
  xen: Switch to libxenevtchn interface for compat shims.
  xen: Switch to libxengnttab interface for compat shims.
  xen: Switch uses of xc_map_foreign_range into xc_map_foreign_bulk
  xen: Switch uses of xc_map_foreign_pages into xc_map_foreign_bulk
  xen: Switch uses of xc_map_foreign_bulk to use libxenforeignmemory
API.
  xen: Use stable library interfaces when they are available.
  xen: domainbuild: reopen libxenctrl interface after forking for domain
watcher.
  xen: make it possible to build without the Xen PV domain builder

 configure|  72 +++
 hw/block/xen_disk.c  |  38 ++--
 hw/char/xen_console.c|  20 +++
 hw/display/xenfb.c   |  22 ---
 hw/net/xen_nic.c |  16 ++---
 hw/xen/xen_backend.c |  44 +++---
 hw/xenpv/Makefile.objs   |   4 +-
 hw/xenpv/xen_domainbuild.c   |   9 ++-
 hw/xenpv/xen_machine_pv.c|  14 +++--
 include/hw/xen/xen_backend.h |   5 +-
 include/hw/xen/xen_common.h  | 135 +--
 xen-common.c |   6 ++
 xen-hvm.c|  53 +
 xen-mapcache.c   |   6 +-
 14 files changed, 309 insertions(+), 135 deletions(-)

-- 
2.1.4


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

[Xen-devel] [PATCH QEMU-XEN v4 1/9] xen_console: correctly cleanup primary console on teardown.

All of the work in con_disconnect applies to the primary console case
(when xendev->dev is NULL). Therefore remove the early check and bail
and allow it to fall through. All of the existing code is correctly
conditional already.

The ->dev and ->gnttabdev handles are either both set or neither. For
consistency with con_initialise() with to the former here too.

With this con_initialise and con_disconnect now mirror each other.

Fix up a hard tab in the function while editing.

Signed-off-by: Ian Campbell 
---
v4: New patch based on feedback to "xen: Switch uses of
xc_map_foreign_bulk to use libxenforeignmemory API."
---
 hw/char/xen_console.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/hw/char/xen_console.c b/hw/char/xen_console.c
index eb7f450..63ade33 100644
--- a/hw/char/xen_console.c
+++ b/hw/char/xen_console.c
@@ -265,9 +265,6 @@ static void con_disconnect(struct XenDevice *xendev)
 {
 struct XenConsole *con = container_of(xendev, struct XenConsole, xendev);
 
-if (!xendev->dev) {
-return;
-}
 if (con->chr) {
 qemu_chr_add_handlers(con->chr, NULL, NULL, NULL, NULL);
 qemu_chr_fe_release(con->chr);
@@ -275,12 +272,12 @@ static void con_disconnect(struct XenDevice *xendev)
 xen_be_unbind_evtchn(>xendev);
 
 if (con->sring) {
-if (!xendev->gnttabdev) {
+if (!xendev->dev) {
 munmap(con->sring, XC_PAGE_SIZE);
 } else {
 xc_gnttab_munmap(xendev->gnttabdev, con->sring, 1);
 }
-   con->sring = NULL;
+con->sring = NULL;
 }
 }
 
-- 
2.1.4


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

[Xen-devel] [PATCH XEN v4 12/23] tools: Implement xc_map_foreign_range(s) in terms of common helper

Both Linux and FreeBSD already implemented these functions using
identical helpers based on xc_map_foreign_pages. Make one copy of
these common helpers and switch all OSes to use them, even those which
previously had a specific lower level implementation of this
functionality.

This is makes two fewer low level interfaces to think about.

Signed-off-by: Ian Campbell 
---
 tools/libxc/xc_foreign_memory.c | 50 +
 tools/libxc/xc_freebsd_osdep.c  | 50 -
 tools/libxc/xc_linux_osdep.c| 49 -
 tools/libxc/xc_minios.c | 43 -
 tools/libxc/xc_netbsd.c | 70 -
 tools/libxc/xc_solaris.c| 67 ---
 6 files changed, 50 insertions(+), 279 deletions(-)

diff --git a/tools/libxc/xc_foreign_memory.c b/tools/libxc/xc_foreign_memory.c
index 2413e75..d1130e6 100644
--- a/tools/libxc/xc_foreign_memory.c
+++ b/tools/libxc/xc_foreign_memory.c
@@ -50,6 +50,56 @@ void *xc_map_foreign_pages(xc_interface *xch, uint32_t dom, 
int prot,
 return res;
 }
 
+void *xc_map_foreign_range(xc_interface *xch,
+   uint32_t dom, int size, int prot,
+   unsigned long mfn)
+{
+xen_pfn_t *arr;
+int num;
+int i;
+void *ret;
+
+num = (size + XC_PAGE_SIZE - 1) >> XC_PAGE_SHIFT;
+arr = calloc(num, sizeof(xen_pfn_t));
+if ( arr == NULL )
+return NULL;
+
+for ( i = 0; i < num; i++ )
+arr[i] = mfn + i;
+
+ret = xc_map_foreign_pages(xch, dom, prot, arr, num);
+free(arr);
+return ret;
+}
+
+void *xc_map_foreign_ranges(xc_interface *xch,
+uint32_t dom, size_t size,
+int prot, size_t chunksize,
+privcmd_mmap_entry_t entries[],
+int nentries)
+{
+xen_pfn_t *arr;
+int num_per_entry;
+int num;
+int i;
+int j;
+void *ret;
+
+num_per_entry = chunksize >> XC_PAGE_SHIFT;
+num = num_per_entry * nentries;
+arr = calloc(num, sizeof(xen_pfn_t));
+if ( arr == NULL )
+return NULL;
+
+for ( i = 0; i < nentries; i++ )
+for ( j = 0; j < num_per_entry; j++ )
+arr[i * num_per_entry + j] = entries[i].mfn + j;
+
+ret = xc_map_foreign_pages(xch, dom, prot, arr, num);
+free(arr);
+return ret;
+}
+
 /*
  * stub for all not yet converted OSes (NetBSD and Solaris). New OSes should
  * just implement xc_map_foreign_bulk.
diff --git a/tools/libxc/xc_freebsd_osdep.c b/tools/libxc/xc_freebsd_osdep.c
index 6b440ee..7745d28 100644
--- a/tools/libxc/xc_freebsd_osdep.c
+++ b/tools/libxc/xc_freebsd_osdep.c
@@ -125,56 +125,6 @@ void *xc_map_foreign_bulk(xc_interface *xch,
 return addr;
 }
 
-void *xc_map_foreign_range(xc_interface *xch,
-   uint32_t dom, int size, int prot,
-   unsigned long mfn)
-{
-xen_pfn_t *arr;
-int num;
-int i;
-void *ret;
-
-num = (size + XC_PAGE_SIZE - 1) >> XC_PAGE_SHIFT;
-arr = calloc(num, sizeof(xen_pfn_t));
-if ( arr == NULL )
-return NULL;
-
-for ( i = 0; i < num; i++ )
-arr[i] = mfn + i;
-
-ret = xc_map_foreign_pages(xch, dom, prot, arr, num);
-free(arr);
-return ret;
-}
-
-void *xc_map_foreign_ranges(xc_interface *xch,
-uint32_t dom, size_t size,
-int prot, size_t chunksize,
-privcmd_mmap_entry_t entries[],
-int nentries)
-{
-xen_pfn_t *arr;
-int num_per_entry;
-int num;
-int i;
-int j;
-void *ret;
-
-num_per_entry = chunksize >> XC_PAGE_SHIFT;
-num = num_per_entry * nentries;
-arr = calloc(num, sizeof(xen_pfn_t));
-if ( arr == NULL )
-return NULL;
-
-for ( i = 0; i < nentries; i++ )
-for ( j = 0; j < num_per_entry; j++ )
-arr[i * num_per_entry + j] = entries[i].mfn + j;
-
-ret = xc_map_foreign_pages(xch, dom, prot, arr, num);
-free(arr);
-return ret;
-}
-
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxc/xc_linux_osdep.c b/tools/libxc/xc_linux_osdep.c
index 1404790..ae1dd9e 100644
--- a/tools/libxc/xc_linux_osdep.c
+++ b/tools/libxc/xc_linux_osdep.c
@@ -284,55 +284,6 @@ void *xc_map_foreign_bulk(xc_interface *xch,
 return addr;
 }
 
-void *xc_map_foreign_range(xc_interface *xch,
-   uint32_t dom, int size, int prot,
-   unsigned long mfn)
-{
-xen_pfn_t *arr;
-int num;
-int i;
-void *ret;
-
-num = (size + XC_PAGE_SIZE - 1) >> XC_PAGE_SHIFT;
-arr = calloc(num, sizeof(xen_pfn_t));
-if ( arr == NULL )
-return NULL;
-
-for ( i = 0; i < num; i++ )
-arr[i] = mfn + i;
-
-ret = xc_map_foreign_pages(xch, dom, prot, arr,

[Xen-devel] [PATCH XEN v4 10/23] tools/libxc: drop xc_map_foreign_bulk_compat wrappers

On Solaris and NetBSD xc_map_foreign_bulk is implemented by calling
xc_map_foreign_bulk_compat and xc_map_foreign_bulk_compat is exposed
as a symbol by libxenctrl.so.

Remove these wrappers and turn the compat function into the real thing
surrounded by the appropriate ifdef.

As this is a compat function all new ports should instead implement
xc_map_foreign_bulk properly, hence the ifdef should never be
expanded.

Signed-off-by: Ian Campbell 
---
 tools/libxc/xc_foreign_memory.c | 13 +
 tools/libxc/xc_netbsd.c |  7 ---
 tools/libxc/xc_private.h|  5 -
 tools/libxc/xc_solaris.c|  7 ---
 4 files changed, 9 insertions(+), 23 deletions(-)

diff --git a/tools/libxc/xc_foreign_memory.c b/tools/libxc/xc_foreign_memory.c
index 9c705b6..b205bca 100644
--- a/tools/libxc/xc_foreign_memory.c
+++ b/tools/libxc/xc_foreign_memory.c
@@ -50,10 +50,14 @@ void *xc_map_foreign_pages(xc_interface *xch, uint32_t dom, 
int prot,
 return res;
 }
 
-/* stub for all not yet converted OSes */
-void *xc_map_foreign_bulk_compat(xc_interface *xch,
- uint32_t dom, int prot,
- const xen_pfn_t *arr, int *err, unsigned int 
num)
+/*
+ * stub for all not yet converted OSes (NetBSD and Solaris). New OSes should
+ * just implement xc_map_foreign_bulk.
+ */
+#if defined(__NetBSD__) || defined(__sun__)
+void *xc_map_foreign_bulk(xc_interface *xch,
+  uint32_t dom, int prot,
+  const xen_pfn_t *arr, int *err, unsigned int num)
 {
 xen_pfn_t *pfn;
 unsigned int i;
@@ -90,6 +94,7 @@ void *xc_map_foreign_bulk_compat(xc_interface *xch,
 
 return ret;
 }
+#endif
 
 /*
  * Local variables:
diff --git a/tools/libxc/xc_netbsd.c b/tools/libxc/xc_netbsd.c
index 5e3b343..d7f7f31 100644
--- a/tools/libxc/xc_netbsd.c
+++ b/tools/libxc/xc_netbsd.c
@@ -67,13 +67,6 @@ int osdep_privcmd_close(xc_interface *xch)
 return close(fd);
 }
 
-void *xc_map_foreign_bulk(xc_interface *xch,
-  uint32_t dom, int prot,
-  const xen_pfn_t *arr, int *err, unsigned int num)
-{
-return xc_map_foreign_bulk_compat(xch, dom, prot, arr, err, num);
-}
-
 void *xc_map_foreign_batch(xc_interface *xch,
uint32_t dom, int prot,
xen_pfn_t *arr, int num)
diff --git a/tools/libxc/xc_private.h b/tools/libxc/xc_private.h
index 3ca9d29..0de907c 100644
--- a/tools/libxc/xc_private.h
+++ b/tools/libxc/xc_private.h
@@ -107,11 +107,6 @@ int osdep_privcmd_close(xc_interface *xch);
 void *osdep_alloc_hypercall_buffer(xc_interface *xch, int npages);
 void osdep_free_hypercall_buffer(xc_interface *xch, void *ptr, int npages);
 
-/* Stub for not yet converted OSes */
-void *xc_map_foreign_bulk_compat(xc_interface *xch,
- uint32_t dom, int prot,
- const xen_pfn_t *arr, int *err, unsigned int 
num);
-
 void xc_report_error(xc_interface *xch, int code, const char *fmt, ...)
 __attribute__((format(printf,3,4)));
 void xc_reportv(xc_interface *xch, xentoollog_logger *lg, xentoollog_level,
diff --git a/tools/libxc/xc_solaris.c b/tools/libxc/xc_solaris.c
index 18622fa..5e72dee 100644
--- a/tools/libxc/xc_solaris.c
+++ b/tools/libxc/xc_solaris.c
@@ -94,13 +94,6 @@ void *xc_map_foreign_batch(xc_interface *xch,
 
 }
 
-void *xc_map_foreign_bulk(xc_interface *xch,
-  uint32_t dom, int prot,
-  const xen_pfn_t *arr, int *err, unsigned int num)
-{
-return xc_map_foreign_bulk_compat(xch, dom, prot, arr, err, num);
-}
-
 void *xc_map_foreign_range(xc_interface *xch,
uint32_t dom,
int size, int prot,
-- 
2.1.4


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

[Xen-devel] [PATCH XEN v4 00/23] Begin to disentangle libxenctrl and provide some stable libraries

We intend to stabilise some parts of the libxenctrl interface by
splitting out some functionality into separate stable libraries.

This is the xen part of the first phase of that change.

This mail is (or is intended to be) a reply to a "0/"
super-intro mail covering all of the related patch series and which
contains more details.

Ian Campbell (23):
  tools/Rules.mk: Properly handle libraries with recursive dependencies.
  tools: Refactor "xentoollog" into its own library
  tools/libxc: Remove osdep indirection for xc_evtchn
  tools: Refactor /dev/xen/evtchn wrappers into libxenevtchn.
  tools: Arrange to check public headers for ANSI compatiblity
  tools/libxc: Remove osdep indirection for xc_gnt{shr,tab}
  tools: Refactor /dev/xen/gnt{dev,shr} wrappers into libxengnttab.
  tools/libxc: Remove osdep indirection for privcmd
  tools: Refactor hypercall calling wrappers into libxencall.
  tools/libxc: drop xc_map_foreign_bulk_compat wrappers
  tools: Remove xc_map_foreign_batch
  tools: Implement xc_map_foreign_range(s) in terms of common helper
  tools: Refactor foreign memory mapping into libxenforeignmemory
  tools: foreignmemory: provide xenforeignmemory_unmap.
  foreignmemory: use size_t for size arguments.
  tools/libs/evtchn: Review and update doc comments.
  tools/libs: Clean up hard tabs.
  tools/libs/gnttab: Review and update doc comments.
  tools/libs/call: Update some log messages to not refer to xc.
  tools/libs/call: Avoid xc_memalign in netbsd and solaris backends
  tools/libs/foreignmemory: Mention restrictions on fork in docs.
  tools: Update CFLAGS for qemu-xen to allow it to use new libraries
  HACK: Update Config.mk to pull all the right bits from my xenbits
trees

 .gitignore |  10 +
 Config.mk  |  18 +-
 config/FreeBSD.mk  |   2 -
 config/NetBSD.mk   |   3 -
 config/NetBSDRump.mk   |   1 -
 config/StdGNU.mk   |   1 -
 config/SunOS.mk|   1 -
 stubdom/Makefile   |  92 ++-
 stubdom/grub/Makefile  |   1 +
 tools/Makefile |  18 +-
 tools/Rules.mk | 124 ++-
 tools/console/Makefile |   3 +-
 tools/console/daemon/io.c  |  64 +-
 tools/console/daemon/utils.c   |   1 -
 tools/console/daemon/utils.h   |   1 +
 tools/libs/Makefile|  11 +
 tools/libs/call/Makefile   |  67 ++
 tools/libs/call/buffer.c   | 192 +
 tools/libs/call/core.c | 144 
 tools/libs/call/freebsd.c  | 140 
 tools/libs/call/include/xencall.h  |  84 ++
 tools/libs/call/libxencall.map |  19 +
 tools/libs/call/linux.c| 132 +++
 tools/libs/call/minios.c   |  81 ++
 tools/libs/call/netbsd.c   | 121 +++
 tools/libs/call/private.h  |  68 ++
 tools/libs/call/solaris.c  |  97 +++
 tools/libs/evtchn/Makefile |  67 ++
 tools/libs/evtchn/core.c   |  69 ++
 tools/libs/evtchn/freebsd.c| 138 
 tools/libs/evtchn/include/xenevtchn.h  | 148 
 tools/libs/evtchn/libxenevtchn.map |  14 +
 tools/libs/evtchn/linux.c  | 136 
 tools/libs/evtchn/minios.c | 266 ++
 tools/libs/evtchn/netbsd.c | 147 
 tools/libs/evtchn/private.h|  25 +
 tools/libs/evtchn/solaris.c| 135 
 tools/libs/foreignmemory/Makefile  |  67 ++
 tools/libs/foreignmemory/compat.c  |  72 ++
 tools/libs/foreignmemory/core.c|  68 ++
 tools/libs/foreignmemory/freebsd.c | 135 
 .../libs/foreignmemory/include/xenforeignmemory.h  |  79 ++
 tools/libs/foreignmemory/libxenforeignmemory.map   |   8 +
 tools/libs/foreignmemory/linux.c   | 294 +++
 tools/libs/foreignmemory/minios.c  |  68 ++
 tools/libs/foreignmemory/netbsd.c  | 111 +++
 tools/libs/foreignmemory/private.h |  47 ++
 tools/libs/foreignmemory/solaris.c | 109 +++
 tools/libs/gnttab/Makefile |  69 ++
 tools/libs/gnttab/gntshr_core.c|  92 +++
 tools/libs/gnttab/gntshr_unimp.c   |  62 ++
 tools/libs/gnttab/gnttab_core.c| 121 +++
 tools/libs/gnttab/gnttab_unimp.c   |  89 ++

Re: [Xen-devel] [linux-4.1 test] 63030: regressions - FAIL

On Wed, Oct 21, 2015 at 05:47:06PM +0100, Ian Campbell wrote:
> On Tue, 2015-10-20 at 16:34 +0100, Ian Jackson wrote:
> > Wei Liu writes ("Re: [Xen-devel] [linux-4.1 test] 63030: regressions 
> > - FAIL"):
> > > From mere code inspection and document of lwip 1.3.0 I think mini
> > -os
> > > does send gratuitous ARP.
> > 
> > The guest is using the PVHVM drivers at this point, with the backend
> > directly in dom0, so it is the guest's gratuitous arp which is needed,
> > I think.
> 
> It would be worth investigating whether mini-os's gratuitous ARP might
> also be occurring and confusing things, e.g. by coming after and
> therefore taking precedence over the one coming from the guest.
> 

Several observations:

1. The guest doesn't always send gratuitous arp -- but this might not be
   the cause of this failure. Guest works fine when using qemu-trad
   only.
2. Guest only sends one gratuitous arp at most.
3. When using stubdom, guest is a lot less responsive. See two
   experiments and analysis below.

I statically add arp entry for guest interface because arp entry some
times gets deleted. Note that this is not covering up the root cause of
failure because  the arp entry is normally deleted after a few migration
iterations. The failure on merlot* mostly fail on first iteration. And
when arp entry is not available, the error for ssh should be "No route
to host", not "timed out".

Furthermore when the arp entry is not available, dom0 naturally sends an
arp request to guest. When stubdom is not in use, guest responded
instantly, when stubdom is in use, guest was a lot less responsive.

I use a script to repeat migration and ssh.

  i=1
  while true; do
  echo " iteration $i"
  ssh localhost xl migrate wheezy-hvm localhost
  if [ $? != 0 ]; then
  echo "migration failed $?";
  exit 1;
  fi 
  timeout 40 ssh -o BatchMode=yes -o ConnectTimeout=100 -o 
ServerAliveInterval=100 root@10.80.239.39 date
  st=$?
  if [ $st != 0 ]; then
  echo "failed $st";
  exit 1;
  fi 
  i=$((i+1))
  done

At the same time
  tcpdump -i xenbr0 arp and host $GUEST_IP

When stubdom is present.

Scenario 1:
  xl shows "Migration successful."
  ...30s...
  xenbr0 receives gratuitous arp
  ...1s...
  ssh date command comes back

Scenario 2:
  xenbr0 receives gratuitous arp
  ...1s...
  xl shows "Migration successful."
  ssh date command comes back

When stubdom was not present I never saw scenario 1.

Note that my machine is relative old (>6 years). It would never pass
the test in osstest because in osstest the timeout is 10s.

The slowness in osstest seems to be host specific because all failures
in guest migrate test failed on merlot*. It's not only linux-4.1 is
failing, other branches fail the same test step on merlot*, too.

Wei.

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

Re: [Xen-devel] xen-netfront crash when detaching network while some network activity

2015-10-21 Thread Marek Marczykowski-Górecki

On Wed, May 27, 2015 at 12:03:12AM +0200, Marek Marczykowski-Górecki wrote:
> On Tue, May 26, 2015 at 11:56:00AM +0100, David Vrabel wrote:
> > On 22/05/15 12:49, Marek Marczykowski-Górecki wrote:
> > > Hi all,
> > > 
> > > I'm experiencing xen-netfront crash when doing xl network-detach while
> > > some network activity is going on at the same time. It happens only when
> > > domU has more than one vcpu. Not sure if this matters, but the backend
> > > is in another domU (not dom0). I'm using Xen 4.2.2. It happens on kernel
> > > 3.9.4 and 4.1-rc1 as well.
> > > 
> > > Steps to reproduce:
> > > 1. Start the domU with some network interface
> > > 2. Call there 'ping -f some-IP'
> > > 3. Call 'xl network-detach NAME 0'
> > 
> > There's a use-after-free in xennet_remove().  Does this patch fix it?
> 
> Unfortunately not. Note that the crash is in xennet_disconnect_backend,
> which is called before xennet_destroy_queues in xennet_remove.
> I've tried to add napi_disable and even netif_napi_del just after
> napi_synchronize in xennet_disconnect_backend (which would probably
> cause crash when trying to cleanup the same later again), but it doesn't
> help - the crash is the same (still in gnttab_end_foreign_access called
> from xennet_disconnect_backend).

Finally I've found some more time to debug this... All tests redone on
v4.3-rc6 frontend and 3.18.17 backend.

Looking at xennet_tx_buf_gc(), I have an impression that shared page
(queue->grant_tx_page[id]) is/should be freed in some other means than
(indirectly) calling to free_page via gnttab_end_foreign_access. Maybe the bug
is that the page _is_ actually freed somewhere else already? At least changing
gnttab_end_foreign_access to gnttab_end_foreign_access_ref makes the crash
gone.

Relevant xennet_tx_buf_gc fragment:
gnttab_end_foreign_access_ref(
queue->grant_tx_ref[id], GNTMAP_readonly);
gnttab_release_grant_reference(
>gref_tx_head, queue->grant_tx_ref[id]);
queue->grant_tx_ref[id] = GRANT_INVALID_REF;
queue->grant_tx_page[id] = NULL;
add_id_to_freelist(>tx_skb_freelist, queue->tx_skbs, id);
dev_kfree_skb_irq(skb);

And similar fragment from xennet_release_tx_bufs:
get_page(queue->grant_tx_page[i]);
gnttab_end_foreign_access(queue->grant_tx_ref[i],
  GNTMAP_readonly,
  (unsigned long)page_address(queue->grant_tx_page[i]));
queue->grant_tx_page[i] = NULL;
queue->grant_tx_ref[i] = GRANT_INVALID_REF;
add_id_to_freelist(>tx_skb_freelist, queue->tx_skbs, i);
dev_kfree_skb_irq(skb);

Note that both have dev_kfree_skb_irq, but the former use
gnttab_end_foreign_access_ref, while the later - gnttab_end_foreign_access.
Also note that the crash is in gnttab_end_foreign_access, so before
dev_kfree_skb_irq. If that would be double free, I'd expect crash in the later.

This change was introduced by cefe007 "xen-netfront: fix resource leak in
netfront". I'm not sure if changing gnttab_end_foreign_access back to
gnttab_end_foreign_access_ref would not (re)introduce some memory leak.

Let me paste again the error message:
[   73.718636] page:ea43b1c0 count:0 mapcount:0 mapping:  
(null) index:0x0
[   73.718661] flags: 0x3ffc008000(tail)
[   73.718684] page dumped because: VM_BUG_ON_PAGE(atomic_read(>_count) 
== 0)
[   73.718725] [ cut here ]
[   73.718743] kernel BUG at include/linux/mm.h:338!

Also it all look quite strange - there is get_page() call just before
gnttab_end_foreign_access, but page->_count is still 0. Maybe it have something
to do how get_page() works on "tail" pages (whatever it means)?

static inline void get_page(struct page *page)
{
if (unlikely(PageTail(page)))
if (likely(__get_page_tail(page)))
return;
/*
 * Getting a normal page or the head of a compound page
 * requires to already have an elevated page->_count.
 */
VM_BUG_ON_PAGE(atomic_read(>_count) <= 0, page);
atomic_inc(>_count);
}

which (I think) ends up in:

static inline void __get_page_tail_foll(struct page *page,
bool get_page_head)
{
/*
 * If we're getting a tail page, the elevated page->_count is
 * required only in the head page and we will elevate the head
 * page->_count and tail page->_mapcount.
 *
 * We elevate page_tail->_mapcount for tail pages to force
 * page_tail->_count to be zero at all times to avoid getting
 * false positives from get_page_unless_zero() with
 * speculative page access (like in
 * page_cache_get_speculative()) on tail pages.
 */
VM_BUG_ON_PAGE(atomic_read(>first_page->_count) <= 0, page);
if (get_page_head)
atomic_inc(>first_page->_count);
get_huge_page_tail(page);
}

So

Re: [Xen-devel] [PATCH v2 3/6] xen: sched: clarify use cases of schedule_cpu_switch()

2015-10-21 Thread Dario Faggioli

On Thu, 2015-10-15 at 10:25 +0200, Juergen Gross wrote:
> Maybe it would be a good idea to move setting of per_cpu(cpupool,
> cpu)
> into schedule_cpu_switch(). Originally I didn't do that to avoid
> spreading too much cpupool related actions outside of cpupool.c. But
> with those ASSERT()s added hiding that action will cause more
> confusion
> than having the modification of per_cpu(cpupool, cpu) here.
> 
Coming back to this.

When reworking the series, I tried to move 'per_cpu(cpupool, cpu)=c' in
schedule_cpu_switch() and, about this part:

> When doing the code movement the current behaviour regarding sequence
> of changes must be kept, of course. So when adding the cpu to a pool
> the cpupool information must be set _before_ taking the scheduler
> lock,
> while when removing this must happen after release of the lock.
> 
I don't think I see why I can't do as in the attached patch (i.e., just
update the cpupool per-cpu variable at the bottom of
schedule_cpu_switch() ).

I don't see anything in the various schedulers' code that relies on
that variable, except one thing in sched_credit.c, which looks safe to
me. And indeed I think that even any future potential code being added
there, should either not depend on it, or do it "safely".

Also, all the operations done in schedule_cpu_switch() itself, depend
either on per_cpu(scheduler) or on per_cpu(schedule_data) being updated
properly, rather than on per_cpu(cpupool) (including the locking that
you are mentioning above).

What am I missing?

Regards,
Dario
---
diff --git a/xen/common/cpupool.c b/xen/common/cpupool.c
index e79850b..8e7b723 100644
--- a/xen/common/cpupool.c
+++ b/xen/common/cpupool.c
@@ -261,19 +261,13 @@ int cpupool_move_domain(struct domain *d, struct cpupool 
*c)
 static int cpupool_assign_cpu_locked(struct cpupool *c, unsigned int cpu)
 {
 int ret;
-struct cpupool *old;
 struct domain *d;
 
 if ( (cpupool_moving_cpu == cpu) && (c != cpupool_cpu_moving) )
 return -EBUSY;
-old = per_cpu(cpupool, cpu);
-per_cpu(cpupool, cpu) = c;
 ret = schedule_cpu_switch(cpu, c);
 if ( ret )
-{
-per_cpu(cpupool, cpu) = old;
 return ret;
-}
 
 cpumask_clear_cpu(cpu, _free_cpus);
 if (cpupool_moving_cpu == cpu)
@@ -326,7 +320,6 @@ static long cpupool_unassign_cpu_helper(void *info)
 cpumask_clear_cpu(cpu, _free_cpus);
 goto out;
 }
-per_cpu(cpupool, cpu) = NULL;
 cpupool_moving_cpu = -1;
 cpupool_put(cpupool_cpu_moving);
 cpupool_cpu_moving = NULL;
diff --git a/xen/common/schedule.c b/xen/common/schedule.c
index d7e2d98..9072540 100644
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -1486,6 +1486,17 @@ void __init scheduler_init(void)
 BUG();
 }
 
+/*
+ * Move a pCPU outside of the influence of the scheduler of its current
+ * cpupool, or subject it to the scheduler of a new cpupool.
+ *
+ * For the pCPUs that are removed from their cpupool, their scheduler becomes
+ *  (the default scheduler, selected at boot, which also services the
+ * default cpupool). However, as these pCPUs are not really part of any pool,
+ * there won't be any scheduling event on them, not even from the default
+ * scheduler. Basically, they will just sit idle until they are explicitly
+ * added back to a cpupool.
+ */
 int schedule_cpu_switch(unsigned int cpu, struct cpupool *c)
 {
 unsigned long flags;
@@ -1494,9 +1505,24 @@ int schedule_cpu_switch(unsigned int cpu, struct cpupool 
*c)
 void *ppriv, *ppriv_old, *vpriv, *vpriv_old;
 struct scheduler *old_ops = per_cpu(scheduler, cpu);
 struct scheduler *new_ops = (c == NULL) ?  : c->sched;
+struct cpupool *old_pool = per_cpu(cpupool, cpu);
+
+/*
+ * pCPUs only move from a valid cpupool to free (i.e., out of any pool),
+ * or from free to a valid cpupool. In the former case (which happens when
+ * c is NULL), we want the CPU to have been marked as free already, as
+ * well as to not be valid for the source pool any longer, when we get to
+ * here. In the latter case (which happens when c is a valid cpupool), we
+ * want the CPU to still be marked as free, as well as to not yet be valid
+ * for the destination pool.
+ */
+ASSERT(c != old_pool && (c != NULL || old_pool != NULL));
+ASSERT(cpumask_test_cpu(cpu, _free_cpus));
+ASSERT((c == NULL && !cpumask_test_cpu(cpu, old_pool->cpu_valid)) ||
+   (c != NULL && !cpumask_test_cpu(cpu, c->cpu_valid)));
 
 if ( old_ops == new_ops )
-return 0;
+goto out;
 
 idle = idle_vcpu[cpu];
 ppriv = SCHED_OP(new_ops, alloc_pdata, cpu);
@@ -1524,6 +1550,9 @@ int schedule_cpu_switch(unsigned int cpu, struct cpupool 
*c)
 SCHED_OP(old_ops, free_vdata, vpriv_old);
 SCHED_OP(old_ops, free_pdata, ppriv_old, cpu);
 
+ out:
+per_cpu(cpupool, cpu) = c;
+
 return 0;
 }
 
-- 
<> (Raistlin Majere)

[Xen-devel] [xen-4.3-testing bisection] complete build-amd64

branch xen-4.3-testing
xen branch xen-4.3-testing
job build-amd64
test xen-build

Tree: qemu git://xenbits.xen.org/staging/qemu-xen-4.3-testing.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-4.3-testing.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  2ddcdd96a0996fe755c6a9ba08182925c57ea412
  Bug not present: 998424e33db121270690586320e899a03c88b4aa


  commit 2ddcdd96a0996fe755c6a9ba08182925c57ea412
  Author: Ian Jackson 
  Date:   Thu Feb 27 17:46:49 2014 +
  
  tools/console: xenconsole tolerate tty errors
  
  Since 28d386fc4341 (XSA-57), libxl writes an empty value for the
  console tty node, with read-only permission for the guest, when
  setting up pv console "frontends".  (The actual tty value is later set
  by xenconsoled.)   Writing an empty node is not strictly necessary to
  stop the frontend from writing dangerous values here, but it is a good
  belt-and-braces approach.
  
  Unfortunately this confuses xenconsole.  It reads the empty value, and
  tries to open it as the tty.  xenconsole then exits.
  
  Fix this by having xenconsole treat an empty value the same way as no
  value at all.
  
  Also, make the error opening the tty be nonfatal: we just print a
  warning, but do not exit.  I think this is helpful in theoretical
  situations where xenconsole is racing with libxl and/or xenconsoled.
  
  Signed-off-by: Ian Jackson 
  Acked-by: Ian Campbell 
  CC: George Dunlap 
  
  ---
  v2: Combine two conditions and move the free
  (cherry picked from commit 39ba2989b10b6a1852e253b204eb010f8e7026f1)
  (cherry picked from commit 7b161be2e51c519754ac4435d63c8fc03db606ec)
  
  Conflicts:
tools/console/client/main.c
  Signed-off-by: Ian Jackson 


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-4.3-testing/build-amd64.xen-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/xen-4.3-testing/build-amd64.xen-build 
--summary-out=tmp/63184.bisection-summary --basis-template=62742 
--blessings=real,real-bisect xen-4.3-testing build-amd64 xen-build
Searching for failure / basis pass:
 63098 fail [host=godello0] / 62742 [host=nocera0] 62392 [host=nocera0] 62208 
[host=nocera0] 62128 [host=nocera0] 62056 [host=nocera0] 61961 [host=nocera0] 
61790 [host=nocera0] 60742 [host=nocera0] 60701 [host=nocera1] 60674 
[host=nocera0] 60151 ok.
Failure / basis pass flights: 63098 / 60151
(tree with no url: seabios)
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-4.3-testing.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-4.3-testing.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 1e5099d596b6f7a977d4bc040a54edc2a6a3c6a4 
b188780861662e8cf1847ec562799b32bb44f05e 
8c5d8c049dad890965124ae4e169e274a693c8fa
Basis pass e1db2596d7c5f8be876481148d407f0cb207b494 
efae5e0f79f77c77720185a0d8a49f3ba49071e7 
d7ab3a1c1cc245dc0683bb937467c27141754053
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/staging/qemu-xen-4.3-testing.git#e1db2596d7c5f8be876481148d407f0cb207b494-1e5099d596b6f7a977d4bc040a54edc2a6a3c6a4
 
git://xenbits.xen.org/staging/qemu-upstream-4.3-testing.git#efae5e0f79f77c77720185a0d8a49f3ba49071e7-b188780861662e8cf1847ec562799b32bb44f05e
 
git://xenbits.xen.org/xen.git#d7ab3a1c1cc245dc0683bb937467c27141754053-8c5d8c049dad890965124ae4e169e274a693c8fa
Loaded 4992 nodes in revision graph
Searching for test results:
 60193 [host=nocera0]
 60151 pass e1db2596d7c5f8be876481148d407f0cb207b494 
efae5e0f79f77c77720185a0d8a49f3ba49071e7 
d7ab3a1c1cc245dc0683bb937467c27141754053
 60394 [host=italia1]
 60674 [host=nocera0]
 60702 [host=nocera1]
 60701 [host=nocera1]
 60737 [host=pinot0]
 60742 [host=nocera0]
 61140 [host=nocera0]
 61790 [host=nocera0]
 61961 [host=nocera0]
 61960 [host=nocera0]
 62128 [host=nocera0]
 62056 [host=nocera0]
 62208 [host=nocera0]
 62307 [host=nocera0]
 62392 [host=nocera0]
 62742 [host=nocera0]
 63150 fail 1e5099d596b6f7a977d4bc040a54edc2a6a3c6a4 
b188780861662e8cf1847ec562799b32bb44f05e 
8c5d8c049dad890965124ae4e169e274a693c8fa
 63098 fail 1e5099d596b6f7a977d4bc040a54edc2a6a3c6a4 
b188780861662e8cf1847ec562799b32bb44f05e 
8c5d8c049dad890965124ae4e169e274a693c8fa
 63143 pass e1db2596d7c5f8be876481148d407f0cb207b494 
efae5e0f79f77c77720185a0d8a49f3ba49071e7 
d7ab3a1c1cc245dc0683bb937467c27141754053
 63154 pass e1db2596d7c5f8be876481148d407f0cb207b494 
20c1b1812de98ed789d55e22a43a4700fb765596 
116bbc6062cd90b98f746c3a058f4ec24347527d
 63160 pass

[Xen-devel] [qemu-mainline baseline-only test] 38185: tolerable FAIL

2015-10-21 Thread Platform Team regression test user

This run is configured for baseline tests only.

flight 38185 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38185/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-xsm  21 guest-start/debian.repeatfail   like 38181
 test-amd64-amd64-xl  21 guest-start/debian.repeatfail   like 38181
 test-amd64-amd64-xl-credit2  21 guest-start/debian.repeatfail   like 38181
 test-amd64-amd64-xl-qemuu-winxpsp3  9 windows-install  fail like 38181

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-midway   12 migrate-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-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd  9 debian-di-installfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass

version targeted for testing:
 qemuu26c7be842637ee65a79cd77f96a99c23ddcd90ad
baseline version:
 qemuu40fe17bea478793fc9106a630fa3610dad51f939

Last test of basis38181  2015-10-20 04:48:23 Z1 days
Testing same since38185  2015-10-21 06:47:20 Z0 days1 attempts


People who touched revisions under test:
  Alex Williamson 
  Alexey Kardashevskiy 
  Andrey Smetanin 
  Andy Whitcroft 
  Christian Borntraeger 
  Daniel P. Berrange 
  Denis V. Lunev 
  Eduardo Habkost 
  Gerd Hoffmann 
  Markus Armbruster 
  Michael S. Tsirkin 
  Nutan Shinde 
  Paolo Bonzini 
  Pavel Fedin 
  Peter Maydell 
  Sair, Umair 
  Sergey Fedorov 
  Stefano Stabellini 
  Thomas Huth 

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

[Xen-devel] Credit scheduler

2015-10-21 Thread Lasya Venneti

Hi,

Can somebody please point me to a resource that talks about scheduler
design for VMs , in contrast with a standard scheduler ( I have consulted
Remzi, Operating Systems for this which is pretty easy to understand
conceptually ). I need to understand the working of the credit scheduler.

Thanks!

Sincerely,
Lasya V
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Dom0 kernel for Xen4.6 on R-Car H2 (LAGER)

2015-10-21 Thread Julien Grall

On 21/10/15 18:20, Ferger, Max wrote:
> Hi!

Hello,

> I'm sorry, but that didn't do the trick.
> Neither did trying, whether a compressed or non-compressed dom0 image would 
> do.
> 
> Also, I tried:
> - 8< -
> /chosen/xen,dom0-bootargs = "console=hvc0 earlyprintk=xen debug 
> ignore_loglevel vmalloc=384M video=HDMI-A-1:1920x1080-32@60 
> ip=192.168.0.5:192.168.0.15:192.168.0.15:255.255.255.0:lager:eth0::: 
> root=/dev/nfs rw nfsroot=192.168.0.15:/nfsroot rootdelay clk_ignore_unused";
> - 8< -
> + earlyprintk=xen
> - rootwait
> + rootdelay
> 
> The log remains the same: empty from the switch to Dom0 onwards.
> 
> Many thanks so far!  Maybe there are some more investigative options to check 
> or try out?

To be sure, even the patch I attached on the previous mail doesn't help
you to get the console?

If so, the simplest way to investigate requires the serial driver in Xen
to be functional (IIRC it's not the case right now). If you got it, you
can type CTRL-a tree times and access to the Xen console.

There is a number of key useful to dump the states of Xen and the
guests. The key '0' will dump the state of every vCPUs of DOM0. To list
the other keys available, type 'h'.

If getting the serial driver requires to much work, you will have to
modify DOM0 and add some xen_raw_printk (#include ).
To figure out what's going on.

If you have Xen built with debug=y, from the log you sent it seems to be
the case, you can use the asm instruction "hvc" to get Xen printing
useful information:
- hvc 0x will dump the state of the vCPU
- hvc 0xfffd will print the program counter
For more of them see do_debug_trap in xen/arch/arm/traps.c

I hope this will help you to get further in DOM0 boot.

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] Dom0 kernel for Xen4.6 on R-Car H2 (LAGER)

2015-10-21 Thread Ferger, Max

Hi!

I'm sorry, but that didn't do the trick.
Neither did trying, whether a compressed or non-compressed dom0 image would do.

Also, I tried:
- 8< -
/chosen/xen,dom0-bootargs = "console=hvc0 earlyprintk=xen debug ignore_loglevel 
vmalloc=384M video=HDMI-A-1:1920x1080-32@60 
ip=192.168.0.5:192.168.0.15:192.168.0.15:255.255.255.0:lager:eth0::: 
root=/dev/nfs rw nfsroot=192.168.0.15:/nfsroot rootdelay clk_ignore_unused";
- 8< -
+ earlyprintk=xen
- rootwait
+ rootdelay

The log remains the same: empty from the switch to Dom0 onwards.

Many thanks so far!  Maybe there are some more investigative options to check 
or try out?

Max Ferger

-Ursprüngliche Nachricht-
Von: Julien Grall [mailto:julien.gr...@citrix.com] 
Gesendet: Mittwoch, 21. Oktober 2015 18:23
An: Ferger, Max ; Ian Campbell ; 
xen-devel@lists.xen.org
Cc: Oleksandr Tyshchenko ; Iurii 
Konovalenko 
Betreff: Re: [Xen-devel] Dom0 kernel for Xen4.6 on R-Car H2 (LAGER)

On 21/10/15 17:05, Ferger, Max wrote:
> Hi!

Hello,

> Thanks for both DT fixes, the "add ranges;", and the "complete memory map".
> 
> Here are some findings:
> 
> * Linus' most recent version of the kernel [1] (configured with a mix of 
> Xen/OMAP description [2] and lager_defconfig [3]) needs the 'add 
> "ranges;"'-fixes, but does not access the otherwise unmapped address regions.
> * Renesas' Yocto/Poky
> 
> Unfortunately, neither gives any message on the console, so I don't know 
> their status.
> 
> [1] git clone 
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> [2] 
> http://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions
> /OMAP5432_uEVM [3] git clone 
> https://github.com/renesas-devel/lager-config
> 
> As I see it, Xen issues no further warnings, but still Dom0 remains silent.

The console parameter in "xen,dom0-bootargs" seems to be wrong.
It should be console=hvc0

If it still doesn't work, you can apply the patch [1] to Linux (it's based on 
the latest version). It will print everything on Xen console even if the HVC 
console is not ready.

> I'm somewhat at a loss.  :-(
> 
> Greetings from Germany!

Regards,


[1]
diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c index 
fa816b7..b57ace0 100644
--- a/drivers/tty/hvc/hvc_xen.c
+++ b/drivers/tty/hvc/hvc_xen.c
@@ -638,7 +638,7 @@ void xen_raw_console_write(const char *str)
ssize_t len = strlen(str);
int rc = 0;
 
-   if (xen_domain()) {
+   if (1 || xen_domain()) {
rc = dom0_write_console(0, str, len);  #ifdef CONFIG_X86
if (rc == -ENOSYS && xen_hvm_domain()) diff --git 
a/kernel/printk/printk.c b/kernel/printk/printk.c index 8f0324e..29a19af 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -1652,6 +1652,8 @@ static size_t cont_print_text(char *text, size_t size)
return textlen;
 }
 
+#include 
+
 asmlinkage int vprintk_emit(int facility, int level,
const char *dict, size_t dictlen,
const char *fmt, va_list args) @@ -1719,6 +1721,7 
@@ asmlinkage int vprintk_emit(int facility, int level,
 * prefix which might be passed-in as a parameter.
 */
text_len = vscnprintf(text, sizeof(textbuf), fmt, args);
+   xen_raw_console_write(text);
 
/* mark and strip a trailing newline */
if (text_len && text[text_len-1] == '\n') {




--
Julien Grall



Leopold KOSTAL GmbH & Co. KG - Sitz Lüdenscheid, Registergericht Iserlohn HRA 
2854, phG Kostal Verwaltungsgesellschaft mbH, Registergericht Iserlohn HRB 4061 
- USt-Id-Nr./Vat No.: DE 125800885
Post- und Werksanschrift: An der Bellmerei 10, D-58513 Lüdenscheid * Telefon: 
+49 2351 16-0 * Telefax: +49 2351 16-2400 Bellmerei
Geschäftsführung: Dipl.-Oec. Andreas Kostal (Vorsitzender), Dipl.-Kfm. Helmut 
Kostal, Dipl.-Ing. Marwin Kinzl, Dr.-Ing. Ludger Laufenberg, Dipl.-Kfm. Ulrich 
Zimmermann


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

[Xen-devel] [xen-4.2-testing bisection] complete build-amd64

branch xen-4.2-testing
xen branch xen-4.2-testing
job build-amd64
test xen-build

Tree: qemu git://xenbits.xen.org/staging/qemu-xen-4.2-testing.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-4.2-testing.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  cb9d2117fae2166375f524967940439e45b08c92
  Bug not present: e4f09370f24a2226125659973655b9bae384f903


  commit cb9d2117fae2166375f524967940439e45b08c92
  Author: Ian Jackson 
  Date:   Thu Feb 27 17:46:49 2014 +
  
  tools/console: xenconsole tolerate tty errors
  
  Since 28d386fc4341 (XSA-57), libxl writes an empty value for the
  console tty node, with read-only permission for the guest, when
  setting up pv console "frontends".  (The actual tty value is later set
  by xenconsoled.)   Writing an empty node is not strictly necessary to
  stop the frontend from writing dangerous values here, but it is a good
  belt-and-braces approach.
  
  Unfortunately this confuses xenconsole.  It reads the empty value, and
  tries to open it as the tty.  xenconsole then exits.
  
  Fix this by having xenconsole treat an empty value the same way as no
  value at all.
  
  Also, make the error opening the tty be nonfatal: we just print a
  warning, but do not exit.  I think this is helpful in theoretical
  situations where xenconsole is racing with libxl and/or xenconsoled.
  
  Signed-off-by: Ian Jackson 
  Acked-by: Ian Campbell 
  CC: George Dunlap 
  
  ---
  v2: Combine two conditions and move the free
  (cherry picked from commit 39ba2989b10b6a1852e253b204eb010f8e7026f1)
  (cherry picked from commit 7b161be2e51c519754ac4435d63c8fc03db606ec)
  
  Conflicts:
tools/console/client/main.c
  Signed-off-by: Ian Jackson 
  (cherry picked from commit 2ddcdd96a0996fe755c6a9ba08182925c57ea412)


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-4.2-testing/build-amd64.xen-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/xen-4.2-testing/build-amd64.xen-build 
--summary-out=tmp/63182.bisection-summary --basis-template=62380 
--blessings=real,real-bisect xen-4.2-testing build-amd64 xen-build
Searching for failure / basis pass:
 63110 fail [host=chardonnay1] / 62380 [host=nocera0] 62285 [host=nocera0] 
62129 [host=nocera0] 61955 [host=nocera1] 61789 [host=nocera1] 60704 
[host=nocera1] 60675 [host=nocera1] 60150 [host=merlot1] 58892 [host=nocera0] 
58855 [host=nocera0] 58833 [host=nocera1] 58824 [host=godello1] 58817 
[host=nocera0] 58800 [host=nocera0] 58783 [host=nocera1] 58757 [host=nocera1] 
58736 [host=nocera1] 58722 [host=nocera0] 58711 [host=godello1] 58678 
[host=godello1] 58631 [host=nocera0] 58540 [host=nocera1] 58460 [host=nocera1] 
58411 [host=nocera1] 57955 [host=nocera0] 57895 [host=nocera0] 57842 
[host=godello0] 57781 [host=rimava1] 57697 [host=nocera1] 57630 [host=nocera1] 
57553 [host=godello0] 57470 [host=nocera1] 57409 [host=nocera1] 53018 
[host=godello0] 52651 [host=italia0] 52620 [host=nocera1] 50412 [host=baroque0] 
50395 [host=godello1] 50375 [host=italia0] 50335 [host=fiano0] 50318 
[host=fiano0] 50288 [host=pinot1] 36512 [host=bush-cricket] 35926 
[host=grain-weevil] 33282 [host=lace-bug] 3322
 7 [host=rice-weevil] 32291 [host=grain-weevil] 32227 [host=gall-mite] 31897 
[host=rice-weevil] 31778 [host=rice-weevil] 31673 [host=bush-cricket] 31630 
[host=bush-cricket] 31592 [host=itch-mite] 31525 [host=bush-cricket] 31476 
[host=grain-weevil] 31461 [host=field-cricket] 31451 [host=field-cricket] 31443 
[host=itch-mite] 31436 [host=grain-weevil] 31432 [host=lace-bug] 31426 
[host=lace-bug] 31406 [host=grain-weevil] 31385 [host=worm-moth] 31335 
[host=worm-moth] 31310 [host=grain-weevil] 31288 [host=scape-moth] 30594 
[host=itch-mite] 30574 [host=field-cricket] 30553 [host=itch-mite] 30536 
[host=scape-moth] 30366 [host=field-cricket] 30094 [host=grain-weevil] 29961 
[host=gall-mite] 29947 [host=gall-mite] 29885 [host=lace-bug] 29846 
[host=field-cricket] 29826 [host=gall-mite] 29808 [host=gall-mite] 29758 
[host=bush-cricket] 29739 [host=field-cricket] 29722 [host=bush-cricket] 29700 
[host=field-cricket] 29687 [host=field-cricket] 29621 [host=gall-mite] 29522 
[host=woodlouse] 28863 [host
 =itch-mite] 27475 [host=bush-cricket] 27462 [host=field-cricket] 27171 
[host=rice-weevil] 27002 [host=rice-weevil] 26982 [host=gall-mite] 26952 
[host=gall-mite] 26490 [host=gall-mite] 26458 [host=gall-mite] 26422 
[host=lace-bug] 26319 [host=lace-bug] 26259 [host=rice-weevil] 26102

Re: [Xen-devel] [PATCH 9/9] treewide: Remove newlines inside DEFINE_PER_CPU() macros

2015-10-21 Thread Michal Marek

Dne 21.10.2015 v 21:27 Prarit Bhargava napsal(a):
> On 10/15/2015 04:16 PM, Michal Marek wrote:
>> Otherwise make tags can't parse them:
>>
>> ctags: Warning: arch/ia64/kernel/smp.c:60: null expansion of name pattern 
>> "\1"
>> ctags: Warning: drivers/xen/events/events_2l.c:41: null expansion of name 
>> pattern "\1"
>> ctags: Warning: drivers/acpi/processor_idle.c:64: null expansion of name 
>> pattern "\1"
>> ctags: Warning: kernel/locking/lockdep.c:153: null expansion of name pattern 
>> "\1"
>> ctags: Warning: kernel/workqueue.c:305: null expansion of name pattern "\1"
>> ctags: Warning: kernel/rcu/rcutorture.c:133: null expansion of name pattern 
>> "\1"
>> ctags: Warning: kernel/rcu/rcutorture.c:135: null expansion of name pattern 
>> "\1"
>> ctags: Warning: net/rds/page.c:45: null expansion of name pattern "\1"
>> ctags: Warning: net/ipv4/syncookies.c:53: null expansion of name pattern "\1"
>> ctags: Warning: net/ipv6/syncookies.c:44: null expansion of name pattern "\1"
> 
> I guarantee you're going to end up fixing this issue over and over again as 
> more
> code is added in.

This is certainly going to happen, but it should be quickly spotted by
anybody running make tags on linux-next. And 10 instances since the
beginning of git is not too many.


> OOC, why not fix ctags to recognize newlines?

It's not ctags itself parsing the DEFINE_PER_CPU() macro, but a
user-supplied regex specified on commandline. Which can only operate on
single lines.

Michal

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

Re: [Xen-devel] [PATCH 9/9] treewide: Remove newlines inside DEFINE_PER_CPU() macros

2015-10-21 Thread Prarit Bhargava

On 10/15/2015 04:16 PM, Michal Marek wrote:
> Otherwise make tags can't parse them:
> 
> ctags: Warning: arch/ia64/kernel/smp.c:60: null expansion of name pattern "\1"
> ctags: Warning: drivers/xen/events/events_2l.c:41: null expansion of name 
> pattern "\1"
> ctags: Warning: drivers/acpi/processor_idle.c:64: null expansion of name 
> pattern "\1"
> ctags: Warning: kernel/locking/lockdep.c:153: null expansion of name pattern 
> "\1"
> ctags: Warning: kernel/workqueue.c:305: null expansion of name pattern "\1"
> ctags: Warning: kernel/rcu/rcutorture.c:133: null expansion of name pattern 
> "\1"
> ctags: Warning: kernel/rcu/rcutorture.c:135: null expansion of name pattern 
> "\1"
> ctags: Warning: net/rds/page.c:45: null expansion of name pattern "\1"
> ctags: Warning: net/ipv4/syncookies.c:53: null expansion of name pattern "\1"
> ctags: Warning: net/ipv6/syncookies.c:44: null expansion of name pattern "\1"
> 
> Cc: linux-i...@vger.kernel.org
> Cc: xen-de...@lists.xenproject.org
> Cc: linux-a...@vger.kernel.org
> Cc: rds-de...@oss.oracle.com
> Cc: net...@vger.kernel.org
> Signed-off-by: Michal Marek 
> ---
>  arch/ia64/kernel/smp.c | 3 +--
>  drivers/acpi/processor_idle.c  | 3 +--
>  drivers/xen/events/events_2l.c | 3 +--
>  kernel/locking/lockdep.c   | 3 +--
>  kernel/rcu/rcutorture.c| 6 ++
>  kernel/workqueue.c | 3 +--
>  net/ipv4/syncookies.c  | 3 +--
>  net/ipv6/syncookies.c  | 3 +--
>  net/rds/page.c | 3 +--
>  9 files changed, 10 insertions(+), 20 deletions(-)
> 
> diff --git a/arch/ia64/kernel/smp.c b/arch/ia64/kernel/smp.c
> index 7f706d4f84f7..1dcfe29d8a42 100644
> --- a/arch/ia64/kernel/smp.c
> +++ b/arch/ia64/kernel/smp.c
> @@ -57,8 +57,7 @@ static struct local_tlb_flush_counts {
>   unsigned int count;
>  } __attribute__((__aligned__(32))) local_tlb_flush_counts[NR_CPUS];
>  
> -static DEFINE_PER_CPU_SHARED_ALIGNED(unsigned short [NR_CPUS],
> -  shadow_flush_counts);
> +static DEFINE_PER_CPU_SHARED_ALIGNED(unsigned short [NR_CPUS], 
> shadow_flush_counts);
>  

I guarantee you're going to end up fixing this issue over and over again as more
code is added in.

OOC, why not fix ctags to recognize newlines?

P.


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

[Xen-devel] [xen-4.3-testing bisection] complete build-armhf

branch xen-4.3-testing
xen branch xen-4.3-testing
job build-armhf
test xen-build

Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-4.3-testing.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  2ddcdd96a0996fe755c6a9ba08182925c57ea412
  Bug not present: 998424e33db121270690586320e899a03c88b4aa


  commit 2ddcdd96a0996fe755c6a9ba08182925c57ea412
  Author: Ian Jackson 
  Date:   Thu Feb 27 17:46:49 2014 +
  
  tools/console: xenconsole tolerate tty errors
  
  Since 28d386fc4341 (XSA-57), libxl writes an empty value for the
  console tty node, with read-only permission for the guest, when
  setting up pv console "frontends".  (The actual tty value is later set
  by xenconsoled.)   Writing an empty node is not strictly necessary to
  stop the frontend from writing dangerous values here, but it is a good
  belt-and-braces approach.
  
  Unfortunately this confuses xenconsole.  It reads the empty value, and
  tries to open it as the tty.  xenconsole then exits.
  
  Fix this by having xenconsole treat an empty value the same way as no
  value at all.
  
  Also, make the error opening the tty be nonfatal: we just print a
  warning, but do not exit.  I think this is helpful in theoretical
  situations where xenconsole is racing with libxl and/or xenconsoled.
  
  Signed-off-by: Ian Jackson 
  Acked-by: Ian Campbell 
  CC: George Dunlap 
  
  ---
  v2: Combine two conditions and move the free
  (cherry picked from commit 39ba2989b10b6a1852e253b204eb010f8e7026f1)
  (cherry picked from commit 7b161be2e51c519754ac4435d63c8fc03db606ec)
  
  Conflicts:
tools/console/client/main.c
  Signed-off-by: Ian Jackson 


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-4.3-testing/build-armhf.xen-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/xen-4.3-testing/build-armhf.xen-build 
--summary-out=tmp/63200.bisection-summary --basis-template=62742 
--blessings=real,real-bisect xen-4.3-testing build-armhf xen-build
Searching for failure / basis pass:
 63098 fail [host=arndale-metrocentre] / 62742 [host=arndale-westfield] 62392 
[host=arndale-lakeside] 62208 [host=arndale-lakeside] 62128 
[host=arndale-westfield] 62056 [host=arndale-westfield] 61961 
[host=arndale-westfield] 61790 [host=arndale-bluewater] 60742 
[host=arndale-westfield] 60701 [host=arndale-bluewater] 60674 
[host=arndale-bluewater] 60151 [host=cubietruck-braque] 58884 
[host=arndale-westfield] 58848 [host=arndale-westfield] 58440 
[host=arndale-westfield] 58404 ok.
Failure / basis pass flights: 63098 / 58404
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-4.3-testing.git
Tree: xen git://xenbits.xen.org/xen.git
Latest b188780861662e8cf1847ec562799b32bb44f05e 
8c5d8c049dad890965124ae4e169e274a693c8fa
Basis pass 447b1c5f24bb942f1b821e6a0e56e743dcffae84 
9176955cb837ba0752ca7ca7a197c9c394468e9f
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/staging/qemu-upstream-4.3-testing.git#447b1c5f24bb942f1b821e6a0e56e743dcffae84-b188780861662e8cf1847ec562799b32bb44f05e
 
git://xenbits.xen.org/xen.git#9176955cb837ba0752ca7ca7a197c9c394468e9f-8c5d8c049dad890965124ae4e169e274a693c8fa
Loaded 2008 nodes in revision graph
Searching for test results:
 58440 [host=arndale-westfield]
 58404 pass 447b1c5f24bb942f1b821e6a0e56e743dcffae84 
9176955cb837ba0752ca7ca7a197c9c394468e9f
 58848 [host=arndale-westfield]
 58884 [host=arndale-westfield]
 60151 [host=cubietruck-braque]
 60674 [host=arndale-bluewater]
 60701 [host=arndale-bluewater]
 60742 [host=arndale-westfield]
 61140 [host=arndale-bluewater]
 61790 [host=arndale-bluewater]
 61961 [host=arndale-westfield]
 62128 [host=arndale-westfield]
 62056 [host=arndale-westfield]
 62208 [host=arndale-lakeside]
 62392 [host=arndale-lakeside]
 62742 [host=arndale-westfield]
 63098 fail b188780861662e8cf1847ec562799b32bb44f05e 
8c5d8c049dad890965124ae4e169e274a693c8fa
 63192 pass a222654ebc3b2292d57e1b48aea2d57340983a6d 
f97021eb92e91db8032d600893a531863a18bd23
 63193 pass b188780861662e8cf1847ec562799b32bb44f05e 
998424e33db121270690586320e899a03c88b4aa
 63195 fail b188780861662e8cf1847ec562799b32bb44f05e 
2ddcdd96a0996fe755c6a9ba08182925c57ea412
 63196 pass b188780861662e8cf1847ec562799b32bb44f05e 
998424e33db121270690586320e899a03c88b4aa
 63197 fail b188780861662e8cf1847ec562799b32bb44f05e 
2ddcdd96a0996fe755c6a9ba08182925c57ea412
 63198 pass b188780861662e8cf1847ec562799b32bb44f05e 
998424e33db121270690586320e899a03c88b4aa
 63200

[Xen-devel] [xen-4.5-testing baseline-only test] 38192: regressions - FAIL

2015-10-21 Thread Platform Team regression test user

This run is configured for baseline tests only.

flight 38192 xen-4.5-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38192/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-pygrub  20 guest-start/debian.repeat fail REGR. vs. 38155
 test-amd64-amd64-amd64-pvgrub 10 guest-start  fail REGR. vs. 38155

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-credit2  21 guest-start/debian.repeatfail   like 38155
 test-amd64-amd64-xl-rtds  6 xen-boot fail   like 38155
 test-amd64-amd64-xl-qemuu-winxpsp3  9 windows-install  fail like 38155

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-rumpuserxen-amd64 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass

version targeted for testing:
 xen  80e9f5624f9d1ef2e7bbd9b9b185e96b45e1bb17
baseline version:
 xen  db0f474646878b0e91fd14f53eec6adcacc4b5ba

Last test of basis38155  2015-10-11 21:34:32 Z   10 days
Testing same since38192  2015-10-21 15:18:05 Z0 days1 attempts


People who touched revisions under test:
  Anthony PERARD 
  George Dunlap 
  Ian Campbell 
  Wei Liu 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  pass
 build-i386-rumpuserxen   pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-xl-pvh-amd  fail
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64pass
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64

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

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start.2fail blocked in 63086

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

version targeted for testing:
 qemuu426c0df9e3e6e64c7ea489092c57088ca4d227d0
baseline version:
 qemuu26c7be842637ee65a79cd77f96a99c23ddcd90ad

Last test of basis63086  2015-10-20 04:28:44 Z1 days
Testing same since63117  2015-10-21 13:12:41 Z0 days1 attempts


People who touched revisions under test:
  Benjamin Herrenschmidt 
  Daniel P. Berrange 
  Denis V. Lunev 
  Gabriel L. Somlo 
  Gabriel Somlo 
  Gerd Hoffmann 
  Kevin O'Connor 
  Marc MarÃ 
  Marc-AndrÃ© Lureau 
  Markus Armbruster 
  Michael Roth 
  Peter Maydell 
  Yuri Pudgorodskiy 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass

[Xen-devel] [xen-4.5-testing test] 63099: tolerable FAIL - PUSHED

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail REGR. vs. 
62802
 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate.2fail like 62726
 test-armhf-armhf-xl-rtds 11 guest-start  fail   like 62756
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail like 62802
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 62802

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-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-xl-qemut-win7-amd64 17 guest-stop fail never pass

version targeted for testing:
 xen  80e9f5624f9d1ef2e7bbd9b9b185e96b45e1bb17
baseline version:
 xen  db0f474646878b0e91fd14f53eec6adcacc4b5ba

Last test of basis62802  2015-10-11 00:33:03 Z   10 days
Testing same since63099  2015-10-20 17:40:41 Z0 days1 attempts


People who touched revisions under test:
  Anthony PERARD 
  George Dunlap 
  Ian Campbell 
  Wei Liu 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  pass
 build-i386-rumpuserxen   pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-xl-pvh-amd  fail
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64pass
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-rumpuserxen-amd64   pass
 test-amd64-amd64-xl-qemut-win7-amd64 fail
 test-amd64-i386-xl-qemut-win7-amd64  fail

Re: [Xen-devel] [PATCH v4 2/3] xen, cpu_hotplug: call device_offline instead of cpu_down

2015-10-21 Thread Boris Ostrovsky


On 10/21/2015 07:53 AM, Stefano Stabellini wrote:

When offlining a cpu, instead of cpu_down, call device_offline, which
also takes care of updating the cpu.dev.offline field. This keeps the
sysfs file /sys/devices/system/cpu/cpuN/online, up to date.  Also move
the call to disable_hotplug_cpu, because it makes more sense to have it
there.

We don't call device_online at cpu-hotplug time, because that would
immediately take the cpu online, while we want to retain the current
behaviour: the user needs to explicitly enable the cpu after it has
been hotplugged.

Signed-off-by: Stefano Stabellini 
CC: konrad.w...@oracle.com
CC: boris.ostrov...@oracle.com
CC: david.vra...@citrix.com


Reviewed-by: Boris Ostrovsky 


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

Re: [Xen-devel] [PATCH v4 1/3] xen/arm: Enable cpu_hotplug.c

CC'ing few more x86 people as it contains a few x86 changes.

If you are OK with this, I'll go ahead and apply the series to
xentip/for-linus-4.4.

On Wed, 21 Oct 2015, Stefano Stabellini wrote:
> Build cpu_hotplug for ARM and ARM64 guests.
> 
> Rename arch_(un)register_cpu to xen_(un)register_cpu and provide an
> empty implementation on ARM and ARM64. On x86 just call
> arch_(un)register_cpu as we are already doing.
> 
> Initialize cpu_hotplug on ARM.
> 
> Signed-off-by: Stefano Stabellini 
> Reviewed-by: Julien Grall 
> 
> ---
> 
> Changes in v2:
> - don't initialize if not a xen_domain() on arm
> - protect xen_arch_(un)register_cpu with ifdef CONFIG_HOTPLUG_CPU on arm
> ---
>  arch/arm/include/asm/xen/hypervisor.h |   10 ++
>  arch/x86/include/asm/xen/hypervisor.h |5 +
>  arch/x86/xen/enlighten.c  |   15 +++
>  drivers/xen/Makefile  |2 --
>  drivers/xen/cpu_hotplug.c |8 ++--
>  5 files changed, 36 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/include/asm/xen/hypervisor.h 
> b/arch/arm/include/asm/xen/hypervisor.h
> index 04ff8e7..9525151 100644
> --- a/arch/arm/include/asm/xen/hypervisor.h
> +++ b/arch/arm/include/asm/xen/hypervisor.h
> @@ -26,4 +26,14 @@ void __init xen_early_init(void);
>  static inline void xen_early_init(void) { return; }
>  #endif
>  
> +#ifdef CONFIG_HOTPLUG_CPU
> +static inline void xen_arch_register_cpu(int num)
> +{
> +}
> +
> +static inline void xen_arch_unregister_cpu(int num)
> +{
> +}
> +#endif
> +
>  #endif /* _ASM_ARM_XEN_HYPERVISOR_H */
> diff --git a/arch/x86/include/asm/xen/hypervisor.h 
> b/arch/x86/include/asm/xen/hypervisor.h
> index d866959..8b2d4be 100644
> --- a/arch/x86/include/asm/xen/hypervisor.h
> +++ b/arch/x86/include/asm/xen/hypervisor.h
> @@ -57,4 +57,9 @@ static inline bool xen_x2apic_para_available(void)
>  }
>  #endif
>  
> +#ifdef CONFIG_HOTPLUG_CPU
> +void xen_arch_register_cpu(int num);
> +void xen_arch_unregister_cpu(int num);
> +#endif
> +
>  #endif /* _ASM_X86_XEN_HYPERVISOR_H */
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index 11d6fb4..ba62d8e 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -71,6 +71,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #ifdef CONFIG_ACPI
>  #include 
> @@ -1868,3 +1869,17 @@ const struct hypervisor_x86 x86_hyper_xen = {
>   .set_cpu_features   = xen_set_cpu_features,
>  };
>  EXPORT_SYMBOL(x86_hyper_xen);
> +
> +#ifdef CONFIG_HOTPLUG_CPU
> +void xen_arch_register_cpu(int num)
> +{
> + arch_register_cpu(num);
> +}
> +EXPORT_SYMBOL(xen_arch_register_cpu);
> +
> +void xen_arch_unregister_cpu(int num)
> +{
> + arch_unregister_cpu(num);
> +}
> +EXPORT_SYMBOL(xen_arch_unregister_cpu);
> +#endif
> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> index e293bc5..aa8a7f7 100644
> --- a/drivers/xen/Makefile
> +++ b/drivers/xen/Makefile
> @@ -1,6 +1,4 @@
> -ifeq ($(filter y, $(CONFIG_ARM) $(CONFIG_ARM64)),)
>  obj-$(CONFIG_HOTPLUG_CPU)+= cpu_hotplug.o
> -endif
>  obj-$(CONFIG_X86)+= fallback.o
>  obj-y+= grant-table.o features.o balloon.o manage.o preempt.o
>  obj-y+= events/
> diff --git a/drivers/xen/cpu_hotplug.c b/drivers/xen/cpu_hotplug.c
> index cc6513a..43de1f5 100644
> --- a/drivers/xen/cpu_hotplug.c
> +++ b/drivers/xen/cpu_hotplug.c
> @@ -11,7 +11,7 @@
>  static void enable_hotplug_cpu(int cpu)
>  {
>   if (!cpu_present(cpu))
> - arch_register_cpu(cpu);
> + xen_arch_register_cpu(cpu);
>  
>   set_cpu_present(cpu, true);
>  }
> @@ -19,7 +19,7 @@ static void enable_hotplug_cpu(int cpu)
>  static void disable_hotplug_cpu(int cpu)
>  {
>   if (cpu_present(cpu))
> - arch_unregister_cpu(cpu);
> + xen_arch_unregister_cpu(cpu);
>  
>   set_cpu_present(cpu, false);
>  }
> @@ -102,7 +102,11 @@ static int __init setup_vcpu_hotplug_event(void)
>   static struct notifier_block xsn_cpu = {
>   .notifier_call = setup_cpu_watcher };
>  
> +#ifdef CONFIG_X86
>   if (!xen_pv_domain())
> +#else
> + if (!xen_domain())
> +#endif
>   return -ENODEV;
>  
>   register_xenstore_notifier(_cpu);
> -- 
> 1.7.10.4
> 

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

Re: [Xen-devel] [qemu-mainline test] 63108: trouble: preparing/queued

On Wed, 2015-10-21 at 12:48 +, osstest service owner wrote:
> flight 63108 qemu-mainline running [real]
> http://logs.test-lab.xenproject.org/osstest/logs/63108/
> 
> Failures and problems with tests :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-amd64-xl-pvh-amd   queued

I missed this branch when dropping stop files prior to implementing the
single qemu git repo changes, hence I killed it.

Ian.


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

[Xen-devel] [PATCH] libxl: make libxl_vncviewer_exec work with stubdom

The xenstore path to look at when stubdom is in used is different. Libxl
should look at stubdom path instead.

Signed-off-by: Wei Liu 
---
 tools/libxl/libxl.c | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 22bbc29..fb98043 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1921,6 +1921,7 @@ int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, 
int autopass)
 GC_INIT(ctx);
 const char *vnc_port;
 const char *vnc_listen = NULL, *vnc_pass = NULL;
+uint32_t stubdom_id, vnc_domid = domid;
 int port = 0, autopass_fd = -1;
 char *vnc_bin, *args[] = {
 "vncviewer",
@@ -1929,11 +1930,19 @@ int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t 
domid, int autopass)
 NULL,
 };
 
+stubdom_id = libxl_get_stubdom_id(ctx, domid);
+if (stubdom_id != 0)
+vnc_domid = stubdom_id;
+
 vnc_port = libxl__xs_read(gc, XBT_NULL,
 libxl__sprintf(gc,
-"/local/domain/%d/console/vnc-port", domid));
+"/local/domain/%d/console/vnc-port", vnc_domid));
 if (!vnc_port) {
-LOG(ERROR, "Cannot get vnc-port of domain %d", domid);
+if (stubdom_id != 0)
+LOG(ERROR, "Cannot get vnc-port of domain %d (stubdom %d)",
+domid, stubdom_id);
+else
+LOG(ERROR, "Cannot get vnc-port of domain %d", domid);
 goto x_fail;
 }
 
@@ -1941,12 +1950,12 @@ int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t 
domid, int autopass)
 
 vnc_listen = libxl__xs_read(gc, XBT_NULL,
 libxl__sprintf(gc,
-"/local/domain/%d/console/vnc-listen", domid));
+"/local/domain/%d/console/vnc-listen", vnc_domid));
 
 if ( autopass )
 vnc_pass = libxl__xs_read(gc, XBT_NULL,
   libxl__sprintf(gc,
-"/local/domain/%d/console/vnc-pass", domid));
+"/local/domain/%d/console/vnc-pass", vnc_domid));
 
 if ( NULL == vnc_listen )
 vnc_listen = "localhost";
-- 
2.1.4


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

Re: [Xen-devel] [PATCH OSSTEST] Switch to merged qemu-xen{, -traditional}.git trees

On Tue, 2015-10-20 at 11:34 +0100, Ian Campbell wrote:
> On Mon, 2015-10-19 at 12:44 +0100, Ian Jackson wrote:
> > Ian Campbell writes ("Re: [PATCH OSSTEST] Switch to merged qemu-xen{,
> > -traditional}.git trees"):
> > > We discussed on IRC with you and Stefano and are going to aim to push
> > > this
> > > in the w/c 19 October.
> > 
> > We have decided under the circumstances to postpone this to next week.
> > 
> > It would probably have been possible for me to pick things up from
> > the deployment plan in your mail
> >[PATCH OSSTEST+XEN 0/1+1] Switching to one qemu tree per qemu
> > version
> > (trad vs upstream)
> > But it seems better to wait for you to be back.
> 
> That was probably wise, although I'm on vacation next week.
> 
> I thought maybe I'd be able to manage it today given the existence of the
> checklist, but I think actually I'm too fuzzy headed even for that.
> 
> I made some updates to the plan last week, see below.
> 
> Ian.
> 
> 
>  * Today we can already just remove the old staging/qemu-xen-* trees, they
>are unused (apart from being manually pushed to along with the staging
>trees, I think).

I have interpreted remove here (and everywhere else) as "move to
~xen/git.single-qemu.deleteme".

I did however delete the corresponding symlinks from /var/xenbits
-www/html/git-http/

>  * Move the two new trees out of people/ianc into the correct places.
>Ensure git-http etc all works and that Stefano + IanJ have appropriate
>permissions.

Appropriate permissions == owned by xen:xenmaint and g+s set for the
directories.

Also, in *.git/config:
[receive]
denyNonFastForwards = true
unpackLimit = 1
[gc]
autopacklimit = 25

Copied from xen.git/config. I also copied xen.git/hooks/pre-receive which
prevents pushes to non-staging branches (except by osstest) and prevents
pushes of unannottated tags.

I also in both cases moved hooks/post-update.sample to hooks/post-update,
which runs update-server-info. I then ran this by hand in both repos.

I also updated config/description of new and old trees.

I also edited ~xen/HG/patchbot/versions to add the appropriate lines for
all the new branches. That is I removed them and added:

/home/xen/git qemu-xen.git#master   
xen-change...@lists.xensource.com   xen-de...@lists.xensource.com
/home/xen/git qemu-xen.git#stable-4.6   
xen-change...@lists.xensource.com   xen-de...@lists.xensource.com
[...]
/home/xen/git qemu-xen.git#stable-4.2   
xen-change...@lists.xensource.com   xen-de...@lists.xensource.com
/home/xen/git qemu-xen-traditional.git#master   
xen-change...@lists.xensource.com   xen-de...@lists.xensource.com
/home/xen/git qemu-xen-traditional.git#stable-4.6   
xen-change...@lists.xensource.com   xen-de...@lists.xensource.com
[...]
/home/xen/git qemu-xen-traditional.git#stable-3.3   
xen-change...@lists.xensource.com   xen-de...@lists.xensource.com

and

/home/xen/git qemu-xen.git#staging  xen-stag...@lists.xensource.com 
xen-de...@lists.xensource.com
/home/xen/git qemu-xen.git#staging-4.6  xen-stag...@lists.xensource.com 
xen-de...@lists.xensource.com
[...]
/home/xen/git qemu-xen.git#staging-4.2  xen-stag...@lists.xensource.com 
xen-de...@lists.xensource.com
/home/xen/git qemu-xen-traditional.git#staging  
xen-stag...@lists.xensource.com xen-de...@lists.xensource.com
/home/xen/git qemu-xen-traditional.git#staging-4.6  
xen-stag...@lists.xensource.com xen-de...@lists.xensource.com
[...]
/home/xen/git qemu-xen-traditional.git#staging-3.3  
xen-stag...@lists.xensource.com xen-de...@lists.xensource.com

This follows the pattern for the existing xen.git and old qemu ones, which
I've removed.

I also did moved ~xen/HG/patchbot/qemu-* to ~xen/git.single-qemu.deleteme/
_after_ having made a botched attempt to rename them appropriately for the
new scheme.

To unbotch it I regenerated from scratch for qemu-xen-traditional:

$ for i in master stable-3.{3,4} stable-4.{0,1,2,3,4,5,6} ; do r=$(git 
rev-parse $i); echo "echo $r > 
qemu-xen-traditional--$i.patchbot-reported-heads" ; done
echo bc00cad75d8bcc3ba696992bec219c21db8406aa > 
qemu-xen-traditional--master.patchbot-reported-heads
echo f3115dc6719e4d21c426b9395b2b30e7062b97cf > 
qemu-xen-traditional--stable-3.3.patchbot-reported-heads
echo 62539a7d5974cdc0a448d469cda458761940cd33 > 
qemu-xen-traditional--stable-3.4.patchbot-reported-heads
echo eaa1bd612f50d2f253738ed19e14981e4ede98a5 > 
qemu-xen-traditional--stable-4.0.patchbot-reported-heads
echo 77d9bdb27c4237a007ba93a6f159791eed317abc > 
qemu-xen-traditional--stable-4.1.patchbot-reported-heads
echo 112599882987da1afbbe4c16f6b049065a64f065 > 
qemu-xen-traditional--stable-4.2.patchbot-reported-heads
echo 1e5099d596b6f7a977d4bc040a54edc2a6a3c6a4 > 
qemu-xen-traditional--stable-4.3.patchbot-reported-heads

[Xen-devel] [ANNOUNCE] Switching to qemu-xen.git and qemu-xen-traditional.git