[Qemu-commits] [qemu/qemu] 549e9b: xen_console: correctly cleanup primary console on ...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: 549e9bcabc2f5b37b0be8c24257e0b527bffb49a
      
https://github.com/qemu/qemu/commit/549e9bcabc2f5b37b0be8c24257e0b527bffb49a
  Author: Ian Campbell <address@hidden>
  Date:   2016-01-26 (Tue, 26 Jan 2016)

  Changed paths:
    M hw/char/xen_console.c

  Log Message:
  -----------
  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 <address@hidden>
Reviewed-by: Stefano Stabellini <address@hidden>
Signed-off-by: Stefano Stabellini <address@hidden>


  Commit: a2db2a1edd06a50b8a862c654cf993368cf9f1d9
      
https://github.com/qemu/qemu/commit/a2db2a1edd06a50b8a862c654cf993368cf9f1d9
  Author: Ian Campbell <address@hidden>
  Date:   2016-01-26 (Tue, 26 Jan 2016)

  Changed paths:
    M hw/xen/xen_backend.c
    M include/hw/xen/xen_backend.h
    M include/hw/xen/xen_common.h
    M xen-hvm.c

  Log Message:
  -----------
  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.

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 <address@hidden>
Reviewed-by: Stefano Stabellini <address@hidden>
Signed-off-by: Stefano Stabellini <address@hidden>


  Commit: c1345a88785b50ba2bf5e87b83c7e22f6b4ec83d
      
https://github.com/qemu/qemu/commit/c1345a88785b50ba2bf5e87b83c7e22f6b4ec83d
  Author: Ian Campbell <address@hidden>
  Date:   2016-01-26 (Tue, 26 Jan 2016)

  Changed paths:
    M hw/block/xen_disk.c
    M hw/char/xen_console.c
    M hw/net/xen_nic.c
    M hw/xen/xen_backend.c
    M include/hw/xen/xen_backend.h
    M include/hw/xen/xen_common.h

  Log Message:
  -----------
  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.

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

Signed-off-by: Ian Campbell <address@hidden>
Reviewed-by: Stefano Stabellini <address@hidden>
Signed-off-by: Stefano Stabellini <address@hidden>


  Commit: 9ed257d1d1c65dbe5a08f207e5106e98384e1860
      
