Sync from SUSE:SLFO:Main xen revision bafde79b448f1d38f9192167f72cc0ee
This commit is contained in:
parent
e0da5782bf
commit
e9f0e797ec
@ -1,31 +0,0 @@
|
||||
# Commit 26a449ce32cef33f2cb50602be19fcc0c4223ba9
|
||||
# Date 2023-11-02 10:50:26 +0100
|
||||
# Author Roger Pau Monné <roger.pau@citrix.com>
|
||||
# Committer Jan Beulich <jbeulich@suse.com>
|
||||
x86/x2apic: remove usage of ACPI_FADT_APIC_CLUSTER
|
||||
|
||||
The ACPI FADT APIC_CLUSTER flag mandates that when the interrupt delivery is
|
||||
Logical mode APIC must be configured for Cluster destination model. However in
|
||||
apic_x2apic_probe() such flag is incorrectly used to gate whether Physical mode
|
||||
can be used.
|
||||
|
||||
Since Xen when in x2APIC mode only uses Logical mode together with Cluster
|
||||
model completely remove checking for ACPI_FADT_APIC_CLUSTER, as Xen always
|
||||
fulfills the requirement signaled by the flag.
|
||||
|
||||
Fixes: eb40ae41b658 ('x86/Kconfig: add option for default x2APIC destination mode')
|
||||
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
|
||||
Reviewed-by: Jan Beulich <jbeulich@suse.com>
|
||||
|
||||
--- a/xen/arch/x86/genapic/x2apic.c
|
||||
+++ b/xen/arch/x86/genapic/x2apic.c
|
||||
@@ -231,8 +231,7 @@ const struct genapic *__init apic_x2apic
|
||||
*/
|
||||
x2apic_phys = iommu_intremap != iommu_intremap_full ||
|
||||
(acpi_gbl_FADT.flags & ACPI_FADT_APIC_PHYSICAL) ||
|
||||
- (IS_ENABLED(CONFIG_X2APIC_PHYSICAL) &&
|
||||
- !(acpi_gbl_FADT.flags & ACPI_FADT_APIC_CLUSTER));
|
||||
+ IS_ENABLED(CONFIG_X2APIC_PHYSICAL);
|
||||
}
|
||||
else if ( !x2apic_phys )
|
||||
switch ( iommu_intremap )
|
||||
@ -1,103 +0,0 @@
|
||||
# Commit 87f37449d586b4d407b75235bb0a171e018e25ec
|
||||
# Date 2023-11-02 10:50:59 +0100
|
||||
# Author Roger Pau Monné <roger.pau@citrix.com>
|
||||
# Committer Jan Beulich <jbeulich@suse.com>
|
||||
x86/i8259: do not assume interrupts always target CPU0
|
||||
|
||||
Sporadically we have seen the following during AP bringup on AMD platforms
|
||||
only:
|
||||
|
||||
microcode: CPU59 updated from revision 0x830107a to 0x830107a, date = 2023-05-17
|
||||
microcode: CPU60 updated from revision 0x830104d to 0x830107a, date = 2023-05-17
|
||||
CPU60: No irq handler for vector 27 (IRQ -2147483648)
|
||||
microcode: CPU61 updated from revision 0x830107a to 0x830107a, date = 2023-05-17
|
||||
|
||||
This is similar to the issue raised on Linux commit 36e9e1eab777e, where they
|
||||
observed i8259 (active) vectors getting delivered to CPUs different than 0.
|
||||
|
||||
On AMD or Hygon platforms adjust the target CPU mask of i8259 interrupt
|
||||
descriptors to contain all possible CPUs, so that APs will reserve the vector
|
||||
at startup if any legacy IRQ is still delivered through the i8259. Note that
|
||||
if the IO-APIC takes over those interrupt descriptors the CPU mask will be
|
||||
reset.
|
||||
|
||||
Spurious i8259 interrupt vectors however (IRQ7 and IRQ15) can be injected even
|
||||
when all i8259 pins are masked, and hence would need to be handled on all CPUs.
|
||||
|
||||
Continue to reserve PIC vectors on CPU0 only, but do check for such spurious
|
||||
interrupts on all CPUs if the vendor is AMD or Hygon. Note that once the
|
||||
vectors get used by devices detecting PIC spurious interrupts will no longer be
|
||||
possible, however the device driver should be able to cope with spurious
|
||||
interrupts. Such PIC spurious interrupts occurring when the vector is in use
|
||||
by a local APIC routed source will lead to an extra EOI, which might
|
||||
unintentionally clear a different vector from ISR. Note this is already the
|
||||
current behavior, so assume it's infrequent enough to not cause real issues.
|
||||
|
||||
Finally, adjust the printed message to display the CPU where the spurious
|
||||
interrupt has been received, so it looks like:
|
||||
|
||||
microcode: CPU1 updated from revision 0x830107a to 0x830107a, date = 2023-05-17
|
||||
cpu1: spurious 8259A interrupt: IRQ7
|
||||
microcode: CPU2 updated from revision 0x830104d to 0x830107a, date = 2023-05-17
|
||||
|
||||
Amends: 3fba06ba9f8b ('x86/IRQ: re-use legacy vector ranges on APs')
|
||||
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
|
||||
Reviewed-by: Jan Beulich <jbeulich@suse.com>
|
||||
|
||||
--- a/xen/arch/x86/i8259.c
|
||||
+++ b/xen/arch/x86/i8259.c
|
||||
@@ -222,7 +222,8 @@ static bool _mask_and_ack_8259A_irq(unsi
|
||||
is_real_irq = false;
|
||||
/* Report spurious IRQ, once per IRQ line. */
|
||||
if (!(spurious_irq_mask & irqmask)) {
|
||||
- printk("spurious 8259A interrupt: IRQ%d.\n", irq);
|
||||
+ printk("cpu%u: spurious 8259A interrupt: IRQ%u\n",
|
||||
+ smp_processor_id(), irq);
|
||||
spurious_irq_mask |= irqmask;
|
||||
}
|
||||
/*
|
||||
@@ -349,7 +350,23 @@ void __init init_IRQ(void)
|
||||
continue;
|
||||
desc->handler = &i8259A_irq_type;
|
||||
per_cpu(vector_irq, cpu)[LEGACY_VECTOR(irq)] = irq;
|
||||
- cpumask_copy(desc->arch.cpu_mask, cpumask_of(cpu));
|
||||
+
|
||||
+ /*
|
||||
+ * The interrupt affinity logic never targets interrupts to offline
|
||||
+ * CPUs, hence it's safe to use cpumask_all here.
|
||||
+ *
|
||||
+ * Legacy PIC interrupts are only targeted to CPU0, but depending on
|
||||
+ * the platform they can be distributed to any online CPU in hardware.
|
||||
+ * Note this behavior has only been observed on AMD hardware. In order
|
||||
+ * to cope install all active legacy vectors on all CPUs.
|
||||
+ *
|
||||
+ * IO-APIC will change the destination mask if/when taking ownership of
|
||||
+ * the interrupt.
|
||||
+ */
|
||||
+ cpumask_copy(desc->arch.cpu_mask,
|
||||
+ (boot_cpu_data.x86_vendor &
|
||||
+ (X86_VENDOR_AMD | X86_VENDOR_HYGON) ? &cpumask_all
|
||||
+ : cpumask_of(cpu)));
|
||||
desc->arch.vector = LEGACY_VECTOR(irq);
|
||||
}
|
||||
|
||||
--- a/xen/arch/x86/irq.c
|
||||
+++ b/xen/arch/x86/irq.c
|
||||
@@ -1920,7 +1920,16 @@ void do_IRQ(struct cpu_user_regs *regs)
|
||||
kind = "";
|
||||
if ( !(vector >= FIRST_LEGACY_VECTOR &&
|
||||
vector <= LAST_LEGACY_VECTOR &&
|
||||
- !smp_processor_id() &&
|
||||
+ (!smp_processor_id() ||
|
||||
+ /*
|
||||
+ * For AMD/Hygon do spurious PIC interrupt
|
||||
+ * detection on all CPUs, as it has been observed
|
||||
+ * that during unknown circumstances spurious PIC
|
||||
+ * interrupts have been delivered to CPUs
|
||||
+ * different than the BSP.
|
||||
+ */
|
||||
+ (boot_cpu_data.x86_vendor & (X86_VENDOR_AMD |
|
||||
+ X86_VENDOR_HYGON))) &&
|
||||
bogus_8259A_irq(vector - FIRST_LEGACY_VECTOR)) )
|
||||
{
|
||||
printk("CPU%u: No irq handler for vector %02x (IRQ %d%s)\n",
|
||||
@ -1,70 +0,0 @@
|
||||
# Commit 4709ec82917668c2df958ef91b4f21c049c76bee
|
||||
# Date 2023-11-20 10:49:29 +0100
|
||||
# Author Juergen Gross <jgross@suse.com>
|
||||
# Committer Jan Beulich <jbeulich@suse.com>
|
||||
xen/sched: fix sched_move_domain()
|
||||
|
||||
When moving a domain out of a cpupool running with the credit2
|
||||
scheduler and having multiple run-queues, the following ASSERT() can
|
||||
be observed:
|
||||
|
||||
(XEN) Xen call trace:
|
||||
(XEN) [<ffff82d04023a700>] R credit2.c#csched2_unit_remove+0xe3/0xe7
|
||||
(XEN) [<ffff82d040246adb>] S sched_move_domain+0x2f3/0x5b1
|
||||
(XEN) [<ffff82d040234cf7>] S cpupool.c#cpupool_move_domain_locked+0x1d/0x3b
|
||||
(XEN) [<ffff82d040236025>] S cpupool_move_domain+0x24/0x35
|
||||
(XEN) [<ffff82d040206513>] S domain_kill+0xa5/0x116
|
||||
(XEN) [<ffff82d040232b12>] S do_domctl+0xe5f/0x1951
|
||||
(XEN) [<ffff82d0402276ba>] S timer.c#timer_lock+0x69/0x143
|
||||
(XEN) [<ffff82d0402dc71b>] S pv_hypercall+0x44e/0x4a9
|
||||
(XEN) [<ffff82d0402012b7>] S lstar_enter+0x137/0x140
|
||||
(XEN)
|
||||
(XEN)
|
||||
(XEN) ****************************************
|
||||
(XEN) Panic on CPU 1:
|
||||
(XEN) Assertion 'svc->rqd == c2rqd(sched_unit_master(unit))' failed at common/sched/credit2.c:1159
|
||||
(XEN) ****************************************
|
||||
|
||||
This is happening as sched_move_domain() is setting a different cpu
|
||||
for a scheduling unit without telling the scheduler. When this unit is
|
||||
removed from the scheduler, the ASSERT() will trigger.
|
||||
|
||||
In non-debug builds the result is usually a clobbered pointer, leading
|
||||
to another crash a short time later.
|
||||
|
||||
Fix that by swapping the two involved actions (setting another cpu and
|
||||
removing the unit from the scheduler).
|
||||
|
||||
Link: https://github.com/Dasharo/dasharo-issues/issues/488
|
||||
Fixes: 70fadc41635b ("xen/cpupool: support moving domain between cpupools with different granularity")
|
||||
Signed-off-by: Juergen Gross <jgross@suse.com>
|
||||
Reviewed-by: George Dunlap <george.dunlap@cloud.com>
|
||||
|
||||
--- a/xen/common/sched/core.c
|
||||
+++ b/xen/common/sched/core.c
|
||||
@@ -732,18 +732,20 @@ int sched_move_domain(struct domain *d,
|
||||
old_domdata = d->sched_priv;
|
||||
|
||||
/*
|
||||
- * Temporarily move all units to same processor to make locking
|
||||
- * easier when moving the new units to the new processors.
|
||||
+ * Remove all units from the old scheduler, and temporarily move them to
|
||||
+ * the same processor to make locking easier when moving the new units to
|
||||
+ * new processors.
|
||||
*/
|
||||
new_p = cpumask_first(d->cpupool->cpu_valid);
|
||||
for_each_sched_unit ( d, unit )
|
||||
{
|
||||
- spinlock_t *lock = unit_schedule_lock_irq(unit);
|
||||
+ spinlock_t *lock;
|
||||
|
||||
+ sched_remove_unit(old_ops, unit);
|
||||
+
|
||||
+ lock = unit_schedule_lock_irq(unit);
|
||||
sched_set_res(unit, get_sched_res(new_p));
|
||||
spin_unlock_irq(lock);
|
||||
-
|
||||
- sched_remove_unit(old_ops, unit);
|
||||
}
|
||||
|
||||
old_units = d->sched_unit_list;
|
||||
BIN
xen-4.18.0-testing-src.tar.bz2
(Stored with Git LFS)
BIN
xen-4.18.0-testing-src.tar.bz2
(Stored with Git LFS)
Binary file not shown.
BIN
xen-4.18.2-testing-src.tar.bz2
(Stored with Git LFS)
Normal file
BIN
xen-4.18.2-testing-src.tar.bz2
(Stored with Git LFS)
Normal file
Binary file not shown.
99
xen.changes
99
xen.changes
@ -1,3 +1,102 @@
|
||||
-------------------------------------------------------------------
|
||||
Tue Apr 9 14:11:15 MDT 2024 - carnold@suse.com
|
||||
|
||||
- Update to Xen 4.18.2 security bug fix release (bsc#1027519)
|
||||
xen-4.18.2-testing-src.tar.bz2
|
||||
* No upstream changelog found in sources or webpage
|
||||
- bsc#1221984 - VUL-0: CVE-2023-46842: xen: x86 HVM hypercalls may
|
||||
trigger Xen bug check (XSA-454)
|
||||
- bsc#1222302 - VUL-0: CVE-2024-31142: xen: x86: Incorrect logic
|
||||
for BTC/SRSO mitigations (XSA-455)
|
||||
- bsc#1222453 - VUL-0: CVE-2024-2201: xen: x86: Native Branch
|
||||
History Injection (XSA-456)
|
||||
- Dropped patch contained in new tarball
|
||||
65f83951-x86-mm-use-block_lock_speculation-in.patch
|
||||
|
||||
-------------------------------------------------------------------
|
||||
Mon Mar 25 15:30:00 CET 2024 - jbeulich@suse.com
|
||||
|
||||
- bsc#1221334 - VUL-0: CVE-2024-2193: xen: GhostRace: Speculative
|
||||
Race Conditions (XSA-453)
|
||||
65f83951-x86-mm-use-block_lock_speculation-in.patch
|
||||
|
||||
-------------------------------------------------------------------
|
||||
Fri Mar 15 10:11:56 MDT 2024 - carnold@suse.com
|
||||
|
||||
- Update to Xen 4.18.1 bug fix release (bsc#1027519)
|
||||
xen-4.18.1-testing-src.tar.bz2
|
||||
* No upstream changelog found in sources or webpage
|
||||
- bsc#1221332 - VUL-0: CVE-2023-28746: xen: x86: Register File Data
|
||||
Sampling (XSA-452)
|
||||
- bsc#1221334 - VUL-0: CVE-2024-2193: xen: GhostRace: Speculative
|
||||
Race Conditions (XSA-453)
|
||||
- Dropped patches included in new tarball
|
||||
654370e2-x86-x2APIC-remove-ACPI_FADT_APIC_CLUSTER-use.patch
|
||||
65437103-x86-i8259-dont-assume-IRQs-always-target-CPU0.patch
|
||||
655b2ba9-fix-sched_move_domain.patch
|
||||
6566fef3-x86-vLAPIC-x2APIC-derive-LDR-from-APIC-ID.patch
|
||||
6569ad03-libxg-mem-leak-in-cpu-policy-get-set.patch
|
||||
656ee5e1-x86emul-avoid-triggering-event-assertions.patch
|
||||
656ee602-cpupool-adding-offline-CPU.patch
|
||||
656ee6c3-domain_create-error-path.patch
|
||||
6571ca95-fix-sched_move_domain.patch
|
||||
6578598c-Arm-avoid-pointer-overflow-on-invalidate.patch
|
||||
65842d5c-x86-AMD-extend-CPU-erratum-1474-fix.patch
|
||||
65a7a0a4-x86-Intel-GPCC-setup.patch
|
||||
65a9911a-VMX-IRQ-handling-for-EXIT_REASON_INIT.patch
|
||||
65b27990-x86-p2m-pt-off-by-1-in-entry-check.patch
|
||||
65b29e91-x86-ucode-stability-of-raw-policy-rescan.patch
|
||||
65b8f961-PCI-fail-dev-assign-if-phantom-functions.patch
|
||||
65b8f9ab-VT-d-else-vs-endif-misplacement.patch
|
||||
xsa451.patch
|
||||
|
||||
-------------------------------------------------------------------
|
||||
Tue Feb 13 09:35:57 MST 2024 - carnold@suse.com
|
||||
|
||||
- bsc#1219885 - VUL-0: CVE-2023-46841: xen: x86: shadow stack vs
|
||||
exceptions from emulation stubs (XSA-451)
|
||||
xsa451.patch
|
||||
|
||||
-------------------------------------------------------------------
|
||||
Wed Jan 31 13:40:00 CET 2024 - jbeulich@suse.com
|
||||
|
||||
- Upstream bug fixes (bsc#1027519)
|
||||
6566fef3-x86-vLAPIC-x2APIC-derive-LDR-from-APIC-ID.patch
|
||||
6569ad03-libxg-mem-leak-in-cpu-policy-get-set.patch
|
||||
656ee5e1-x86emul-avoid-triggering-event-assertions.patch
|
||||
656ee602-cpupool-adding-offline-CPU.patch
|
||||
656ee6c3-domain_create-error-path.patch
|
||||
6571ca95-fix-sched_move_domain.patch
|
||||
6578598c-Arm-avoid-pointer-overflow-on-invalidate.patch
|
||||
65842d5c-x86-AMD-extend-CPU-erratum-1474-fix.patch
|
||||
65a7a0a4-x86-Intel-GPCC-setup.patch
|
||||
65a9911a-VMX-IRQ-handling-for-EXIT_REASON_INIT.patch
|
||||
65b27990-x86-p2m-pt-off-by-1-in-entry-check.patch
|
||||
65b29e91-x86-ucode-stability-of-raw-policy-rescan.patch
|
||||
- bsc#1218851 - VUL-0: CVE-2023-46839: xen: phantom functions
|
||||
assigned to incorrect contexts (XSA-449)
|
||||
65b8f961-PCI-fail-dev-assign-if-phantom-functions.patch
|
||||
- bsc#1219080 - VUL-0: CVE-2023-46840: xen: VT-d: Failure to
|
||||
quarantine devices in !HVM builds (XSA-450)
|
||||
65b8f9ab-VT-d-else-vs-endif-misplacement.patch
|
||||
- Patches dropped / replaced by newer upstream versions
|
||||
xsa449.patch
|
||||
xsa450.patch
|
||||
|
||||
-------------------------------------------------------------------
|
||||
Tue Jan 23 08:52:25 MST 2024 - carnold@suse.com
|
||||
|
||||
- bsc#1219080 - VUL-0: CVE-2023-46840: xen: VT-d: Failure to
|
||||
quarantine devices in !HVM builds (XSA-450)
|
||||
xsa450.patch
|
||||
|
||||
-------------------------------------------------------------------
|
||||
Tue Jan 16 09:32:55 MST 2024 - carnold@suse.com
|
||||
|
||||
- bsc#1218851 - VUL-0: CVE-2023-46839: xen: phantom functions
|
||||
assigned to incorrect contexts (XSA-449)
|
||||
xsa449.patch
|
||||
|
||||
-------------------------------------------------------------------
|
||||
Tue Nov 21 13:22:23 MST 2023 - carnold@suse.com
|
||||
|
||||
|
||||
11
xen.spec
11
xen.spec
@ -1,7 +1,7 @@
|
||||
#
|
||||
# spec file for package xen
|
||||
#
|
||||
# Copyright (c) 2023 SUSE LLC
|
||||
# Copyright (c) 2024 SUSE LLC
|
||||
#
|
||||
# All modifications and additions to the file contributed by third parties
|
||||
# remain the property of their copyright owners, unless otherwise agreed
|
||||
@ -28,7 +28,7 @@
|
||||
|
||||
Name: xen
|
||||
ExclusiveArch: %ix86 x86_64 aarch64
|
||||
%define xen_build_dir xen-4.18.0-testing
|
||||
%define xen_build_dir xen-4.18.2-testing
|
||||
#
|
||||
%define with_gdbsx 0
|
||||
%define with_dom0_support 0
|
||||
@ -119,12 +119,12 @@ BuildRequires: pesign-obs-integration
|
||||
%endif
|
||||
Provides: installhint(reboot-needed)
|
||||
|
||||
Version: 4.18.0_04
|
||||
Version: 4.18.2_02
|
||||
Release: 0
|
||||
Summary: Xen Virtualization: Hypervisor (aka VMM aka Microkernel)
|
||||
License: GPL-2.0-only
|
||||
Group: System/Kernel
|
||||
Source0: xen-4.18.0-testing-src.tar.bz2
|
||||
Source0: xen-4.18.2-testing-src.tar.bz2
|
||||
Source1: stubdom.tar.bz2
|
||||
Source2: mini-os.tar.bz2
|
||||
Source9: xen.changes
|
||||
@ -154,9 +154,6 @@ Source10183: xen_maskcalc.py
|
||||
# For xen-libs
|
||||
Source99: baselibs.conf
|
||||
# Upstream patches
|
||||
Patch1: 654370e2-x86-x2APIC-remove-ACPI_FADT_APIC_CLUSTER-use.patch
|
||||
Patch2: 65437103-x86-i8259-dont-assume-IRQs-always-target-CPU0.patch
|
||||
Patch3: 655b2ba9-fix-sched_move_domain.patch
|
||||
# EMBARGOED security fixes
|
||||
# libxc
|
||||
Patch301: libxc-bitmap-long.patch
|
||||
|
||||
@ -21,7 +21,7 @@ Keep going if the event type and shutdown reason remains the same.
|
||||
|
||||
--- a/tools/xl/Makefile
|
||||
+++ b/tools/xl/Makefile
|
||||
@@ -26,6 +26,7 @@ XL_OBJS += xl_vmcontrol.o xl_saverestore
|
||||
@@ -25,6 +25,7 @@ XL_OBJS += xl_vmcontrol.o xl_saverestore
|
||||
XL_OBJS += xl_vdispl.o xl_vsnd.o xl_vkb.o
|
||||
|
||||
$(XL_OBJS): CFLAGS += $(CFLAGS_libxentoollog)
|
||||
@ -29,7 +29,7 @@ Keep going if the event type and shutdown reason remains the same.
|
||||
$(XL_OBJS): CFLAGS += $(CFLAGS_XL)
|
||||
$(XL_OBJS): CFLAGS += -include $(XEN_ROOT)/tools/config.h # libxl_json.h needs it.
|
||||
|
||||
@@ -33,7 +34,7 @@ $(XL_OBJS): CFLAGS += -include $(XEN_ROO
|
||||
@@ -32,7 +33,7 @@ $(XL_OBJS): CFLAGS += -include $(XEN_ROO
|
||||
all: xl
|
||||
|
||||
xl: $(XL_OBJS)
|
||||
|
||||
Loading…
Reference in New Issue
Block a user