Log message:
apply fixes from upstream for
XSA-125 Long latency MMIO mapping operations are not preemptible
XSA-126 Unmediated PCI command register access in qemu

Log message:
xsa119-unstable.patch from upstream:

By default qemu will try to create some sort of backend for the
emulated VGA device, either SDL or VNC.

However when the user specifies sdl=0 and vnc=0 in their configuration
libxl was not explicitly disabling either backend, which could lead to
one unexpectedly running.

If either sdl=1 or vnc=1 is configured then both before and after this
change only the backends which are explicitly enabled are configured,
i.e. this issue only occurs when all backends are supposed to have
been disabled.

This affects qemu-xen and qemu-xen-traditional differently.

If qemu-xen was compiled with SDL support then this would result in an
SDL window being opened if $DISPLAY is valid, or a failure to start
the guest if not. Passing "-display none" to qemu before any further
-sdl options disables this default behaviour and ensures that SDL is
only started if the libxl configuration demands it.

If qemu-xen was compiled without SDL support then qemu would instead
start a VNC server listening on ::1 (IPv6 localhost) or 127.0.0.1
(IPv4 localhost) with IPv6 preferred if available. Explicitly pass
"-vnc none" when vnc is not enabled in the libxl configuration to
remove this possibility.

qemu-xen-traditional would never start a vnc backend unless asked.
However by default it will start an SDL backend, the way to disable
this is to pass a -vnc option. In other words passing "-vnc none" will
disable both vnc and sdl by default. sdl can then be reenabled if
configured by subsequent use of the -sdl option.

Tested with both qemu-xen and qemu-xen-traditional built with SDL
support and:
        xl cr # defaults
        xl cr sdl=0 vnc=0
        xl cr sdl=1 vnc=0
        xl cr sdl=0 vnc=1
        xl cr sdl=0 vnc=0 vga=\"none\"
        xl cr sdl=0 vnc=0 nographic=1
with both valid and invalid $DISPLAY.

This is XSA-119.

Log message:
Fix build with clang and on NetBSD/current.

Log message:
xen build with python 3.3 fails with:

xenkernel45:
  File "/tmp/pkgsrc/sysutils/xenkernel45/work.x86_64/xen-4.5.0/xen/tools/compat-
build-source.py", line 30
    print line.rstrip()
             ^
SyntaxError: invalid syntax

xentools45:
  File "mkchecker.py", line 40, in <module>
    if compat_arches.has_key(a):
AttributeError: 'dict' object has no attribute 'has_key'
...

XXX Assume the same is true for python 3.4 and mark as not for 33 34

Log message:
Just because it is a new xentools version, don't expect the horrible
dynamic type mess is fixed.

Log message:
Make it build on netbsd-7.
Remove dependancy on py-curses and py-xml now that the xm toolstack is gone.
Bump PKGREVISION

Log message:
Remove outdated file inherited from xentools42

Log message:
Xen is a virtual machine monitor which supports running multiple
guests operating systems on a single machine. Guest OSes (also
called "domains") require a modified kernel which supports Xen
hypercalls in replacement to access to the physical hardware. At
boot, the xen kernel is loaded along with the guest kernel for the
first domain (called domain0). domain0 has privileges to access
the physical hardware (PCI and ISA devices), administrate other
domains and provide virtual devices (disks and network) to other
domains.

xenkernel45 and xentools45 contains the kernel and tools from
the Xen 4.5.x branch