xen-4.4.1-1.parabola1: updating version

1 files changed, 0 insertions, 36 deletions

diff --git a/kernels/xen/xsa92.patch b/kernels/xen/xsa92.patch
deleted file mode 100644
index 60ef934aa..000000000
--- a/kernels/xen/xsa92.patch
+++ /dev/null
@@ -1,36 +0,0 @@
-x86/HVM: restrict HVMOP_set_mem_type
-
-Permitting arbitrary type changes here has the potential of creating
-present P2M (and hence EPT/NPT/IOMMU) entries pointing to an invalid
-MFN (INVALID_MFN truncated to the respective hardware structure field's
-width). This would become a problem the latest when something real sat
-at the end of the physical address space; I'm suspecting though that
-other things might break with such bogus entries.
-
-Along with that drop a bogus (and otherwise becoming stale) log
-message.
-
-Afaict the similar operation in p2m_set_mem_access() is safe.
-
-This is XSA-92.
-
-Signed-off-by: Jan Beulich <jbeulich@suse.com>
-Reviewed-by: Tim Deegan <tim@xen.org>
-
---- a/xen/arch/x86/hvm/hvm.c
-+++ b/xen/arch/x86/hvm/hvm.c
-@@ -4541,12 +4541,10 @@ long do_hvm_op(unsigned long op, XEN_GUE
-                 rc = -EINVAL;
-                 goto param_fail4;
-             } 
--            if ( p2m_is_grant(t) )
-+            if ( !p2m_is_ram(t) &&
-+                 (!p2m_is_hole(t) || a.hvmmem_type != HVMMEM_mmio_dm) )
-             {
-                 put_gfn(d, pfn);
--                gdprintk(XENLOG_WARNING,
--                         "type for pfn %#lx changed to grant while "
--                         "we were working?\n", pfn);
-                 goto param_fail4;
-             }
-             else