=> Bootstrap dependency digest>=20010302: found digest-20190127 => Checksum SHA1 OK for xen411/xen-4.11.4.tar.gz => Checksum RMD160 OK for xen411/xen-4.11.4.tar.gz => Checksum SHA512 OK for xen411/xen-4.11.4.tar.gz ===> Installing dependencies for xenkernel411-4.11.4nb1 ========================================================================== The following variables will affect the build process of this package, xenkernel411-4.11.4nb1. 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.18nb1 => Build dependency cwrappers>=20150314: found cwrappers-20180325 ===> 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'. ===> Overriding tools for xenkernel411-4.11.4nb1 ===> Extracting for xenkernel411-4.11.4nb1 ===> Patching for xenkernel411-4.11.4nb1 => Applying pkgsrc patches for xenkernel411-4.11.4nb1 => Verifying /data/pkgsrc/sysutils/xenkernel411/patches/patch-Config.mk => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel411/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 2018/07/24 13:40:11 bouyer Exp $ | |--- Config.mk.orig 2018-04-17 19:21:31.000000000 +0200 |+++ Config.mk 2018-04-23 13:29:47.000000000 +0200 -------------------------- Patching file Config.mk using Plan A... Hunk #1 succeeded at 32. done => Verifying /data/pkgsrc/sysutils/xenkernel411/patches/patch-XSA317 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel411/patches/patch-XSA317 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA317,v 1.1 2020/07/16 09:57:17 bouyer Exp $ | |From aeb46e92f915f19a61d5a8a1f4b696793f64e6fb Mon Sep 17 00:00:00 2001 |From: Julien Grall |Date: Thu, 19 Mar 2020 13:17:31 +0000 |Subject: [PATCH] xen/common: event_channel: Don't ignore error in | get_free_port() | |Currently, get_free_port() is assuming that the port has been allocated |when evtchn_allocate_port() is not return -EBUSY. | |However, the function may return an error when: | - We exhausted all the event channels. This can happen if the limit | configured by the administrator for the guest ('max_event_channels' | in xl cfg) is higher than the ABI used by the guest. For instance, | if the guest is using 2L, the limit should not be higher than 4095. | - We cannot allocate memory (e.g Xen has not more memory). | |Users of get_free_port() (such as EVTCHNOP_alloc_unbound) will validly |assuming the port was valid and will next call evtchn_from_port(). This |will result to a crash as the memory backing the event channel structure |is not present. | |Fixes: 368ae9a05fe ("xen/pvshim: forward evtchn ops between L0 Xen and L2 DomU") |Signed-off-by: Julien Grall |Reviewed-by: Jan Beulich |--- | xen/common/event_channel.c | 8 ++++---- | 1 file changed, 4 insertions(+), 4 deletions(-) | |diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c |index e86e2bfab0..a8d182b584 100644 |--- xen/common/event_channel.c.orig |+++ xen/common/event_channel.c -------------------------- Patching file xen/common/event_channel.c using Plan A... Hunk #1 succeeded at 195. Hmm... Ignoring the trailing garbage. done => Verifying /data/pkgsrc/sysutils/xenkernel411/patches/patch-XSA319 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel411/patches/patch-XSA319 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA319,v 1.1 2020/07/16 09:57:17 bouyer Exp $ | |From: Jan Beulich |Subject: x86/shadow: correct an inverted conditional in dirty VRAM tracking | |This originally was "mfn_x(mfn) == INVALID_MFN". Make it like this |again, taking the opportunity to also drop the unnecessary nearby |braces. | |This is XSA-319. | |Fixes: 246a5a3377c2 ("xen: Use a typesafe to define INVALID_MFN") |Signed-off-by: Jan Beulich |Reviewed-by: Andrew Cooper | |--- xen/arch/x86/mm/shadow/common.c.orig |+++ xen/arch/x86/mm/shadow/common.c -------------------------- Patching file xen/arch/x86/mm/shadow/common.c using Plan A... Hunk #1 succeeded at 3881 (offset 629 lines). done => Verifying /data/pkgsrc/sysutils/xenkernel411/patches/patch-XSA320 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel411/patches/patch-XSA320 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA320,v 1.1 2020/07/16 09:57:17 bouyer Exp $ | |From: Andrew Cooper |Subject: x86/spec-ctrl: CPUID/MSR definitions for Special Register Buffer Data Sampling | |This is part of XSA-320 / CVE-2020-0543 | |Signed-off-by: Andrew Cooper |Reviewed-by: Jan Beulich |Acked-by: Wei Liu | |diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown |index 194615bfc5..9be18ac99f 100644 |--- docs/misc/xen-command-line.markdown.orig |+++ docs/misc/xen-command-line.markdown -------------------------- Patching file docs/misc/xen-command-line.markdown using Plan A... Hunk #1 succeeded at 489. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff --git a/tools/libxl/libxl_cpuid.c b/tools/libxl/libxl_cpuid.c |index 5a1702d703..1235c8b91e 100644 |--- tools/libxl/libxl_cpuid.c.orig |+++ tools/libxl/libxl_cpuid.c -------------------------- Patching file tools/libxl/libxl_cpuid.c using Plan A... Hunk #1 succeeded at 202. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff --git a/tools/misc/xen-cpuid.c b/tools/misc/xen-cpuid.c |index 4c9af6b7f0..8fb54c3001 100644 |--- tools/misc/xen-cpuid.c.orig |+++ tools/misc/xen-cpuid.c -------------------------- Patching file tools/misc/xen-cpuid.c using Plan A... Hunk #1 succeeded at 142. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c |index 04aefa555d..b8e5b6fe67 100644 |--- xen/arch/x86/cpuid.c.orig |+++ xen/arch/x86/cpuid.c -------------------------- Patching file xen/arch/x86/cpuid.c using Plan A... Hunk #1 succeeded at 58. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c |index ccb316c547..256e58d82b 100644 |--- xen/arch/x86/msr.c.orig |+++ xen/arch/x86/msr.c -------------------------- Patching file xen/arch/x86/msr.c using Plan A... Hunk #1 succeeded at 154. Hunk #2 succeeded at 244. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c |index ab196b156d..94ab8dd786 100644 |--- xen/arch/x86/spec_ctrl.c.orig |+++ xen/arch/x86/spec_ctrl.c -------------------------- Patching file xen/arch/x86/spec_ctrl.c using Plan A... Hunk #1 succeeded at 365. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff --git a/xen/include/asm-x86/msr-index.h b/xen/include/asm-x86/msr-index.h |index 1761a01f1f..480d1d8102 100644 |--- xen/include/asm-x86/msr-index.h.orig |+++ xen/include/asm-x86/msr-index.h -------------------------- Patching file xen/include/asm-x86/msr-index.h using Plan A... Hunk #1 succeeded at 177. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff --git a/xen/include/public/arch-x86/cpufeatureset.h b/xen/include/public/arch-x86/cpufeatureset.h |index a14d8a7013..9d210e74a0 100644 |--- xen/include/public/arch-x86/cpufeatureset.h.orig |+++ xen/include/public/arch-x86/cpufeatureset.h -------------------------- Patching file xen/include/public/arch-x86/cpufeatureset.h using Plan A... Hunk #1 succeeded at 242. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |From: Andrew Cooper |Subject: x86/spec-ctrl: Mitigate the Special Register Buffer Data Sampling sidechannel | |See patch documentation and comments. | |This is part of XSA-320 / CVE-2020-0543 | |Signed-off-by: Andrew Cooper |Reviewed-by: Jan Beulich | |diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown |index 9be18ac99f..3356e59fee 100644 |--- docs/misc/xen-command-line.markdown.orig |+++ docs/misc/xen-command-line.markdown -------------------------- Patching file docs/misc/xen-command-line.markdown using Plan A... Hunk #1 succeeded at 1858. Hunk #2 succeeded at 1930. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff --git a/xen/arch/x86/acpi/power.c b/xen/arch/x86/acpi/power.c |index 4c12794809..30e1bd5cd3 100644 |--- xen/arch/x86/acpi/power.c.orig |+++ xen/arch/x86/acpi/power.c -------------------------- Patching file xen/arch/x86/acpi/power.c using Plan A... Hunk #1 succeeded at 266. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c |index 0887806e85..d24d215946 100644 |--- xen/arch/x86/smpboot.c.orig |+++ xen/arch/x86/smpboot.c -------------------------- Patching file xen/arch/x86/smpboot.c using Plan A... Hunk #1 succeeded at 369. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c |index 94ab8dd786..a306d10c34 100644 |--- xen/arch/x86/spec_ctrl.c.orig |+++ xen/arch/x86/spec_ctrl.c -------------------------- Patching file xen/arch/x86/spec_ctrl.c using Plan A... Hunk #1 succeeded at 63. Hunk #2 succeeded at 169. Hunk #3 succeeded at 235. Hunk #4 succeeded at 400. Hunk #5 succeeded at 411. Hunk #6 succeeded at 1204. Hunk #7 succeeded at 1263. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff --git a/xen/include/asm-x86/spec_ctrl.h b/xen/include/asm-x86/spec_ctrl.h |index 333d180b7e..bf10d2ce5c 100644 |--- xen/include/asm-x86/spec_ctrl.h.orig |+++ xen/include/asm-x86/spec_ctrl.h -------------------------- Patching file xen/include/asm-x86/spec_ctrl.h using Plan A... Hunk #1 succeeded at 46. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |From: Andrew Cooper |Subject: x86/spec-ctrl: Allow the RDRAND/RDSEED features to be hidden | |RDRAND/RDSEED can be hidden using cpuid= to mitigate SRBDS if microcode |isn't available. | |This is part of XSA-320 / CVE-2020-0543. | |Signed-off-by: Andrew Cooper |Acked-by: Julien Grall | |diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown |index 3356e59fee..ac397e7de0 100644 |--- docs/misc/xen-command-line.markdown.orig |+++ docs/misc/xen-command-line.markdown -------------------------- Patching file docs/misc/xen-command-line.markdown using Plan A... Hunk #1 succeeded at 487. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c |index b8e5b6fe67..78d08dbb32 100644 |--- xen/arch/x86/cpuid.c.orig |+++ xen/arch/x86/cpuid.c -------------------------- Patching file xen/arch/x86/cpuid.c using Plan A... Hunk #1 succeeded at 63. done => Verifying /data/pkgsrc/sysutils/xenkernel411/patches/patch-XSA321 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel411/patches/patch-XSA321 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA321,v 1.2 2020/08/24 10:35:35 bouyer Exp $ | |From: Jan Beulich |Subject: vtd: improve IOMMU TLB flush | |Do not limit PSI flushes to order 0 pages, in order to avoid doing a |full TLB flush if the passed in page has an order greater than 0 and |is aligned. Should increase the performance of IOMMU TLB flushes when |dealing with page orders greater than 0. | |This is part of XSA-321. | |Signed-off-by: Jan Beulich | |--- xen/drivers/passthrough/vtd/iommu.c.orig |+++ xen/drivers/passthrough/vtd/iommu.c -------------------------- Patching file xen/drivers/passthrough/vtd/iommu.c using Plan A... Hunk #1 succeeded at 612. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |From: |Subject: vtd: prune (and rename) cache flush functions | |Rename __iommu_flush_cache to iommu_sync_cache and remove |iommu_flush_cache_page. Also remove the iommu_flush_cache_entry |wrapper and just use iommu_sync_cache instead. Note the _entry suffix |was meaningless as the wrapper was already taking a size parameter in |bytes. While there also constify the addr parameter. | |No functional change intended. | |This is part of XSA-321. | |Reviewed-by: Jan Beulich | |--- xen/drivers/passthrough/vtd/extern.h.orig |+++ xen/drivers/passthrough/vtd/extern.h -------------------------- Patching file xen/drivers/passthrough/vtd/extern.h using Plan A... Hunk #1 succeeded at 37. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- xen/drivers/passthrough/vtd/intremap.c.orig |+++ xen/drivers/passthrough/vtd/intremap.c -------------------------- Patching file xen/drivers/passthrough/vtd/intremap.c using Plan A... Hunk #1 succeeded at 231. Hunk #2 succeeded at 403. Hunk #3 succeeded at 694. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- xen/drivers/passthrough/vtd/iommu.c.orig |+++ xen/drivers/passthrough/vtd/iommu.c -------------------------- Patching file xen/drivers/passthrough/vtd/iommu.c using Plan A... Hunk #1 succeeded at 158. Hunk #2 succeeded at 174. Hunk #3 succeeded at 198. Hunk #4 succeeded at 233. Hunk #5 succeeded at 291. Hunk #6 succeeded at 665. Hunk #7 succeeded at 707. Hunk #8 succeeded at 1440. Hunk #9 succeeded at 1593. Hunk #10 succeeded at 1819. Hunk #11 succeeded at 1853. Hunk #12 succeeded at 2716. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |From: |Subject: x86/iommu: introduce a cache sync hook | |The hook is only implemented for VT-d and it uses the already existing |iommu_sync_cache function present in VT-d code. The new hook is |added so that the cache can be flushed by code outside of VT-d when |using shared page tables. | |Note that alloc_pgtable_maddr must use the now locally defined |sync_cache function, because IOMMU ops are not yet setup the first |time the function gets called during IOMMU initialization. | |No functional change intended. | |This is part of XSA-321. | |Reviewed-by: Jan Beulich | |--- xen/drivers/passthrough/vtd/extern.h.orig |+++ xen/drivers/passthrough/vtd/extern.h -------------------------- Patching file xen/drivers/passthrough/vtd/extern.h using Plan A... Hunk #1 succeeded at 37. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- xen/drivers/passthrough/vtd/iommu.c.orig |+++ xen/drivers/passthrough/vtd/iommu.c -------------------------- Patching file xen/drivers/passthrough/vtd/iommu.c using Plan A... Hunk #1 succeeded at 159. Hunk #2 succeeded at 198. Hunk #3 succeeded at 2760. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- xen/include/asm-x86/iommu.h.orig |+++ xen/include/asm-x86/iommu.h -------------------------- Patching file xen/include/asm-x86/iommu.h using Plan A... Hunk #1 succeeded at 98. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- xen/include/xen/iommu.h.orig |+++ xen/include/xen/iommu.h -------------------------- Patching file xen/include/xen/iommu.h using Plan A... Hunk #1 succeeded at 161. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |From: |Subject: vtd: don't assume addresses are aligned in sync_cache | |Current code in sync_cache assume that the address passed in is |aligned to a cache line size. Fix the code to support passing in |arbitrary addresses not necessarily aligned to a cache line size. | |This is part of XSA-321. | |Reviewed-by: Jan Beulich | |--- xen/drivers/passthrough/vtd/iommu.c.orig |+++ xen/drivers/passthrough/vtd/iommu.c -------------------------- Patching file xen/drivers/passthrough/vtd/iommu.c using Plan A... Hunk #1 succeeded at 161. Hunk #2 succeeded at 170. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |From: |Subject: x86/alternative: introduce alternative_2 | |It's based on alternative_io_2 without inputs or outputs but with an |added memory clobber. | |This is part of XSA-321. | |Acked-by: Jan Beulich | |--- xen/include/asm-x86/alternative.h.orig |+++ xen/include/asm-x86/alternative.h -------------------------- Patching file xen/include/asm-x86/alternative.h using Plan A... Hunk #1 succeeded at 113. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |From: |Subject: vtd: optimize CPU cache sync | |Some VT-d IOMMUs are non-coherent, which requires a cache write back |in order for the changes made by the CPU to be visible to the IOMMU. |This cache write back was unconditionally done using clflush, but there are |other more efficient instructions to do so, hence implement support |for them using the alternative framework. | |This is part of XSA-321. | |Reviewed-by: Jan Beulich | |--- xen/drivers/passthrough/vtd/extern.h.orig |+++ xen/drivers/passthrough/vtd/extern.h -------------------------- Patching file xen/drivers/passthrough/vtd/extern.h using Plan A... Hunk #1 succeeded at 63. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- xen/drivers/passthrough/vtd/iommu.c.orig |+++ xen/drivers/passthrough/vtd/iommu.c -------------------------- Patching file xen/drivers/passthrough/vtd/iommu.c using Plan A... Hunk #1 succeeded at 31. Hunk #2 succeeded at 173. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- xen/drivers/passthrough/vtd/x86/vtd.c.orig |+++ xen/drivers/passthrough/vtd/x86/vtd.c -------------------------- Patching file xen/drivers/passthrough/vtd/x86/vtd.c using Plan A... Hunk #1 succeeded at 53. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |From: |Subject: x86/ept: flush cache when modifying PTEs and sharing page tables | |Modifications made to the page tables by EPT code need to be written |to memory when the page tables are shared with the IOMMU, as Intel |IOMMUs can be non-coherent and thus require changes to be written to |memory in order to be visible to the IOMMU. | |In order to achieve this make sure data is written back to memory |after writing an EPT entry when the recalc bit is not set in |atomic_write_ept_entry. If such bit is set, the entry will be |adjusted and atomic_write_ept_entry will be called a second time |without the recalc bit set. Note that when splitting a super page the |new tables resulting of the split should also be written back. | |Failure to do so can allow devices behind the IOMMU access to the |stale super page, or cause coherency issues as changes made by the |processor to the page tables are not visible to the IOMMU. | |This allows to remove the VT-d specific iommu_pte_flush helper, since |the cache write back is now performed by atomic_write_ept_entry, and |hence iommu_iotlb_flush can be used to flush the IOMMU TLB. The newly |used method (iommu_iotlb_flush) can result in less flushes, since it |might sometimes be called rightly with 0 flags, in which case it |becomes a no-op. | |This is part of XSA-321. | |Reviewed-by: Jan Beulich | |--- xen/arch/x86/mm/p2m-ept.c.orig |+++ xen/arch/x86/mm/p2m-ept.c -------------------------- Patching file xen/arch/x86/mm/p2m-ept.c using Plan A... Hunk #1 succeeded at 90. Hunk #2 succeeded at 334 (offset 2 lines). Hunk #3 succeeded at 891 (offset -3 lines). Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- xen/drivers/passthrough/vtd/iommu.c.orig |+++ xen/drivers/passthrough/vtd/iommu.c -------------------------- Patching file xen/drivers/passthrough/vtd/iommu.c using Plan A... Hunk #1 succeeded at 612. Hunk #2 succeeded at 1878. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- xen/include/asm-x86/iommu.h.orig |+++ xen/include/asm-x86/iommu.h -------------------------- Patching file xen/include/asm-x86/iommu.h using Plan A... Hunk #1 succeeded at 87. done => Verifying /data/pkgsrc/sysutils/xenkernel411/patches/patch-XSA328 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel411/patches/patch-XSA328 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA328,v 1.1 2020/07/16 09:57:17 bouyer Exp $ | |From: Jan Beulich |Subject: x86/EPT: ept_set_middle_entry() related adjustments | |ept_split_super_page() wants to further modify the newly allocated |table, so have ept_set_middle_entry() return the mapped pointer rather |than tearing it down and then getting re-established right again. | |Similarly ept_next_level() wants to hand back a mapped pointer of |the next level page, so re-use the one established by |ept_set_middle_entry() in case that path was taken. | |Pull the setting of suppress_ve ahead of insertion into the higher level |table, and don't have ept_split_super_page() set the field a 2nd time. | |This is part of XSA-328. | |Signed-off-by: Jan Beulich | |--- xen/arch/x86/mm/p2m-ept.c.orig |+++ xen/arch/x86/mm/p2m-ept.c -------------------------- Patching file xen/arch/x86/mm/p2m-ept.c using Plan A... Hunk #1 succeeded at 241 (offset 13 lines). Hunk #2 succeeded at 251 (offset 13 lines). Hunk #3 succeeded at 268 (offset 13 lines). Hunk #4 succeeded at 306 (offset 13 lines). Hunk #5 succeeded at 320 (offset 13 lines). Hunk #6 succeeded at 348 (offset 3 lines). Hunk #7 succeeded at 383 (offset 13 lines). Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |From: |Subject: x86/ept: atomically modify entries in ept_next_level | |ept_next_level was passing a live PTE pointer to ept_set_middle_entry, |which was then modified without taking into account that the PTE could |be part of a live EPT table. This wasn't a security issue because the |pages returned by p2m_alloc_ptp are zeroed, so adding such an entry |before actually initializing it didn't allow a guest to access |physical memory addresses it wasn't supposed to access. | |This is part of XSA-328. | |Reviewed-by: Jan Beulich | |--- xen/arch/x86/mm/p2m-ept.c.orig |+++ xen/arch/x86/mm/p2m-ept.c -------------------------- Patching file xen/arch/x86/mm/p2m-ept.c using Plan A... Hunk #1 succeeded at 364 (offset 16 lines). Hunk #2 succeeded at 382 (offset 16 lines). Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- | |this has to be applied after patch-XSA328 | |From: |Subject: x86/ept: flush cache when modifying PTEs and sharing page tables | |Modifications made to the page tables by EPT code need to be written |to memory when the page tables are shared with the IOMMU, as Intel |IOMMUs can be non-coherent and thus require changes to be written to |memory in order to be visible to the IOMMU. | |In order to achieve this make sure data is written back to memory |after writing an EPT entry when the recalc bit is not set in |atomic_write_ept_entry. If such bit is set, the entry will be |adjusted and atomic_write_ept_entry will be called a second time |without the recalc bit set. Note that when splitting a super page the |new tables resulting of the split should also be written back. | |Failure to do so can allow devices behind the IOMMU access to the |stale super page, or cause coherency issues as changes made by the |processor to the page tables are not visible to the IOMMU. | |This allows to remove the VT-d specific iommu_pte_flush helper, since |the cache write back is now performed by atomic_write_ept_entry, and |hence iommu_iotlb_flush can be used to flush the IOMMU TLB. The newly |used method (iommu_iotlb_flush) can result in less flushes, since it |might sometimes be called rightly with 0 flags, in which case it |becomes a no-op. | |This is part of XSA-321. | |Reviewed-by: Jan Beulich | |--- xen/arch/x86/mm/p2m-ept.c.orig |+++ xen/arch/x86/mm/p2m-ept.c -------------------------- Patching file xen/arch/x86/mm/p2m-ept.c using Plan A... Hunk #1 succeeded at 394. done => Verifying /data/pkgsrc/sysutils/xenkernel411/patches/patch-xen_Makefile => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel411/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 2018/07/24 13:40:11 bouyer Exp $ | |--- xen/Makefile.orig 2018-04-17 19:21:31.000000000 +0200 |+++ xen/Makefile 2018-04-23 13:29:47.000000000 +0200 -------------------------- Patching file xen/Makefile using Plan A... Hunk #1 succeeded at 167. done => Verifying /data/pkgsrc/sysutils/xenkernel411/patches/patch-xen_Rules.mk => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel411/patches/patch-xen_Rules.mk Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-xen_Rules.mk,v 1.1 2018/07/24 13:40:11 bouyer Exp $ | |--- xen/Rules.mk.orig 2018-04-23 14:50:02.000000000 +0200 |+++ xen/Rules.mk 2018-04-23 14:50:32.000000000 +0200 -------------------------- Patching file xen/Rules.mk using Plan A... Hunk #1 succeeded at 1. done => Verifying /data/pkgsrc/sysutils/xenkernel411/patches/patch-xen_arch_x86_Rules.mk => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel411/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 2018/07/24 13:40:11 bouyer Exp $ | |--- xen/arch/x86/Rules.mk.orig 2018-04-17 19:21:31.000000000 +0200 |+++ xen/arch/x86/Rules.mk 2018-04-23 13:31:24.000000000 +0200 -------------------------- Patching file xen/arch/x86/Rules.mk using Plan A... Hunk #1 succeeded at 8. done => Verifying /data/pkgsrc/sysutils/xenkernel411/patches/patch-xen_arch_x86_boot_build32.mk => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel411/patches/patch-xen_arch_x86_boot_build32.mk Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-xen_arch_x86_boot_build32.mk,v 1.1 2018/07/24 13:40:11 bouyer Exp $ |linux's toolchain doesn't generate a .eh_frame section but NetBSD does. |remove it. | |--- xen/arch/x86/boot/build32.mk.orig 2018-04-17 19:21:31.000000000 +0200 |+++ xen/arch/x86/boot/build32.mk 2018-04-23 13:29:47.000000000 +0200 -------------------------- Patching file xen/arch/x86/boot/build32.mk using Plan A... Hunk #1 succeeded at 25. done => Verifying /data/pkgsrc/sysutils/xenkernel411/patches/patch-xen_tools_symbols.c => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel411/patches/patch-xen_tools_symbols.c Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-xen_tools_symbols.c,v 1.1 2018/07/24 13:40:11 bouyer Exp $ |fix "error: array subscript has type 'char'" | |--- xen/tools/symbols.c.orig 2018-04-17 19:21:31.000000000 +0200 |+++ xen/tools/symbols.c 2018-04-23 13:29:47.000000000 +0200 -------------------------- Patching file xen/tools/symbols.c using Plan A... Hunk #1 succeeded at 173. done => Verifying /data/pkgsrc/sysutils/xenkernel411/patches/patch-zz-bouyer => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel411/patches/patch-zz-bouyer Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-zz-bouyer,v 1.3 2019/03/25 15:28:13 bouyer Exp $ |Dirty hack to avoid assert failure. This has been discussed on xen-devel |but no solution has been found so far. |The box producing http://www-soc.lip6.fr/~bouyer/NetBSD-tests/xen/ |is running with this patch; the printk has fired but the |hypervisor keeps running. | |--- xen/arch/x86/mm.c.orig 2018-07-19 10:32:07.000000000 +0200 |+++ xen/arch/x86/mm.c 2018-07-21 20:47:47.000000000 +0200 -------------------------- Patching file xen/arch/x86/mm.c using Plan A... Hunk #1 succeeded at 724 (offset 50 lines). done ===> Creating toolchain wrappers for xenkernel411-4.11.4nb1