=> Bootstrap dependency digest>=20010302: found digest-20180917 ===> 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 xen411/xen-4.11.0.tar.gz => Checksum RMD160 OK for xen411/xen-4.11.0.tar.gz => Checksum SHA512 OK for xen411/xen-4.11.0.tar.gz ===> Installing dependencies for xenkernel411-4.11.0nb1 ========================================================================== The following variables will affect the build process of this package, xenkernel411-4.11.0nb1. 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.2.1nb1 => Tool dependency checkperms>=1.1: found checkperms-1.12 => Build dependency python27>=2.7.1nb2: found python27-2.7.15nb1 => Build dependency cwrappers>=20150314: found cwrappers-20180325 ===> Overriding tools for xenkernel411-4.11.0nb1 ===> Extracting for xenkernel411-4.11.0nb1 ===> Patching for xenkernel411-4.11.0nb1 => Applying pkgsrc patches for xenkernel411-4.11.0nb1 => 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-XSA269 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel411/patches/patch-XSA269 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA269,v 1.1 2018/11/28 14:00:49 bouyer Exp $ | |From: Andrew Cooper |Subject: x86/vtx: Fix the checking for unknown/invalid MSR_DEBUGCTL bits | |The VPMU_MODE_OFF early-exit in vpmu_do_wrmsr() introduced by c/s |11fe998e56 bypasses all reserved bit checking in the general case. As a |result, a guest can enable BTS when it shouldn't be permitted to, and |lock up the entire host. | |With vPMU active (not a security supported configuration, but useful for |debugging), the reserved bit checking in broken, caused by the original |BTS changeset 1a8aa75ed. | |From a correctness standpoint, it is not possible to have two different |pieces of code responsible for different parts of value checking, if |there isn't an accumulation of bits which have been checked. A |practical upshot of this is that a guest can set any value it |wishes (usually resulting in a vmentry failure for bad guest state). | |Therefore, fix this by implementing all the reserved bit checking in the |main MSR_DEBUGCTL block, and removing all handling of DEBUGCTL from the |vPMU MSR logic. | |This is XSA-269 | |Signed-off-by: Andrew Cooper |Reviewed-by: Jan Beulich | |diff --git a/xen/arch/x86/cpu/vpmu_intel.c b/xen/arch/x86/cpu/vpmu_intel.c |index 207e2e7..d4444f0 100644 |--- xen/arch/x86/cpu/vpmu_intel.c.orig |+++ xen/arch/x86/cpu/vpmu_intel.c -------------------------- Patching file xen/arch/x86/cpu/vpmu_intel.c using Plan A... Hunk #1 succeeded at 535. 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/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c |index 9707514..ae028dd 100644 |--- 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 3036 (offset 4 lines). Hunk #2 succeeded at 3098 (offset 4 lines). done => Verifying /data/pkgsrc/sysutils/xenkernel411/patches/patch-XSA275-1 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel411/patches/patch-XSA275-1 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA275-1,v 1.1 2018/11/28 14:00:49 bouyer Exp $ | |From: Roger Pau Monné |Subject: amd/iommu: fix flush checks | |Flush checking for AMD IOMMU didn't check whether the previous entry |was present, or whether the flags (writable/readable) changed in order |to decide whether a flush should be executed. | |Fix this by taking the writable/readable/next-level fields into account, |together with the present bit. | |Along these lines the flushing in amd_iommu_map_page() must not be |omitted for PV domains. The comment there was simply wrong: Mappings may |very well change, both their addresses and their permissions. Ultimately |this should honor iommu_dont_flush_iotlb, but to achieve this |amd_iommu_ops first needs to gain an .iotlb_flush hook. | |Also make clear_iommu_pte_present() static, to demonstrate there's no |caller omitting the (subsequent) flush. | |This is part of XSA-275. | |Reported-by: Paul Durrant |Signed-off-by: Roger Pau Monné |Signed-off-by: Jan Beulich | |--- xen/drivers/passthrough/amd/iommu_map.c.orig |+++ xen/drivers/passthrough/amd/iommu_map.c -------------------------- Patching file xen/drivers/passthrough/amd/iommu_map.c using Plan A... Hunk #1 succeeded at 35. Hunk #2 succeeded at 49. Hunk #3 succeeded at 706. done => Verifying /data/pkgsrc/sysutils/xenkernel411/patches/patch-XSA275-2 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel411/patches/patch-XSA275-2 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA275-2,v 1.1 2018/11/28 14:00:49 bouyer Exp $ | |From: Jan Beulich |Subject: AMD/IOMMU: suppress PTE merging after initial table creation | |The logic is not fit for this purpose, so simply disable its use until |it can be fixed / replaced. Note that this re-enables merging for the |table creation case, which was disabled as a (perhaps unintended) side |effect of the earlier "amd/iommu: fix flush checks". It relies on no |page getting mapped more than once (with different properties) in this |process, as that would still be beyond what the merging logic can cope |with. But arch_iommu_populate_page_table() guarantees this afaict. | |This is part of XSA-275. | |Reported-by: Paul Durrant |Signed-off-by: Jan Beulich | |--- xen/drivers/passthrough/amd/iommu_map.c.orig |+++ xen/drivers/passthrough/amd/iommu_map.c -------------------------- Patching file xen/drivers/passthrough/amd/iommu_map.c using Plan A... Hunk #1 succeeded at 702. Hunk #2 succeeded at 793. 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 40. done => Verifying /data/pkgsrc/sysutils/xenkernel411/patches/patch-XSA276-1 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel411/patches/patch-XSA276-1 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA276-1,v 1.1 2018/11/28 14:00:49 bouyer Exp $ | |From bcc115ba39d2985dcf356ba8a9ac291e314f1f0f Mon Sep 17 00:00:00 2001 |From: Jan Beulich |Date: Thu, 11 Oct 2018 04:00:26 -0600 |Subject: [PATCH 1/2] x86/hvm/ioreq: fix page referencing | |The code does not take a page reference in hvm_alloc_ioreq_mfn(), only a |type reference. This can lead to a situation where a malicious domain with |XSM_DM_PRIV can engineer a sequence as follows: | |- create IOREQ server: no pages as yet. |- acquire resource: page allocated, total 0. |- decrease reservation: -1 ref, total -1. | |This will cause Xen to hit a BUG_ON() in free_domheap_pages(). | |This patch fixes the issue by changing the call to get_page_type() in |hvm_alloc_ioreq_mfn() to a call to get_page_and_type(). This change |in turn requires an extra put_page() in hvm_free_ioreq_mfn() in the case |that _PGC_allocated is still set (i.e. a decrease reservation has not |occurred) to avoid the page being leaked. | |This is part of XSA-276. | |Reported-by: Julien Grall |Reported-by: Julien Grall |Signed-off-by: Paul Durrant |Signed-off-by: Jan Beulich |--- | xen/arch/x86/hvm/ioreq.c | 46 +++++++++++++++++++++++++++------------- | 1 file changed, 31 insertions(+), 15 deletions(-) | |diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c |index f39f391929..bdc2687014 100644 |--- xen/arch/x86/hvm/ioreq.c.orig |+++ xen/arch/x86/hvm/ioreq.c -------------------------- Patching file xen/arch/x86/hvm/ioreq.c using Plan A... Hunk #1 succeeded at 327. Hunk #2 succeeded at 350. Hunk #3 succeeded at 384. Hmm... Ignoring the trailing garbage. done => Verifying /data/pkgsrc/sysutils/xenkernel411/patches/patch-XSA276-2 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel411/patches/patch-XSA276-2 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA276-2,v 1.1 2018/11/28 14:00:49 bouyer Exp $ | |From 0bb2969630fbc92a0510bf120578b58efb74cdab Mon Sep 17 00:00:00 2001 |From: Paul Durrant |Date: Thu, 1 Nov 2018 17:30:20 +0000 |Subject: [PATCH 2/2] x86/hvm/ioreq: use ref-counted target-assigned shared | pages | |Passing MEMF_no_refcount to alloc_domheap_pages() will allocate, as |expected, a page that is assigned to the specified domain but is not |accounted for in tot_pages. Unfortunately there is no logic for tracking |such allocations and avoiding any adjustment to tot_pages when the page |is freed. | |The only caller of alloc_domheap_pages() that passes MEMF_no_refcount is |hvm_alloc_ioreq_mfn() so this patch removes use of the flag from that |call-site to avoid the possibility of a domain using an ioreq server as |a means to adjust its tot_pages and hence allocate more memory than it |should be able to. | |However, the reason for using the flag in the first place was to avoid |the allocation failing if the emulator domain is already at its maximum |memory limit. Hence this patch switches to allocating memory from the |target domain instead of the emulator domain. There is already an extra |memory allowance of 2MB (LIBXL_HVM_EXTRA_MEMORY) applied to HVM guests, |which is sufficient to cover the pages required by the supported |configuration of a single IOREQ server for QEMU. (Stub-domains do not, |so far, use resource mapping). It also also the case the QEMU will have |mapped the IOREQ server pages before the guest boots, hence it is not |possible for the guest to inflate its balloon to consume these pages. | |Reported-by: Julien Grall |Signed-off-by: Paul Durrant |--- | xen/arch/x86/hvm/ioreq.c | 12 ++---------- | xen/arch/x86/mm.c | 6 ------ | 2 files changed, 2 insertions(+), 16 deletions(-) | |diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c |index bdc2687014..fd10ee6146 100644 |--- xen/arch/x86/hvm/ioreq.c.orig |+++ xen/arch/x86/hvm/ioreq.c -------------------------- Patching file xen/arch/x86/hvm/ioreq.c using Plan A... Hunk #1 succeeded at 342. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c |index 7d4871b791..24b215d785 100644 |--- xen/arch/x86/mm.c.orig |+++ xen/arch/x86/mm.c -------------------------- Patching file xen/arch/x86/mm.c using Plan A... Hunk #1 succeeded at 4333 (offset -63 lines). Hmm... Ignoring the trailing garbage. done => Verifying /data/pkgsrc/sysutils/xenkernel411/patches/patch-XSA277 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel411/patches/patch-XSA277 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA277,v 1.1 2018/11/28 14:00:49 bouyer Exp $ | |From: Andrew Cooper |Subject: x86/mm: Put the gfn on all paths after get_gfn_query() | |c/s 7867181b2 "x86/PoD: correctly handle non-order-0 decrease-reservation |requests" introduced an early exit in guest_remove_page() for unexpected p2m |types. However, get_gfn_query() internally takes the p2m lock, and must be |matched with a put_gfn() call later. | |Fix the erroneous comment beside the declaration of get_gfn_query(). | |This is XSA-277. | |Reported-by: Paul Durrant |Signed-off-by: Andrew Cooper | |diff --git a/xen/common/memory.c b/xen/common/memory.c |index 987395f..26b7123 100644 |--- xen/common/memory.c.orig |+++ xen/common/memory.c -------------------------- Patching file xen/common/memory.c using Plan A... Hunk #1 succeeded at 303 (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/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h |index ac33f50..6d849a5 100644 |--- xen/include/asm-x86/p2m.h.orig |+++ xen/include/asm-x86/p2m.h -------------------------- Patching file xen/include/asm-x86/p2m.h using Plan A... Hunk #1 succeeded at 432 (offset -16 lines). done => Verifying /data/pkgsrc/sysutils/xenkernel411/patches/patch-XSA278 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel411/patches/patch-XSA278 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA278,v 1.1 2018/11/28 14:00:49 bouyer Exp $ | |From: Andrew Cooper |Subject: x86/vvmx: Disallow the use of VT-x instructions when nested virt is disabled | |c/s ac6a4500b "vvmx: set vmxon_region_pa of vcpu out of VMX operation to an |invalid address" was a real bugfix as described, but has a very subtle bug |which results in all VT-x instructions being usable by a guest. | |The toolstack constructs a guest by issuing: | | XEN_DOMCTL_createdomain | XEN_DOMCTL_max_vcpus | |and optionally later, HVMOP_set_param to enable nested virt. | |As a result, the call to nvmx_vcpu_initialise() in hvm_vcpu_initialise() |(which is what makes the above patch look correct during review) is actually |dead code. In practice, nvmx_vcpu_initialise() first gets called when nested |virt is enabled, which is typically never. | |As a result, the zeroed memory of struct vcpu causes nvmx_vcpu_in_vmx() to |return true before nested virt is enabled for the guest. | |Fixing the order of initialisation is a work in progress for other reasons, |but not viable for security backports. | |A compounding factor is that the vmexit handlers for all instructions, other |than VMXON, pass 0 into vmx_inst_check_privilege()'s vmxop_check parameter, |which skips the CR4.VMXE check. (This is one of many reasons why nested virt |isn't a supported feature yet.) | |However, the overall result is that when nested virt is not enabled by the |toolstack (i.e. the default configuration for all production guests), the VT-x |instructions (other than VMXON) are actually usable, and Xen very quickly |falls over the fact that the nvmx structure is uninitialised. | |In order to fail safe in the supported case, re-implement all the VT-x |instruction handling using a single function with a common prologue, covering |all the checks which should cause #UD or #GP faults. This deliberately |doesn't use any state from the nvmx structure, in case there are other lurking |issues. | |This is XSA-278 | |Reported-by: Sergey Dyasli |Signed-off-by: Andrew Cooper |Reviewed-by: Sergey Dyasli | |diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c |index a6415f0..a4d2829 100644 |--- 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 3941 (offset -41 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/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c |index e97db33..88cb58c 100644 |--- xen/arch/x86/hvm/vmx/vvmx.c.orig |+++ xen/arch/x86/hvm/vmx/vvmx.c -------------------------- Patching file xen/arch/x86/hvm/vmx/vvmx.c using Plan A... Hunk #1 succeeded at 1470. Hunk #2 succeeded at 1522. Hunk #3 succeeded at 1611. Hunk #4 succeeded at 1645. Hunk #5 succeeded at 1688. Hunk #6 succeeded at 1759. Hunk #7 succeeded at 1784. Hunk #8 succeeded at 1836. Hunk #9 succeeded at 1878. Hunk #10 succeeded at 1926. Hunk #11 succeeded at 1954. Hunk #12 succeeded at 1980. 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/hvm/vmx/vvmx.h b/xen/include/asm-x86/hvm/vmx/vvmx.h |index 9ea35eb..fc4a8d1 100644 |--- xen/include/asm-x86/hvm/vmx/vvmx.h.orig |+++ xen/include/asm-x86/hvm/vmx/vvmx.h -------------------------- Patching file xen/include/asm-x86/hvm/vmx/vvmx.h using Plan A... Hunk #1 succeeded at 94. Hunk #2 succeeded at 188. done => Verifying /data/pkgsrc/sysutils/xenkernel411/patches/patch-XSA279 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel411/patches/patch-XSA279 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA279,v 1.1 2018/11/28 14:00:49 bouyer Exp $ | |From: Andrew Cooper |Subject: x86/mm: Don't perform flush after failing to update a guests L1e | |If the L1e update hasn't occured, the flush cannot do anything useful. This |skips the potentially expensive vcpumask_to_pcpumask() conversion, and |broadcast TLB shootdown. | |More importantly however, we might be in the error path due to a bad va |parameter from the guest, and this should not propagate into the TLB flushing |logic. The INVPCID instruction for example raises #GP for a non-canonical |address. | |This is XSA-279. | |Reported-by: Matthew Daley |Signed-off-by: Andrew Cooper |Reviewed-by: Jan Beulich | |diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c |index 703f330..75663c6 100644 |--- xen/arch/x86/mm.c.orig |+++ xen/arch/x86/mm.c -------------------------- Patching file xen/arch/x86/mm.c using Plan A... Hunk #1 succeeded at 4072 (offset -83 lines). done => Verifying /data/pkgsrc/sysutils/xenkernel411/patches/patch-XSA280-1 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel411/patches/patch-XSA280-1 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA280-1,v 1.1 2018/11/28 14:00:49 bouyer Exp $ | |From: Jan Beulich |Subject: x86/shadow: move OOS flag bit positions | |In preparation of reducing struct page_info's shadow_flags field to 16 |bits, lower the bit positions used for SHF_out_of_sync and |SHF_oos_may_write. | |Instead of also adjusting the open coded use in _get_page_type(), |introduce shadow_prepare_page_type_change() to contain knowledge of the |bit positions to shadow code. | |This is part of XSA-280. | |Signed-off-by: Jan Beulich |Reviewed-by: Tim Deegan |--- |v2: Rename function and pass full type. | |--- xen/arch/x86/mm.c.orig |+++ xen/arch/x86/mm.c -------------------------- Patching file xen/arch/x86/mm.c using Plan A... Hunk #1 succeeded at 2631 (offset -81 lines). Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- 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 988 (offset 239 lines). Hunk #2 succeeded at 2692 (offset 276 lines). Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- xen/arch/x86/mm/shadow/private.h.orig |+++ xen/arch/x86/mm/shadow/private.h -------------------------- Patching file xen/arch/x86/mm/shadow/private.h using Plan A... Hunk #1 succeeded at 287 (offset 2 lines). Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- xen/include/asm-x86/shadow.h.orig |+++ xen/include/asm-x86/shadow.h -------------------------- Patching file xen/include/asm-x86/shadow.h using Plan A... Hunk #1 succeeded at 80 (offset -1 lines). Hunk #2 succeeded at 108 (offset -1 lines). done => Verifying /data/pkgsrc/sysutils/xenkernel411/patches/patch-XSA280-2 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel411/patches/patch-XSA280-2 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA280-2,v 1.1 2018/11/28 14:00:49 bouyer Exp $ | |From: Jan Beulich |Subject: x86/shadow: shrink struct page_info's shadow_flags to 16 bits | |This is to avoid it overlapping the linear_pt_count field needed for PV |domains. Introduce a separate, HVM-only pagetable_dying field to replace |the sole one left in the upper 16 bits. | |Note that the accesses to ->shadow_flags in shadow_{pro,de}mote() get |switched to non-atomic, non-bitops operations, as {test,set,clear}_bit() |are not allowed on uint16_t fields and hence their use would have |required ugly casts. This is fine because all updates of the field ought |to occur with the paging lock held, and other updates of it use |= and |&= as well (i.e. using atomic operations here didn't really guard |against potentially racing updates elsewhere). | |This is part of XSA-280. | |Reported-by: Prgmr.com Security |Signed-off-by: Jan Beulich |Reviewed-by: Tim Deegan | |--- 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 1026 (offset -2 lines). Hunk #2 succeeded at 1042 (offset -2 lines). Hunk #3 succeeded at 2923 (offset -2 lines). Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- xen/arch/x86/mm/shadow/multi.c.orig |+++ xen/arch/x86/mm/shadow/multi.c -------------------------- Patching file xen/arch/x86/mm/shadow/multi.c using Plan A... Hunk #1 succeeded at 3299. Hunk #2 succeeded at 4254. Hunk #3 succeeded at 4572. Hunk #4 succeeded at 4612. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- xen/arch/x86/mm/shadow/private.h.orig |+++ xen/arch/x86/mm/shadow/private.h -------------------------- Patching file xen/arch/x86/mm/shadow/private.h using Plan A... Hunk #1 succeeded at 292. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- xen/include/asm-x86/mm.h.orig |+++ xen/include/asm-x86/mm.h -------------------------- Patching file xen/include/asm-x86/mm.h using Plan A... Hunk #1 succeeded at 259. done => Verifying /data/pkgsrc/sysutils/xenkernel411/patches/patch-XSA282-1 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel411/patches/patch-XSA282-1 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA282-1,v 1.1 2018/11/28 14:00:49 bouyer Exp $ | |From: Jan Beulich |Subject: x86: extend get_platform_badpages() interface | |Use a structure so along with an address (now frame number) an order can |also be specified. | |This is part of XSA-282. | |Signed-off-by: Jan Beulich |Reviewed-by: Andrew Cooper | |--- xen/arch/x86/guest/xen.c.orig |+++ xen/arch/x86/guest/xen.c -------------------------- Patching file xen/arch/x86/guest/xen.c using Plan A... Hunk #1 succeeded at 40. Hunk #2 succeeded at 326. Hunk #3 succeeded at 334. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- xen/arch/x86/mm.c.orig |+++ xen/arch/x86/mm.c -------------------------- Patching file xen/arch/x86/mm.c using Plan A... No such line 5767 in input file, ignoring Hunk #1 succeeded at 5699 (offset -69 lines). Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- xen/common/page_alloc.c.orig |+++ xen/common/page_alloc.c -------------------------- Patching file xen/common/page_alloc.c using Plan A... Hunk #1 succeeded at 270. Hunk #2 succeeded at 299. Hunk #3 succeeded at 312. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- xen/include/asm-x86/guest/xen.h.orig |+++ xen/include/asm-x86/guest/xen.h -------------------------- Patching file xen/include/asm-x86/guest/xen.h using Plan A... Hunk #1 succeeded at 37. Hunk #2 succeeded at 65. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- xen/include/asm-x86/mm.h.orig |+++ xen/include/asm-x86/mm.h -------------------------- Patching file xen/include/asm-x86/mm.h using Plan A... Hunk #1 succeeded at 348. done => Verifying /data/pkgsrc/sysutils/xenkernel411/patches/patch-XSA282-2 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel411/patches/patch-XSA282-2 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA282-2,v 1.1 2018/11/28 14:00:49 bouyer Exp $ | |From: Jan Beulich |Subject: x86: work around HLE host lockup erratum | |XACQUIRE prefixed accesses to the 4Mb range of memory starting at 1Gb |are liable to lock up the processor. Disallow use of this memory range. | |Unfortunately the available Core Gen7 and Gen8 spec updates are pretty |old, so I can only guess that they're similarly affected when Core Gen6 |is and the Xeon counterparts are, too. | |This is part of XSA-282. | |Signed-off-by: Jan Beulich |Reviewed-by: Andrew Cooper |--- |v2: Don't apply the workaround when running ourselves virtualized. | |--- xen/arch/x86/mm.c.orig |+++ xen/arch/x86/mm.c -------------------------- Patching file xen/arch/x86/mm.c using Plan A... No such line 5852 in input file, ignoring Hunk #1 succeeded at 5709 (offset -144 lines). 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-JBeulich => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel411/patches/patch-zz-JBeulich Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-zz-JBeulich,v 1.1 2018/07/24 13:40:11 bouyer Exp $ | |x86: further avoid setting TLB flush time stamp | |NetBSD's use of linear page tables in 32-bit mode exposes an issue with |us still storing TLB flush time stamps too early, corrupting the |linear_pt_count field living in the same union. Since we go that path |(for page tables) only when neither PGT_validated nor PGT_partial are |set on a page, we don't really require a flush to happen (see also the |code comment), yet we're also no concerned if one happens which isn't |needed (which might occur when we never write the time stamp). | |Reported-by: Manuel Bouyer |Signed-off-by: Jan Beulich | |--- ./xen/arch/x86/mm.c.orig 2018-07-09 15:47:19.000000000 +0200 |+++ ./xen/arch/x86/mm.c 2018-07-16 12:38:47.000000000 +0200 -------------------------- Patching file ./xen/arch/x86/mm.c using Plan A... Hunk #1 succeeded at 2538. Hunk #2 succeeded at 2569. 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.1 2018/07/24 13:40:11 bouyer Exp $ |Dirty hack to avoid assert failure. This has been discussed on xen-devel |but no solution has been fonud 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 674. done ===> Creating toolchain wrappers for xenkernel411-4.11.0nb1