=> Bootstrap dependency digest>=20010302: found digest-20190127 ===> 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.5nb6 ========================================================================== The following variables will affect the build process of this package, xenkernel45-4.5.5nb6. Their current value is shown below: * PYTHON_VERSION_DEFAULT = 37 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.2.1nb1 => Tool dependency checkperms>=1.1: found checkperms-1.12 => Build dependency python27>=2.7.1nb2: found python27-2.7.16 => Build dependency cwrappers>=20150314: found cwrappers-20180325 ===> Overriding tools for xenkernel45-4.5.5nb6 ===> Extracting for xenkernel45-4.5.5nb6 ===> Patching for xenkernel45-4.5.5nb6 => Applying pkgsrc patches for xenkernel45-4.5.5nb6 => Verifying /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel45/patches/patch-Config.mk => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/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 /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel45/patches/patch-XSA-191 => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/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 |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 |Reviewed-by: Jan Beulich | |--- 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 /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel45/patches/patch-XSA-192 => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/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 |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 |Reviewed-by: Andrew Cooper |Tested-by: Andrew Cooper | |--- 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 /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel45/patches/patch-XSA-193 => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/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 |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 |Signed-off-by: Jan Beulich |Reviewed-by: Andrew Cooper | |--- 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 /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel45/patches/patch-XSA-195 => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/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 |Subject: x86emul: fix huge bit offset handling | |We must never chop off the high 32 bits. | |This is XSA-195. | |Reported-by: George Dunlap |Signed-off-by: Jan Beulich |Reviewed-by: Andrew Cooper | |--- 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 /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel45/patches/patch-XSA-196-1 => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/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 |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 |Reviewed-by: Jan Beulich |--- | 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 /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel45/patches/patch-XSA-196-2 => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/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 |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 |Reviewed-by: Jan Beulich |--- | 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 /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel45/patches/patch-XSA-200 => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/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 |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 | |--- 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 /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel45/patches/patch-XSA-202 => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/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 |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 | |--- 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 /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel45/patches/patch-XSA-204 => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/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 |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 |Reviewed-by: Jan Beulich |--- | 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 /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel45/patches/patch-XSA-207 => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/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 |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 |Reviewed-by: Jan Beulich |Tested-by: Jan Beulich |Tested-by: Julien Grall | |--- 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 /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel45/patches/patch-XSA-212 => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel45/patches/patch-XSA-212 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA-212,v 1.1 2017/04/08 11:47:33 spz Exp $ | |memory: properly check guest memory ranges in XENMEM_exchange handling | |The use of guest_handle_okay() here (as introduced by the XSA-29 fix) |is insufficient here, guest_handle_subrange_okay() needs to be used |instead. | |Note that the uses are okay in |- XENMEM_add_to_physmap_batch handling due to the size field being only | 16 bits wide, |- livepatch_list() due to the limit of 1024 enforced on the | number-of-entries input (leaving aside the fact that this can be | called by a privileged domain only anyway), |- compat mode handling due to counts there being limited to 32 bits, |- everywhere else due to guest arrays being accessed sequentially from | index zero. | |This is XSA-212. | |Reported-by: Jann Horn |Signed-off-by: Jan Beulich |Reviewed-by: Andrew Cooper | |--- xen/common/memory.c |+++ xen/common/memory.c -------------------------- Patching file xen/common/memory.c using Plan A... Hunk #1 succeeded at 409 (offset -27 lines). Hunk #2 succeeded at 420 (offset -27 lines). Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- xen/include/asm-x86/x86_64/uaccess.h |+++ xen/include/asm-x86/x86_64/uaccess.h -------------------------- Patching file xen/include/asm-x86/x86_64/uaccess.h using Plan A... Hunk #1 succeeded at 29. Hunk #2 succeeded at 41. done => Verifying /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel45/patches/patch-xen_Makefile => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/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 /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel45/patches/patch-xen_arch_arm_xen.lds.S => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel45/patches/patch-xen_arch_arm_xen.lds.S Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-xen_arch_arm_xen.lds.S,v 1.1 2017/05/07 21:21:01 joerg Exp $ | |--- xen/arch/arm/xen.lds.S.orig 2016-09-20 05:59:24.000000000 +0000 |+++ xen/arch/arm/xen.lds.S -------------------------- Patching file xen/arch/arm/xen.lds.S using Plan A... Hunk #1 succeeded at 110. done => Verifying /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel45/patches/patch-xen_arch_x86_Rules.mk => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/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 /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel45/patches/patch-xen_arch_x86_alternative.c => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel45/patches/patch-xen_arch_x86_alternative.c Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-xen_arch_x86_alternative.c,v 1.1 2017/05/07 21:21:01 joerg Exp $ | |--- xen/arch/x86/alternative.c.orig 2016-09-20 05:59:24.000000000 +0000 |+++ xen/arch/x86/alternative.c -------------------------- Patching file xen/arch/x86/alternative.c using Plan A... Hunk #1 succeeded at 39. Hunk #2 succeeded at 63. done => Verifying /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel45/patches/patch-xen_common_efi_boot.c => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel45/patches/patch-xen_common_efi_boot.c Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-xen_common_efi_boot.c,v 1.1 2017/05/07 21:21:01 joerg Exp $ | |--- xen/common/efi/boot.c.orig 2016-09-20 05:59:24.000000000 +0000 |+++ xen/common/efi/boot.c -------------------------- Patching file xen/common/efi/boot.c using Plan A... Hunk #1 succeeded at 239. done => Verifying /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel45/patches/patch-xen_common_page__alloc.c => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/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 /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel45/patches/patch-xen_drivers_passthrough_vtd_x86_ats.c => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/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 /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel45/patches/patch-xen_include_asm-x86_current.h => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/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 /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel45/patches/patch-xen_include_xen_init.h => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel45/patches/patch-xen_include_xen_init.h Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-xen_include_xen_init.h,v 1.1 2017/05/07 21:21:01 joerg Exp $ | |--- xen/include/xen/init.h.orig 2016-09-20 05:59:24.000000000 +0000 |+++ xen/include/xen/init.h -------------------------- Patching file xen/include/xen/init.h using Plan A... Hunk #1 succeeded at 11. done => Verifying /amd/pkgsrc/CHROOT/P/pkgsrc/sysutils/xenkernel45/patches/patch-xen_include_xen_lib.h => Applying pkgsrc patch /amd/pkgsrc/CHROOT/P/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.5nb6