=> Bootstrap dependency digest>=20010302: found digest-20160304
===> Skipping vulnerability checks.
WARNING: No /var/db/pkg/pkg-vulnerabilities file found.
WARNING: To fix run: `/usr/sbin/pkg_admin -K /var/db/pkg fetch-pkg-vulnerabilities'.
=> Checksum SHA1 OK for xen-4.5.5.tar.gz
=> Checksum RMD160 OK for xen-4.5.5.tar.gz
=> Checksum SHA512 OK for xen-4.5.5.tar.gz
===> Installing dependencies for xenkernel45-4.5.5nb4
==========================================================================
The following variables will affect the build process of this package,
xenkernel45-4.5.5nb4.  Their current value is shown below:

        * PYTHON_VERSION_DEFAULT = 27

Based on these variables, the following variables have been set:

        * PYPACKAGE = python27

You may want to abort the process now with CTRL-C and change their value
before continuing.  Be sure to run `/usr/bin/make clean' after
the changes.
==========================================================================
=> Tool dependency gmake>=3.81: found gmake-4.1nb3
=> Tool dependency checkperms>=1.1: found checkperms-1.11nb1
=> Build dependency python27>=2.7.1nb2: found python27-2.7.13nb1
=> Build dependency cwrappers>=20150314: found cwrappers-20170112
===> Overriding tools for xenkernel45-4.5.5nb4
===> Extracting for xenkernel45-4.5.5nb4
===> Patching for xenkernel45-4.5.5nb4
=> Applying pkgsrc patches for xenkernel45-4.5.5nb4
=> Verifying /data/pkgsrc/sysutils/xenkernel45/patches/patch-Config.mk
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel45/patches/patch-Config.mk
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-Config.mk,v 1.1 2015/01/20 16:42:13 bouyer Exp $
|
|--- Config.mk.orig	2015-01-12 17:53:24.000000000 +0100
|+++ Config.mk	2015-01-19 12:29:14.000000000 +0100
--------------------------
Patching file Config.mk using Plan A...
Hunk #1 succeeded at 39.
done
=> Verifying /data/pkgsrc/sysutils/xenkernel45/patches/patch-XSA-191
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel45/patches/patch-XSA-191
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-XSA-191,v 1.1 2016/11/22 20:57:10 bouyer Exp $
|
|From: Andrew Cooper <andrew.cooper3@citrix.com>
|Subject: x86/hvm: Fix the handling of non-present segments
|
|In 32bit, the data segments may be NULL to indicate that the segment is
|ineligible for use.  In both 32bit and 64bit, the LDT selector may be NULL to
|indicate that the entire LDT is ineligible for use.  However, nothing in Xen
|actually checks for this condition when performing other segmentation
|checks.  (Note however that limit and writeability checks are correctly
|performed).
|
|Neither Intel nor AMD specify the exact behaviour of loading a NULL segment.
|Experimentally, AMD zeroes all attributes but leaves the base and limit
|unmodified.  Intel zeroes the base, sets the limit to 0xfffffff and resets the
|attributes to just .G and .D/B.
|
|The use of the segment information in the VMCB/VMCS is equivalent to a native
|pipeline interacting with the segment cache.  The present bit can therefore
|have a subtly different meaning, and it is now cooked to uniformly indicate
|whether the segment is usable or not.
|
|GDTR and IDTR don't have access rights like the other segments, but for
|consistency, they are treated as being present so no special casing is needed
|elsewhere in the segmentation logic.
|
|AMD hardware does not consider the present bit for %cs and %tr, and will
|function as if they were present.  They are therefore unconditionally set to
|present when reading information from the VMCB, to maintain the new meaning of
|usability.
|
|Intel hardware has a separate unusable bit in the VMCS segment attributes.
|This bit is inverted and stored in the present field, so the hvm code can work
|with architecturally-common state.
|
|This is XSA-191.
|
|Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
|Reviewed-by: Jan Beulich <jbeulich@suse.com>
|
|--- xen/arch/x86/hvm/hvm.c.orig
|+++ xen/arch/x86/hvm/hvm.c
--------------------------
Patching file xen/arch/x86/hvm/hvm.c using Plan A...
Hunk #1 succeeded at 3417 (offset -249 lines).
Hunk #2 succeeded at 3867 (offset -8 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- xen/arch/x86/hvm/svm/svm.c.orig
|+++ xen/arch/x86/hvm/svm/svm.c
--------------------------
Patching file xen/arch/x86/hvm/svm/svm.c using Plan A...
Hunk #1 succeeded at 622 (offset 2 lines).
Hunk #2 succeeded at 656 (offset 2 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- xen/arch/x86/hvm/vmx/vmx.c.orig
|+++ xen/arch/x86/hvm/vmx/vmx.c
--------------------------
Patching file xen/arch/x86/hvm/vmx/vmx.c using Plan A...
Hunk #1 succeeded at 829 (offset -38 lines).
Hunk #2 succeeded at 914 (offset -38 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- xen/arch/x86/x86_emulate/x86_emulate.c.orig
|+++ xen/arch/x86/x86_emulate/x86_emulate.c
--------------------------
Patching file xen/arch/x86/x86_emulate/x86_emulate.c using Plan A...
Hunk #1 succeeded at 1163 (offset -46 lines).
done
=> Verifying /data/pkgsrc/sysutils/xenkernel45/patches/patch-XSA-192
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel45/patches/patch-XSA-192
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-XSA-192,v 1.1 2016/11/22 20:57:10 bouyer Exp $
|
|From: Jan Beulich <jbeulich@suse.com>
|Subject: x86/HVM: don't load LDTR with VM86 mode attrs during task switch
|
|Just like TR, LDTR is purely a protected mode facility and hence needs
|to be loaded accordingly. Also move its loading to where it
|architecurally belongs.
|
|This is XSA-192.
|
|Signed-off-by: Jan Beulich <jbeulich@suse.com>
|Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
|Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
|
|--- xen/arch/x86/hvm/hvm.c.orig
|+++ xen/arch/x86/hvm/hvm.c
--------------------------
Patching file xen/arch/x86/hvm/hvm.c using Plan A...
Hunk #1 succeeded at 3581 (offset 4 lines).
Hunk #2 succeeded at 3832 (offset 4 lines).
Hunk #3 succeeded at 3856 (offset 4 lines).
done
=> Verifying /data/pkgsrc/sysutils/xenkernel45/patches/patch-XSA-193
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel45/patches/patch-XSA-193
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-XSA-193,v 1.1 2016/11/22 20:57:10 bouyer Exp $
|
|From: Jan Beulich <jbeulich@suse.com>
|Subject: x86/PV: writes of %fs and %gs base MSRs require canonical addresses
|
|Commit c42494acb2 ("x86: fix FS/GS base handling when using the
|fsgsbase feature") replaced the use of wrmsr_safe() on these paths
|without recognizing that wr{f,g}sbase() use just wrmsrl() and that the
|WR{F,G}SBASE instructions also raise #GP for non-canonical input.
|
|Similarly arch_set_info_guest() needs to prevent non-canonical
|addresses from getting stored into state later to be loaded by context
|switch code. For consistency also check stack pointers and LDT base.
|DR0..3, otoh, already get properly checked in set_debugreg() (albeit
|we discard the error there).
|
|The SHADOW_GS_BASE check isn't strictly necessary, but I think we
|better avoid trying the WRMSR if we know it's going to fail.
|
|This is XSA-193.
|
|Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
|Signed-off-by: Jan Beulich <jbeulich@suse.com>
|Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
|
|--- xen/arch/x86/domain.c.orig
|+++ xen/arch/x86/domain.c
--------------------------
Patching file xen/arch/x86/domain.c using Plan A...
Hunk #1 succeeded at 741.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- xen/arch/x86/traps.c.orig
|+++ xen/arch/x86/traps.c
--------------------------
Patching file xen/arch/x86/traps.c using Plan A...
Hunk #1 succeeded at 2439.
done
=> Verifying /data/pkgsrc/sysutils/xenkernel45/patches/patch-XSA-195
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel45/patches/patch-XSA-195
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-XSA-195,v 1.1 2016/11/22 20:57:10 bouyer Exp $
|
|From: Jan Beulich <jbeulich@suse.com>
|Subject: x86emul: fix huge bit offset handling
|
|We must never chop off the high 32 bits.
|
|This is XSA-195.
|
|Reported-by: George Dunlap <george.dunlap@citrix.com>
|Signed-off-by: Jan Beulich <jbeulich@suse.com>
|Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
|
|--- xen/arch/x86/x86_emulate/x86_emulate.c.orig
|+++ xen/arch/x86/x86_emulate/x86_emulate.c
--------------------------
Patching file xen/arch/x86/x86_emulate/x86_emulate.c using Plan A...
Hunk #1 succeeded at 1936 (offset -613 lines).
Hunk #2 succeeded at 1953 (offset -613 lines).
done
=> Verifying /data/pkgsrc/sysutils/xenkernel45/patches/patch-XSA-196-1
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel45/patches/patch-XSA-196-1
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-XSA-196-1,v 1.1 2016/11/22 20:57:10 bouyer Exp $
|
|From: Andrew Cooper <andrew.cooper3@citrix.com>
|Subject: x86/emul: Correct the IDT entry calculation in inject_swint()
|
|The logic, as introduced in c/s 36ebf14ebe "x86/emulate: support for emulating
|software event injection" is buggy.  The size of an IDT entry depends on long
|mode being active, not the width of the code segment currently in use.
|
|In particular, this means that a compatibility code segment which hits
|emulation for software event injection will end up using an incorrect offset
|in the IDT for DPL/Presence checking.  In practice, this only occurs on old
|AMD hardware lacking NRip support; all newer AMD hardware, and all Intel
|hardware bypass this path in the emulator.
|
|While here, fix a minor issue with reading the IDT entry.  The return value
|from ops->read() wasn't checked, but in reality the only failure case is if a
|pagefault occurs.  This is not a realistic problem as the kernel will almost
|certainly crash with a double fault if this setup actually occured.
|
|This is part of XSA-196.
|
|Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
|Reviewed-by: Jan Beulich <jbeulich@suse.com>
|---
| xen/arch/x86/x86_emulate/x86_emulate.c | 15 +++++++++++----
| 1 file changed, 11 insertions(+), 4 deletions(-)
|
|diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c b/xen/arch/x86/x86_emulate/x86_emulate.c
|index 7a707dc..f74aa8f 100644
|--- xen/arch/x86/x86_emulate/x86_emulate.c.orig
|+++ xen/arch/x86/x86_emulate/x86_emulate.c
--------------------------
Patching file xen/arch/x86/x86_emulate/x86_emulate.c using Plan A...
Hunk #1 succeeded at 1412 (offset -218 lines).
Hunk #2 succeeded at 1449 (offset -218 lines).
done
=> Verifying /data/pkgsrc/sysutils/xenkernel45/patches/patch-XSA-196-2
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel45/patches/patch-XSA-196-2
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-XSA-196-2,v 1.1 2016/11/22 20:57:10 bouyer Exp $
|
|From: Andrew Cooper <andrew.cooper3@citrix.com>
|Subject: x86/svm: Fix injection of software interrupts
|
|The non-NextRip logic in c/s 36ebf14eb "x86/emulate: support for emulating
|software event injection" was based on an older version of the AMD software
|manual.  The manual was later corrected, following findings from that series.
|
|I took the original wording of "not supported without NextRIP" to mean that
|X86_EVENTTYPE_SW_INTERRUPT was not eligible for use.  It turns out that this
|is not the case, and the new wording is clearer on the matter.
|
|Despite testing the original patch series on non-NRip hardware, the
|swint-emulation XTF test case focuses on the debug vectors; it never ended up
|executing an `int $n` instruction for a vector which wasn't also an exception.
|
|During a vmentry, the use of X86_EVENTTYPE_HW_EXCEPTION comes with a vector
|check to ensure that it is only used with exception vectors.  Xen's use of
|X86_EVENTTYPE_HW_EXCEPTION for `int $n` injection has always been buggy on AMD
|hardware.
|
|Fix this by always using X86_EVENTTYPE_SW_INTERRUPT.
|
|Print and decode the eventinj information in svm_vmcb_dump(), as it has
|several invalid combinations which cause vmentry failures.
|
|This is part of XSA-196.
|
|Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
|Reviewed-by: Jan Beulich <jbeulich@suse.com>
|---
| xen/arch/x86/hvm/svm/svm.c      | 13 +++++--------
| xen/arch/x86/hvm/svm/svmdebug.c |  4 ++++
| 2 files changed, 9 insertions(+), 8 deletions(-)
|
|diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
|index 4391744..76efc3e 100644
|--- xen/arch/x86/hvm/svm/svm.c.orig
|+++ xen/arch/x86/hvm/svm/svm.c
--------------------------
Patching file xen/arch/x86/hvm/svm/svm.c using Plan A...
Hunk #1 succeeded at 1229 (offset -2 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff --git a/xen/arch/x86/hvm/svm/svmdebug.c b/xen/arch/x86/hvm/svm/svmdebug.c
|index ded5d19..f93dfed 100644
|--- xen/arch/x86/hvm/svm/svmdebug.c.orig
|+++ xen/arch/x86/hvm/svm/svmdebug.c
--------------------------
Patching file xen/arch/x86/hvm/svm/svmdebug.c using Plan A...
Hunk #1 succeeded at 49 (offset 1 line).
done
=> Verifying /data/pkgsrc/sysutils/xenkernel45/patches/patch-XSA-200
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel45/patches/patch-XSA-200
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-XSA-200,v 1.1 2016/12/20 10:22:28 bouyer Exp $
|
|From: Jan Beulich <jbeulich@suse.com>
|Subject: x86emul: CMPXCHG8B ignores operand size prefix
|
|Otherwise besides mis-handling the instruction, the comparison failure
|case would result in uninitialized stack data being handed back to the
|guest in rDX:rAX (32 bits leaked for 32-bit guests, 96 bits for 64-bit
|ones).
|
|This is XSA-200.
|
|Signed-off-by: Jan Beulich <jbeulich@suse.com>
|
|--- tools/tests/x86_emulator/test_x86_emulator.c.orig
|+++ tools/tests/x86_emulator/test_x86_emulator.c
--------------------------
Patching file tools/tests/x86_emulator/test_x86_emulator.c using Plan A...
Hunk #1 succeeded at 412 (offset -17 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- xen/arch/x86/x86_emulate/x86_emulate.c.orig
|+++ xen/arch/x86/x86_emulate/x86_emulate.c
--------------------------
Patching file xen/arch/x86/x86_emulate/x86_emulate.c using Plan A...
No such line 4738 in input file, ignoring
Hunk #1 succeeded at 4641 (offset -98 lines).
done
=> Verifying /data/pkgsrc/sysutils/xenkernel45/patches/patch-XSA-202
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel45/patches/patch-XSA-202
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-XSA-202,v 1.1 2016/12/21 15:36:08 bouyer Exp $
|
|From: Jan Beulich <jbeulich@suse.com>
|Subject: x86: force EFLAGS.IF on when exiting to PV guests
|
|Guest kernels modifying instructions in the process of being emulated
|for another of their vCPU-s may effect EFLAGS.IF to be cleared upon
|next exiting to guest context, by converting the being emulated
|instruction to CLI (at the right point in time). Prevent any such bad
|effects by always forcing EFLAGS.IF on. And to cover hypothetical other
|similar issues, also force EFLAGS.{IOPL,NT,VM} to zero.
|
|This is XSA-202.
|
|Signed-off-by: Jan Beulich <jbeulich@suse.com>
|
|--- xen/arch/x86/x86_64/compat/entry.S.orig
|+++ xen/arch/x86/x86_64/compat/entry.S
--------------------------
Patching file xen/arch/x86/x86_64/compat/entry.S using Plan A...
Hunk #1 succeeded at 174.
Hunk #2 succeeded at 211.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- xen/arch/x86/x86_64/entry.S.orig
|+++ xen/arch/x86/x86_64/entry.S
--------------------------
Patching file xen/arch/x86/x86_64/entry.S using Plan A...
Hunk #1 succeeded at 41 (offset 1 line).
done
=> Verifying /data/pkgsrc/sysutils/xenkernel45/patches/patch-XSA-204
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel45/patches/patch-XSA-204
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-XSA-204,v 1.1 2016/12/20 10:22:28 bouyer Exp $
|
|From: Andrew Cooper <andrew.cooper3@citrix.com>
|Date: Sun, 18 Dec 2016 15:42:59 +0000
|Subject: [PATCH] x86/emul: Correct the handling of eflags with SYSCALL
|
|A singlestep #DB is determined by the resulting eflags value from the
|execution of SYSCALL, not the original eflags value.
|
|By using the original eflags value, we negate the guest kernels attempt to
|protect itself from a privilege escalation by masking TF.
|
|Introduce a tf boolean and have the SYSCALL emulation recalculate it
|after the instruction is complete.
|
|This is XSA-204
|
|Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
|Reviewed-by: Jan Beulich <jbeulich@suse.com>
|---
| xen/arch/x86/x86_emulate/x86_emulate.c | 23 ++++++++++++++++++++---
| 1 file changed, 20 insertions(+), 3 deletions(-)
|
|diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c b/xen/arch/x86/x86_emulate/x86_emulate.c
|index 0c43fe1..f675dc9 100644
|--- xen/arch/x86/x86_emulate/x86_emulate.c.orig
|+++ xen/arch/x86/x86_emulate/x86_emulate.c
--------------------------
Patching file xen/arch/x86/x86_emulate/x86_emulate.c using Plan A...
Hunk #1 succeeded at 1498 (offset -39 lines).
Hunk #2 succeeded at 3876 (offset -6 lines).
Hunk #3 succeeded at 4029 (offset -39 lines).
done
=> Verifying /data/pkgsrc/sysutils/xenkernel45/patches/patch-XSA-207
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel45/patches/patch-XSA-207
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-XSA-207,v 1.1 2017/03/20 18:11:10 bouyer Exp $
|
|From: Oleksandr Tyshchenko <olekstysh@gmail.com>
|Subject: IOMMU: always call teardown callback
|
|There is a possible scenario when (d)->need_iommu remains unset
|during guest domain execution. For example, when no devices
|were assigned to it. Taking into account that teardown callback
|is not called when (d)->need_iommu is unset we might have unreleased
|resourses after destroying domain.
|
|So, always call teardown callback to roll back actions
|that were performed in init callback.
|
|This is XSA-207.
|
|Signed-off-by: Oleksandr Tyshchenko <olekstysh@gmail.com>
|Reviewed-by: Jan Beulich <jbeulich@suse.com>
|Tested-by: Jan Beulich <jbeulich@suse.com>
|Tested-by: Julien Grall <julien.grall@arm.com>
|
|--- xen/drivers/passthrough/iommu.c.orig
|+++ xen/drivers/passthrough/iommu.c
--------------------------
Patching file xen/drivers/passthrough/iommu.c using Plan A...
Hunk #1 succeeded at 191 (offset -53 lines).
done
=> Verifying /data/pkgsrc/sysutils/xenkernel45/patches/patch-xen_Makefile
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel45/patches/patch-xen_Makefile
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-xen_Makefile,v 1.1 2015/01/20 16:42:13 bouyer Exp $
|
|--- xen/Makefile.orig	2015-01-12 17:53:24.000000000 +0100
|+++ xen/Makefile	2015-01-19 12:29:14.000000000 +0100
--------------------------
Patching file xen/Makefile using Plan A...
Hunk #1 succeeded at 131.
done
=> Verifying /data/pkgsrc/sysutils/xenkernel45/patches/patch-xen_arch_x86_Rules.mk
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel45/patches/patch-xen_arch_x86_Rules.mk
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-xen_arch_x86_Rules.mk,v 1.1 2015/01/20 16:42:13 bouyer Exp $
|
|--- xen/arch/x86/Rules.mk.orig	2015-01-12 17:53:24.000000000 +0100
|+++ xen/arch/x86/Rules.mk	2015-01-19 12:29:14.000000000 +0100
--------------------------
Patching file xen/arch/x86/Rules.mk using Plan A...
Hunk #1 succeeded at 24.
done
=> Verifying /data/pkgsrc/sysutils/xenkernel45/patches/patch-xen_common_page__alloc.c
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel45/patches/patch-xen_common_page__alloc.c
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-xen_common_page__alloc.c,v 1.1 2015/09/14 13:36:29 joerg Exp $
|
|--- xen/common/page_alloc.c.orig	2015-09-13 17:37:09.000000000 +0000
|+++ xen/common/page_alloc.c
--------------------------
Patching file xen/common/page_alloc.c using Plan A...
Hunk #1 succeeded at 1564 (offset 3 lines).
done
=> Verifying /data/pkgsrc/sysutils/xenkernel45/patches/patch-xen_drivers_passthrough_vtd_x86_ats.c
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel45/patches/patch-xen_drivers_passthrough_vtd_x86_ats.c
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-xen_drivers_passthrough_vtd_x86_ats.c,v 1.1 2015/09/14 13:36:29 joerg Exp $
|
|--- xen/drivers/passthrough/vtd/x86/ats.c.orig	2015-06-22 13:41:35.000000000 +0000
|+++ xen/drivers/passthrough/vtd/x86/ats.c
--------------------------
Patching file xen/drivers/passthrough/vtd/x86/ats.c using Plan A...
Hunk #1 succeeded at 134.
Hunk #2 succeeded at 146.
done
=> Verifying /data/pkgsrc/sysutils/xenkernel45/patches/patch-xen_include_asm-x86_current.h
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel45/patches/patch-xen_include_asm-x86_current.h
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-xen_include_asm-x86_current.h,v 1.1 2015/02/04 20:52:16 joerg Exp $
|
|--- xen/include/asm-x86/current.h.orig	2015-01-30 12:45:05.000000000 +0000
|+++ xen/include/asm-x86/current.h
--------------------------
Patching file xen/include/asm-x86/current.h using Plan A...
Hunk #1 succeeded at 25.
done
=> Verifying /data/pkgsrc/sysutils/xenkernel45/patches/patch-xen_include_xen_lib.h
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel45/patches/patch-xen_include_xen_lib.h
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-xen_include_xen_lib.h,v 1.2 2015/06/23 17:45:33 bouyer Exp $
|
|--- xen/include/xen/lib.h.orig	2015-06-22 15:41:35.000000000 +0200
|+++ xen/include/xen/lib.h	2015-06-23 18:32:26.000000000 +0200
--------------------------
Patching file xen/include/xen/lib.h using Plan A...
Hunk #1 succeeded at 44.
done
===> Creating toolchain wrappers for xenkernel45-4.5.5nb4