=> Bootstrap dependency digest>=20010302: found digest-20190127 => Checksum SHA1 OK for xen413/xen-4.13.1.tar.gz => Checksum RMD160 OK for xen413/xen-4.13.1.tar.gz => Checksum SHA512 OK for xen413/xen-4.13.1.tar.gz ===> Installing dependencies for xenkernel413-4.13.1nb1 ========================================================================== The following variables will affect the build process of this package, xenkernel413-4.13.1nb1. Their current value is shown below: * PYTHON_VERSION_DEFAULT = 37 Based on these variables, the following variables have been set: * PYPACKAGE = python37 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 python37>=3.7.0: found python37-3.7.9nb1 => 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 xenkernel413-4.13.1nb1 ===> Extracting for xenkernel413-4.13.1nb1 ===> Patching for xenkernel413-4.13.1nb1 => Applying pkgsrc patches for xenkernel413-4.13.1nb1 => Verifying /data/pkgsrc/sysutils/xenkernel413/patches/patch-Config.mk => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel413/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 2020/05/26 11:12:10 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/xenkernel413/patches/patch-XSA317 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel413/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:56:47 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/xenkernel413/patches/patch-XSA319 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel413/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:56:47 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 3249 (offset -3 lines). done => Verifying /data/pkgsrc/sysutils/xenkernel413/patches/patch-XSA320 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel413/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:56:47 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.pandoc b/docs/misc/xen-command-line.pandoc |index 1d9d816622..9268454297 100644 |--- docs/misc/xen-command-line.pandoc.orig |+++ docs/misc/xen-command-line.pandoc -------------------------- Patching file docs/misc/xen-command-line.pandoc using Plan A... Hunk #1 succeeded at 483. 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 6cea4227ba..a78f08b927 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 213. 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 603e1d65fd..a09440813b 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 157. 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 4b12103482..0cded3c0ad 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 134. Hunk #2 succeeded at 289. 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 6656c44aec..5fc1c6827e 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 312. 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 7693c4a71a..91994669e1 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 179. 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 2835688f1c..a2482c3627 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 252. 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.pandoc b/docs/misc/xen-command-line.pandoc |index 9268454297..c780312531 100644 |--- docs/misc/xen-command-line.pandoc.orig |+++ docs/misc/xen-command-line.pandoc -------------------------- Patching file docs/misc/xen-command-line.pandoc using Plan A... Hunk #1 succeeded at 1991. Hunk #2 succeeded at 2068. 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 feb0f6ce20..75c6e34164 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 295. 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 dc8fdac1a1..b1e51b3aff 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 361. 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 5fc1c6827e..33343062a7 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 65. Hunk #2 succeeded at 115. Hunk #3 succeeded at 182. Hunk #4 succeeded at 347. Hunk #5 succeeded at 358. Hunk #6 succeeded at 1157. Hunk #7 succeeded at 1216. 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 9caecddfec..b252bb8631 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 54. 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: Update docs with SRBDS workaround | |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.pandoc b/docs/misc/xen-command-line.pandoc |index c780312531..81e12d053c 100644 |--- docs/misc/xen-command-line.pandoc.orig |+++ docs/misc/xen-command-line.pandoc -------------------------- Patching file docs/misc/xen-command-line.pandoc using Plan A... Hunk #1 succeeded at 481. done => Verifying /data/pkgsrc/sysutils/xenkernel413/patches/patch-XSA321 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel413/patches/patch-XSA321 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA321,v 1.1 2020/07/16 09:56:47 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 570. 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 43. 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 230. Hunk #2 succeeded at 406. Hunk #3 succeeded at 695. 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 140. Hunk #2 succeeded at 156. Hunk #3 succeeded at 174. Hunk #4 succeeded at 207. Hunk #5 succeeded at 254. Hunk #6 succeeded at 631. Hunk #7 succeeded at 670. Hunk #8 succeeded at 1391. Hunk #9 succeeded at 1555. Hunk #10 succeeded at 1782. Hunk #11 succeeded at 1857. Hunk #12 succeeded at 2715. 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 43. 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 141. Hunk #2 succeeded at 174. Hunk #3 succeeded at 2763. 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 121. 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 250. 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 143. Hunk #2 succeeded at 152. 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 114. 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 68. 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 155. 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 51. 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 58. Hunk #2 succeeded at 293 (offset 2 lines). Hunk #3 succeeded at 837 (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 1884. 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 97. done => Verifying /data/pkgsrc/sysutils/xenkernel413/patches/patch-XSA328 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel413/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:56:47 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 200 (offset 13 lines). Hunk #2 succeeded at 210 (offset 13 lines). Hunk #3 succeeded at 227 (offset 13 lines). Hunk #4 succeeded at 265 (offset 13 lines). Hunk #5 succeeded at 279 (offset 13 lines). Hunk #6 succeeded at 307 (offset 3 lines). Hunk #7 succeeded at 342 (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 323 (offset 16 lines). Hunk #2 succeeded at 341 (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 XSA-328 |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 369 (offset 16 lines). done => Verifying /data/pkgsrc/sysutils/xenkernel413/patches/patch-xen_Makefile => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel413/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 2020/05/26 11:12:10 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 174 (offset 7 lines). done => Verifying /data/pkgsrc/sysutils/xenkernel413/patches/patch-xen_Rules.mk => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel413/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 2020/05/26 11:12:10 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/xenkernel413/patches/patch-xen_arch_x86_Rules.mk => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel413/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 2020/05/26 11:12:10 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/xenkernel413/patches/patch-xen_arch_x86_boot_build32.mk => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel413/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 2020/05/26 11:12:10 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/xenkernel413/patches/patch-xen_arch_x86_mm_p2m.c => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel413/patches/patch-xen_arch_x86_mm_p2m.c Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-xen_arch_x86_mm_p2m.c,v 1.1 2020/05/26 11:12:10 bouyer Exp $ | |silent a noisy warning | |--- xen/arch/x86/mm/p2m.c.orig 2020-05-03 21:13:56.173269058 +0200 |+++ xen/arch/x86/mm/p2m.c 2020-05-03 21:15:38.477174874 +0200 -------------------------- Patching file xen/arch/x86/mm/p2m.c using Plan A... Hunk #1 succeeded at 1367. done => Verifying /data/pkgsrc/sysutils/xenkernel413/patches/patch-xen_drivers_passthrough_x86_iommu.c => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel413/patches/patch-xen_drivers_passthrough_x86_iommu.c Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-xen_drivers_passthrough_x86_iommu.c,v 1.1 2020/05/26 11:12:10 bouyer Exp $ | |Silent noisy warning | |--- xen/drivers/passthrough/x86/iommu.c.orig 2020-05-03 22:03:37.840754709 +0200 |+++ xen/drivers/passthrough/x86/iommu.c 2020-05-03 22:04:36.676914512 +0200 -------------------------- Patching file xen/drivers/passthrough/x86/iommu.c using Plan A... Hunk #1 succeeded at 234. done => Verifying /data/pkgsrc/sysutils/xenkernel413/patches/patch-xen_tools_symbols.c => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel413/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 2020/05/26 11:12:10 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 ===> Creating toolchain wrappers for xenkernel413-4.13.1nb1