https://github.com/qemu/qemu/commit/9ed257d1d1c65dbe5a08f207e5106e98384e1860
  Author: Ian Campbell <address@hidden>
  Date:   2016-01-26 (Tue, 26 Jan 2016)

  Changed paths:
    M hw/char/xen_console.c
    M hw/display/xenfb.c
    M xen-hvm.c

  Log Message:
  -----------
  xen: Switch uses of xc_map_foreign_range into xc_map_foreign_pages

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_{pages,bulk}.

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

  * Pass &mfn (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.
  * 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*.

In xenfb.c:common_bind we now explicitly launder the mfn into a
xen_pfn_t, so it has the correct type to be passed to
xc_map_foreign_pages and doesn't provoke warnings on 32-bit x86.

Signed-off-by: Ian Campbell <address@hidden>
Reviewed-by: Stefano Stabellini <address@hidden>
Signed-off-by: Stefano Stabellini <address@hidden>


  Commit: e0cb42ae4bc4438ba4ec0760df2d830b8759b255
      
https://github.com/qemu/qemu/commit/e0cb42ae4bc4438ba4ec0760df2d830b8759b255
  Author: Ian Campbell <address@hidden>
  Date:   2016-01-26 (Tue, 26 Jan 2016)

  Changed paths:
    M hw/char/xen_console.c
    M hw/display/xenfb.c
    M hw/xen/xen_backend.c
    M include/hw/xen/xen_backend.h
    M include/hw/xen/xen_common.h
    M xen-common.c
    M xen-hvm.c
    M xen-mapcache.c

  Log Message:
  -----------
  xen: Switch uses of xc_map_foreign_{pages,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_{pages,bulk}.

The new xenforeignmemory_map() function behaves like
xc_map_foreign_pages() when the err argument is NULL and like
xc_map_foreign_bulk() when err is non-NULL, which maps into the shim
here onto checking err == NULL and calling the appropriate old
function.

Note that xenforeignmemory_map() takes the number of pages before the
arrays themselves, in order to support potentially future use of
variable-length-arrays in the prototype (in the future, when Xen's
baseline toolchain requirements are new enough to ensure VLAs are
supported).

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

Signed-off-by: Ian Campbell <address@hidden>
Reviewed-by: Stefano Stabellini <address@hidden>
Signed-off-by: Stefano Stabellini <address@hidden>


  Commit: 5eeb39c24b7d4da5d129bfdd9c4fd21cfb3d28d6
      
https://github.com/qemu/qemu/commit/5eeb39c24b7d4da5d129bfdd9c4fd21cfb3d28d6
  Author: Ian Campbell <address@hidden>
  Date:   2016-01-26 (Tue, 26 Jan 2016)

  Changed paths:
    M configure
    M include/hw/xen/xen_common.h

  Log Message:
  -----------
  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.6 (inclusive) and the patches targetting
4.7 which adds these libraries.

This uses CONFIG_XEN_CTRL_INTERFACE_VERSION == 471 to cover the
introduction of these new interfaces.

Signed-off-by: Ian Campbell <address@hidden>
Reviewed-by: Stefano Stabellini <address@hidden>
Signed-off-by: Stefano Stabellini <address@hidden>


  Commit: 228df5c91c87d98383f02ee07bbfdc001ba0ab0f
      
https://github.com/qemu/qemu/commit/228df5c91c87d98383f02ee07bbfdc001ba0ab0f
  Author: Ian Campbell <address@hidden>
  Date:   2016-01-26 (Tue, 26 Jan 2016)

  Changed paths:
    M hw/xenpv/xen_domainbuild.c
    M include/hw/xen/xen_common.h

  Log Message:
  -----------
  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 <address@hidden>
Acked-by: Stefano Stabellini <address@hidden>
Signed-off-by: Stefano Stabellini <address@hidden>


  Commit: 64a7ad6fe3d8500119d83e0af830e0e45e83499a
      
https://github.com/qemu/qemu/commit/64a7ad6fe3d8500119d83e0af830e0e45e83499a
  Author: Ian Campbell <address@hidden>
  Date:   2016-01-26 (Tue, 26 Jan 2016)

  Changed paths:
    M configure
    M hw/xenpv/Makefile.objs
    M hw/xenpv/xen_machine_pv.c
    M include/hw/xen/xen_common.h

  Log Message:
  -----------
  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 <address@hidden>
Reviewed-by: Stefano Stabellini <address@hidden>
Signed-off-by: Stefano Stabellini <address@hidden>


  Commit: 39c36a0573d9307d68c0c3336b48e6351ffabc06
      
https://github.com/qemu/qemu/commit/39c36a0573d9307d68c0c3336b48e6351ffabc06
  Author: Peter Maydell <address@hidden>
  Date:   2016-01-26 (Tue, 26 Jan 2016)

  Changed paths:
    M configure
    M hw/block/xen_disk.c
    M hw/char/xen_console.c
    M hw/display/xenfb.c
    M hw/net/xen_nic.c
    M hw/xen/xen_backend.c
    M hw/xenpv/Makefile.objs
    M hw/xenpv/xen_domainbuild.c
    M hw/xenpv/xen_machine_pv.c
    M include/hw/xen/xen_backend.h
    M include/hw/xen/xen_common.h
    M xen-common.c
    M xen-hvm.c
    M xen-mapcache.c

  Log Message:
  -----------
  Merge remote-tracking branch 'remotes/sstabellini/tags/xen-20160126-2' into 
staging

Xen 2016/01/26 with Signed-off-by lines.

# gpg: Signature made Tue 26 Jan 2016 17:20:12 GMT using RSA key ID 70E1AE90
# gpg: Good signature from "Stefano Stabellini <address@hidden>"

* remotes/sstabellini/tags/xen-20160126-2:
  xen: make it possible to build without the Xen PV domain builder
  xen: domainbuild: reopen libxenctrl interface after forking for domain 
watcher.
  xen: Use stable library interfaces when they are available.
  xen: Switch uses of xc_map_foreign_{pages,bulk} to use libxenforeignmemory 
API.
  xen: Switch uses of xc_map_foreign_range into xc_map_foreign_pages
  xen: Switch to libxengnttab interface for compat shims.
  xen: Switch to libxenevtchn interface for compat shims.
  xen_console: correctly cleanup primary console on teardown.

Signed-off-by: Peter Maydell <address@hidden>


Compare: https://github.com/qemu/qemu/compare/ba3fb2f02325...39c36a0573d9