Script 'mail_helper' called by obssrc
Hello community,
here is the log from the commit of package xen for openSUSE:Factory checked in
at 2024-05-23 15:34:11
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Comparing /work/SRC/openSUSE:Factory/xen (Old)
and /work/SRC/openSUSE:Factory/.xen.new.24587 (New)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Package is "xen"
Thu May 23 15:34:11 2024 rev:344 rq:1175908 version:4.18.2_04
Changes:
--------
--- /work/SRC/openSUSE:Factory/xen/xen.changes 2024-04-10 17:49:16.834023025
+0200
+++ /work/SRC/openSUSE:Factory/.xen.new.24587/xen.changes 2024-05-23
15:34:32.558053096 +0200
@@ -1,0 +2,17 @@
+Wed May 15 11:15:00 CEST 2024 - jbeul...@suse.com
+
+- bsc#1221984 - VUL-0: CVE-2023-46842: xen: x86 HVM hypercalls may
+ trigger Xen bug check (XSA-454)
+ 6617d62c-x86-hvm-Misra-Rule-19-1-regression.patch
+- Upstream bug fixes (bsc#1027519)
+ 6627a4ee-vRTC-UIP-set-for-longer-than-expected.patch
+ 6627a5fc-x86-MTRR-inverted-WC-check.patch
+ 662a6a4c-x86-spec-reporting-of-BHB-clearing.patch
+ 662a6a8d-x86-spec-adjust-logic-to-elide-LFENCE.patch
+ 663090fd-x86-gen-cpuid-syntax.patch
+ 663a383c-libxs-open-xenbus-fds-as-O_CLOEXEC.patch
+ 663a4f3e-x86-cpu-policy-migration-IceLake-to-CascadeLake.patch
+ 663d05b5-x86-ucode-distinguish-up-to-date.patch
+ 663eaa27-libxl-XenStore-error-handling-in-device-creation.patch
+
+-------------------------------------------------------------------
New:
----
6617d62c-x86-hvm-Misra-Rule-19-1-regression.patch
6627a4ee-vRTC-UIP-set-for-longer-than-expected.patch
6627a5fc-x86-MTRR-inverted-WC-check.patch
662a6a4c-x86-spec-reporting-of-BHB-clearing.patch
662a6a8d-x86-spec-adjust-logic-to-elide-LFENCE.patch
663090fd-x86-gen-cpuid-syntax.patch
663a383c-libxs-open-xenbus-fds-as-O_CLOEXEC.patch
663a4f3e-x86-cpu-policy-migration-IceLake-to-CascadeLake.patch
663d05b5-x86-ucode-distinguish-up-to-date.patch
663eaa27-libxl-XenStore-error-handling-in-device-creation.patch
BETA DEBUG BEGIN:
New: trigger Xen bug check (XSA-454)
6617d62c-x86-hvm-Misra-Rule-19-1-regression.patch
- Upstream bug fixes (bsc#1027519)
New:- Upstream bug fixes (bsc#1027519)
6627a4ee-vRTC-UIP-set-for-longer-than-expected.patch
6627a5fc-x86-MTRR-inverted-WC-check.patch
New: 6627a4ee-vRTC-UIP-set-for-longer-than-expected.patch
6627a5fc-x86-MTRR-inverted-WC-check.patch
662a6a4c-x86-spec-reporting-of-BHB-clearing.patch
New: 6627a5fc-x86-MTRR-inverted-WC-check.patch
662a6a4c-x86-spec-reporting-of-BHB-clearing.patch
662a6a8d-x86-spec-adjust-logic-to-elide-LFENCE.patch
New: 662a6a4c-x86-spec-reporting-of-BHB-clearing.patch
662a6a8d-x86-spec-adjust-logic-to-elide-LFENCE.patch
663090fd-x86-gen-cpuid-syntax.patch
New: 662a6a8d-x86-spec-adjust-logic-to-elide-LFENCE.patch
663090fd-x86-gen-cpuid-syntax.patch
663a383c-libxs-open-xenbus-fds-as-O_CLOEXEC.patch
New: 663090fd-x86-gen-cpuid-syntax.patch
663a383c-libxs-open-xenbus-fds-as-O_CLOEXEC.patch
663a4f3e-x86-cpu-policy-migration-IceLake-to-CascadeLake.patch
New: 663a383c-libxs-open-xenbus-fds-as-O_CLOEXEC.patch
663a4f3e-x86-cpu-policy-migration-IceLake-to-CascadeLake.patch
663d05b5-x86-ucode-distinguish-up-to-date.patch
New: 663a4f3e-x86-cpu-policy-migration-IceLake-to-CascadeLake.patch
663d05b5-x86-ucode-distinguish-up-to-date.patch
663eaa27-libxl-XenStore-error-handling-in-device-creation.patch
New: 663d05b5-x86-ucode-distinguish-up-to-date.patch
663eaa27-libxl-XenStore-error-handling-in-device-creation.patch
BETA DEBUG END:
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Other differences:
------------------
++++++ xen.spec ++++++
--- /var/tmp/diff_new_pack.FLYKYP/_old 2024-05-23 15:34:36.198185188 +0200
+++ /var/tmp/diff_new_pack.FLYKYP/_new 2024-05-23 15:34:36.198185188 +0200
@@ -119,7 +119,7 @@
%endif
Provides: installhint(reboot-needed)
-Version: 4.18.2_02
+Version: 4.18.2_04
Release: 0
Summary: Xen Virtualization: Hypervisor (aka VMM aka Microkernel)
License: GPL-2.0-only
@@ -154,6 +154,16 @@
# For xen-libs
Source99: baselibs.conf
# Upstream patches
+Patch1: 6617d62c-x86-hvm-Misra-Rule-19-1-regression.patch
+Patch2: 6627a4ee-vRTC-UIP-set-for-longer-than-expected.patch
+Patch3: 6627a5fc-x86-MTRR-inverted-WC-check.patch
+Patch4: 662a6a4c-x86-spec-reporting-of-BHB-clearing.patch
+Patch5: 662a6a8d-x86-spec-adjust-logic-to-elide-LFENCE.patch
+Patch6: 663090fd-x86-gen-cpuid-syntax.patch
+Patch7: 663a383c-libxs-open-xenbus-fds-as-O_CLOEXEC.patch
+Patch8: 663a4f3e-x86-cpu-policy-migration-IceLake-to-CascadeLake.patch
+Patch9: 663d05b5-x86-ucode-distinguish-up-to-date.patch
+Patch10: 663eaa27-libxl-XenStore-error-handling-in-device-creation.patch
# EMBARGOED security fixes
# libxc
Patch301: libxc-bitmap-long.patch
++++++ 6617d62c-x86-hvm-Misra-Rule-19-1-regression.patch ++++++
# Commit d0a718a45f14b86471d8eb3083acd72760963470
# Date 2024-04-11 13:23:08 +0100
# Author Andrew Cooper <andrew.coop...@citrix.com>
# Committer Andrew Cooper <andrew.coop...@citrix.com>
x86/hvm: Fix Misra Rule 19.1 regression
Despite noticing an impending Rule 19.1 violation, the adjustment made (the
uint32_t cast) wasn't sufficient to avoid it. Try again.
Subsequently noticed by Coverity too.
Fixes: 6a98383b0877 ("x86/HVM: clear upper halves of GPRs upon entry from
32-bit code")
Coverity-IDs: 1596289 thru 1596298
Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com>
Reviewed-by: Stefano Stabellini <sstabell...@kernel.org>
--- a/xen/arch/x86/include/asm/hvm/hvm.h
+++ b/xen/arch/x86/include/asm/hvm/hvm.h
@@ -585,16 +585,16 @@ static inline void hvm_sanitize_regs_fie
if ( compat )
{
/* Clear GPR upper halves, to counteract guests playing games. */
- regs->rbp = (uint32_t)regs->ebp;
- regs->rbx = (uint32_t)regs->ebx;
- regs->rax = (uint32_t)regs->eax;
- regs->rcx = (uint32_t)regs->ecx;
- regs->rdx = (uint32_t)regs->edx;
- regs->rsi = (uint32_t)regs->esi;
- regs->rdi = (uint32_t)regs->edi;
- regs->rip = (uint32_t)regs->eip;
- regs->rflags = (uint32_t)regs->eflags;
- regs->rsp = (uint32_t)regs->esp;
+ regs->rbp = (uint32_t)regs->rbp;
+ regs->rbx = (uint32_t)regs->rbx;
+ regs->rax = (uint32_t)regs->rax;
+ regs->rcx = (uint32_t)regs->rcx;
+ regs->rdx = (uint32_t)regs->rdx;
+ regs->rsi = (uint32_t)regs->rsi;
+ regs->rdi = (uint32_t)regs->rdi;
+ regs->rip = (uint32_t)regs->rip;
+ regs->rflags = (uint32_t)regs->rflags;
+ regs->rsp = (uint32_t)regs->rsp;
}
#ifndef NDEBUG
++++++ 6627a4ee-vRTC-UIP-set-for-longer-than-expected.patch ++++++
# Commit 43a07069863b419433dee12c9b58c1f7ce70aa97
# Date 2024-04-23 14:09:18 +0200
# Author Ross Lagerwall <ross.lagerw...@citrix.com>
# Committer Jan Beulich <jbeul...@suse.com>
x86/rtc: Avoid UIP flag being set for longer than expected
In a test, OVMF reported an error initializing the RTC without
indicating the precise nature of the error. The only plausible
explanation I can find is as follows:
As part of the initialization, OVMF reads register C and then reads
register A repatedly until the UIP flag is not set. If this takes longer
than 100 ms, OVMF fails and reports an error. This may happen with the
following sequence of events:
At guest time=0s, rtc_init() calls check_update_timer() which schedules
update_timer for t=(1 - 244us).
At t=1s, the update_timer function happens to have been called >= 244us
late. In the timer callback, it sets the UIP flag and schedules
update_timer2 for t=1s.
Before update_timer2 runs, the guest reads register C which calls
check_update_timer(). check_update_timer() stops the scheduled
update_timer2 and since the guest time is now outside of the update
cycle, it schedules update_timer for t=(2 - 244us).
The UIP flag will therefore be set for a whole second from t=1 to t=2
while the guest repeatedly reads register A waiting for the UIP flag to
clear. Fix it by clearing the UIP flag when scheduling update_timer.
I was able to reproduce this issue with a synthetic test and this
resolves the issue.
Signed-off-by: Ross Lagerwall <ross.lagerw...@citrix.com>
Reviewed-by: Jan Beulich <jbeul...@suse.com>
--- a/xen/arch/x86/hvm/rtc.c
+++ b/xen/arch/x86/hvm/rtc.c
@@ -202,6 +202,7 @@ static void check_update_timer(RTCState
}
else
{
+ s->hw.cmos_data[RTC_REG_A] &= ~RTC_UIP;
next_update_time = (USEC_PER_SEC - guest_usec - 244) * NS_PER_USEC;
expire_time = NOW() + next_update_time;
s->next_update_time = expire_time;
++++++ 6627a5fc-x86-MTRR-inverted-WC-check.patch ++++++
# Commit 77e25f0e30ddd11e043e6fce84bf108ce7de5b6f
# Date 2024-04-23 14:13:48 +0200
# Author Jan Beulich <jbeul...@suse.com>
# Committer Jan Beulich <jbeul...@suse.com>
x86/MTRR: correct inadvertently inverted WC check
The ! clearly got lost by mistake.
Fixes: e9e0eb30d4d6 ("x86/MTRR: avoid several indirect calls")
Reported-by: Marek Marczykowski-Górecki <marma...@invisiblethingslab.com>
Signed-off-by: Jan Beulich <jbeul...@suse.com>
Acked-by: Roger Pau Monné <roger....@citrix.com>
--- a/xen/arch/x86/cpu/mtrr/main.c
+++ b/xen/arch/x86/cpu/mtrr/main.c
@@ -316,7 +316,7 @@ int mtrr_add_page(unsigned long base, un
}
/* If the type is WC, check that this processor supports it */
- if ((type == X86_MT_WC) && mtrr_have_wrcomb()) {
+ if ((type == X86_MT_WC) && !mtrr_have_wrcomb()) {
printk(KERN_WARNING
"mtrr: your processor doesn't support
write-combining\n");
return -EOPNOTSUPP;
++++++ 662a6a4c-x86-spec-reporting-of-BHB-clearing.patch ++++++
# Commit 049ab0b2c9f1f5edb54b505fef0bc575787dafe9
# Date 2024-04-25 16:35:56 +0200
# Author Roger Pau Monné <roger....@citrix.com>
# Committer Jan Beulich <jbeul...@suse.com>
x86/spec: fix reporting of BHB clearing usage from guest entry points
Reporting whether the BHB clearing on entry is done for the different domains
types based on cpu_has_bhb_seq is unhelpful, as that variable signals whether
there's a BHB clearing sequence selected, but that alone doesn't imply that
such sequence is used from the PV and/or HVM entry points.
Instead use opt_bhb_entry_{pv,hvm} which do signal whether BHB clearing is
performed on entry from PV/HVM.
Fixes: 689ad48ce9cf ('x86/spec-ctrl: Wire up the Native-BHI software sequences')
Signed-off-by: Roger Pau Monné <roger....@citrix.com>
Reviewed-by: Jan Beulich <jbeul...@suse.com>
Reviewed-by: Andrew Cooper <andrew.coop...@citrix.com>
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -634,7 +634,7 @@ static void __init print_details(enum in
(boot_cpu_has(X86_FEATURE_SC_MSR_HVM) ||
boot_cpu_has(X86_FEATURE_SC_RSB_HVM) ||
boot_cpu_has(X86_FEATURE_IBPB_ENTRY_HVM) ||
- cpu_has_bhb_seq || amd_virt_spec_ctrl ||
+ opt_bhb_entry_hvm || amd_virt_spec_ctrl ||
opt_eager_fpu || opt_verw_hvm) ? "" : "
None",
boot_cpu_has(X86_FEATURE_SC_MSR_HVM) ? " MSR_SPEC_CTRL" : "",
(boot_cpu_has(X86_FEATURE_SC_MSR_HVM) ||
@@ -643,7 +643,7 @@ static void __init print_details(enum in
opt_eager_fpu ? " EAGER_FPU" : "",
opt_verw_hvm ? " VERW" : "",
boot_cpu_has(X86_FEATURE_IBPB_ENTRY_HVM) ? " IBPB-entry" : "",
- cpu_has_bhb_seq ? " BHB-entry" : "");
+ opt_bhb_entry_hvm ? " BHB-entry" : "");
#endif
#ifdef CONFIG_PV
@@ -651,14 +651,14 @@ static void __init print_details(enum in
(boot_cpu_has(X86_FEATURE_SC_MSR_PV) ||
boot_cpu_has(X86_FEATURE_SC_RSB_PV) ||
boot_cpu_has(X86_FEATURE_IBPB_ENTRY_PV) ||
- cpu_has_bhb_seq ||
+ opt_bhb_entry_pv ||
opt_eager_fpu || opt_verw_pv) ? "" : "
None",
boot_cpu_has(X86_FEATURE_SC_MSR_PV) ? " MSR_SPEC_CTRL" : "",
boot_cpu_has(X86_FEATURE_SC_RSB_PV) ? " RSB" : "",
opt_eager_fpu ? " EAGER_FPU" : "",
opt_verw_pv ? " VERW" : "",
boot_cpu_has(X86_FEATURE_IBPB_ENTRY_PV) ? " IBPB-entry" : "",
- cpu_has_bhb_seq ? " BHB-entry" : "");
+ opt_bhb_entry_pv ? " BHB-entry" : "");
printk(" XPTI (64-bit PV only): Dom0 %s, DomU %s (with%s PCID)\n",
opt_xpti_hwdom ? "enabled" : "disabled",
++++++ 662a6a8d-x86-spec-adjust-logic-to-elide-LFENCE.patch ++++++
# Commit 656ae8f1091bcefec9c46ec3ea3ac2118742d4f6
# Date 2024-04-25 16:37:01 +0200
# Author Roger Pau Monné <roger....@citrix.com>
# Committer Jan Beulich <jbeul...@suse.com>
x86/spec: adjust logic that elides lfence
It's currently too restrictive by just checking whether there's a BHB clearing
sequence selected. It should instead check whether BHB clearing is used on
entry from PV or HVM specifically.
Switch to use opt_bhb_entry_{pv,hvm} instead, and then remove cpu_has_bhb_seq
since it no longer has any users.
Reported-by: Jan Beulich <jbeul...@suse.com>
Fixes: 954c983abcee ('x86/spec-ctrl: Software BHB-clearing sequences')
Signed-off-by: Roger Pau Monné <roger....@citrix.com>
Reviewed-by: Jan Beulich <jbeul...@suse.com>
Reviewed-by: Andrew Cooper <andrew.coop...@citrix.com>
--- a/xen/arch/x86/include/asm/cpufeature.h
+++ b/xen/arch/x86/include/asm/cpufeature.h
@@ -228,9 +228,6 @@ static inline bool boot_cpu_has(unsigned
#define cpu_bug_fpu_ptrs boot_cpu_has(X86_BUG_FPU_PTRS)
#define cpu_bug_null_seg boot_cpu_has(X86_BUG_NULL_SEG)
-#define cpu_has_bhb_seq (boot_cpu_has(X86_SPEC_BHB_TSX) || \
- boot_cpu_has(X86_SPEC_BHB_LOOPS))
-
enum _cache_type {
CACHE_TYPE_NULL = 0,
CACHE_TYPE_DATA = 1,
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -2328,7 +2328,7 @@ void __init init_speculation_mitigations
* unconditional WRMSR. If we do have it, or we're not using any
* prior conditional block, then it's safe to drop the LFENCE.
*/
- if ( !cpu_has_bhb_seq &&
+ if ( !opt_bhb_entry_pv &&
(boot_cpu_has(X86_FEATURE_SC_MSR_PV) ||
!boot_cpu_has(X86_FEATURE_IBPB_ENTRY_PV)) )
setup_force_cpu_cap(X86_SPEC_NO_LFENCE_ENTRY_PV);
@@ -2344,7 +2344,7 @@ void __init init_speculation_mitigations
* active in the block that is skipped when interrupting guest
* context, then it's safe to drop the LFENCE.
*/
- if ( !cpu_has_bhb_seq &&
+ if ( !opt_bhb_entry_pv &&
(boot_cpu_has(X86_FEATURE_SC_MSR_PV) ||
(!boot_cpu_has(X86_FEATURE_IBPB_ENTRY_PV) &&
!boot_cpu_has(X86_FEATURE_SC_RSB_PV))) )
@@ -2356,7 +2356,7 @@ void __init init_speculation_mitigations
* A BHB sequence, if used, is the only conditional action, so if we
* don't have it, we don't need the safety LFENCE.
*/
- if ( !cpu_has_bhb_seq )
+ if ( !opt_bhb_entry_hvm )
setup_force_cpu_cap(X86_SPEC_NO_LFENCE_ENTRY_VMX);
}
++++++ 663090fd-x86-gen-cpuid-syntax.patch ++++++
# Commit 08e79bba73d74a85d3ce6ff0f91c5205f1e05eda
# Date 2024-04-30 08:34:37 +0200
# Author Jason Andryuk <jason.andr...@amd.com>
# Committer Jan Beulich <jbeul...@suse.com>
xen/x86: Fix Syntax warning in gen-cpuid.py
Python 3.12.2 warns:
xen/tools/gen-cpuid.py:50: SyntaxWarning: invalid escape sequence '\s'
"\s+([\s\d]+\*[\s\d]+\+[\s\d]+)\)"
xen/tools/gen-cpuid.py:51: SyntaxWarning: invalid escape sequence '\s'
"\s+/\*([\w!]*) .*$")
Specify the strings as raw strings so '\s' is read as literal '\' + 's'.
This avoids escaping all the '\'s in the strings.
Signed-off-by: Jason Andryuk <jason.andr...@amd.com>
Acked-by: Andrew Cooper <andrew.coop...@citrix.com>
--- a/xen/tools/gen-cpuid.py
+++ b/xen/tools/gen-cpuid.py
@@ -47,8 +47,8 @@ def parse_definitions(state):
"""
feat_regex = re.compile(
r"^XEN_CPUFEATURE\(([A-Z0-9_]+),"
- "\s+([\s\d]+\*[\s\d]+\+[\s\d]+)\)"
- "\s+/\*([\w!]*) .*$")
+ r"\s+([\s\d]+\*[\s\d]+\+[\s\d]+)\)"
+ r"\s+/\*([\w!]*) .*$")
word_regex = re.compile(
r"^/\* .* word (\d*) \*/$")
++++++ 663a383c-libxs-open-xenbus-fds-as-O_CLOEXEC.patch ++++++
# Commit f4f2f3402b2f4985d69ffc0d46f845d05fd0b60f
# Date 2024-05-07 15:18:36 +0100
# Author Andrew Cooper <andrew.coop...@citrix.com>
# Committer Andrew Cooper <andrew.coop...@citrix.com>
tools/libxs: Open /dev/xen/xenbus fds as O_CLOEXEC
The header description for xs_open() goes as far as to suggest that the fd is
O_CLOEXEC, but it isn't actually.
`xl devd` has been observed leaking /dev/xen/xenbus into children.
Link: https://github.com/QubesOS/qubes-issues/issues/8292
Reported-by: Demi Marie Obenour <d...@invisiblethingslab.com>
Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com>
Reviewed-by: Juergen Gross <jgr...@suse.com>
--- a/tools/libs/store/xs.c
+++ b/tools/libs/store/xs.c
@@ -54,6 +54,10 @@ struct xs_stored_msg {
#include <dlfcn.h>
#endif
+#ifndef O_CLOEXEC
+#define O_CLOEXEC 0
+#endif
+
struct xs_handle {
/* Communications channel to xenstore daemon. */
int fd;
@@ -227,7 +231,7 @@ error:
static int get_dev(const char *connect_to)
{
/* We cannot open read-only because requests are writes */
- return open(connect_to, O_RDWR);
+ return open(connect_to, O_RDWR | O_CLOEXEC);
}
static int all_restrict_cb(Xentoolcore__Active_Handle *ah, domid_t domid) {
++++++ 663a4f3e-x86-cpu-policy-migration-IceLake-to-CascadeLake.patch ++++++
# Commit a2330b51df267e20e66bbba6c5bf08f0570ed58b
# Date 2024-05-07 16:56:46 +0100
# Author Andrew Cooper <andrew.coop...@citrix.com>
# Committer Andrew Cooper <andrew.coop...@citrix.com>
x86/cpu-policy: Fix migration from Ice Lake to Cascade Lake
Ever since Xen 4.14, there has been a latent bug with migration.
While some toolstacks can level the features properly, they don't shink
feat.max_subleaf when all features have been dropped. This is because
we *still* have not completed the toolstack side work for full CPU Policy
objects.
As a consequence, even when properly feature levelled, VMs can't migrate
"backwards" across hardware which reduces feat.max_subleaf. One such example
is Ice Lake (max_subleaf=2 for INTEL_PSFD) to Cascade Lake (max_subleaf=0).
Extend the max policies feat.max_subleaf to the hightest number Xen knows
about, but leave the default policies matching the host. This will allow VMs
with a higher feat.max_subleaf than strictly necessary to migrate in.
Eventually we'll manage to teach the toolstack how to avoid creating such VMs
in the first place, but there's still more work to do there.
Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com>
Acked-by: Roger Pau Monné <roger....@citrix.com>
--- a/xen/arch/x86/cpu-policy.c
+++ b/xen/arch/x86/cpu-policy.c
@@ -603,6 +603,13 @@ static void __init calculate_pv_max_poli
unsigned int i;
*p = host_cpu_policy;
+
+ /*
+ * Some VMs may have a larger-than-necessary feat max_subleaf. Allow them
+ * to migrate in.
+ */
+ p->feat.max_subleaf = ARRAY_SIZE(p->feat.raw) - 1;
+
x86_cpu_policy_to_featureset(p, fs);
for ( i = 0; i < ARRAY_SIZE(fs); ++i )
@@ -643,6 +650,10 @@ static void __init calculate_pv_def_poli
unsigned int i;
*p = pv_max_cpu_policy;
+
+ /* Default to the same max_subleaf as the host. */
+ p->feat.max_subleaf = host_cpu_policy.feat.max_subleaf;
+
x86_cpu_policy_to_featureset(p, fs);
for ( i = 0; i < ARRAY_SIZE(fs); ++i )
@@ -679,6 +690,13 @@ static void __init calculate_hvm_max_pol
const uint32_t *mask;
*p = host_cpu_policy;
+
+ /*
+ * Some VMs may have a larger-than-necessary feat max_subleaf. Allow them
+ * to migrate in.
+ */
+ p->feat.max_subleaf = ARRAY_SIZE(p->feat.raw) - 1;
+
x86_cpu_policy_to_featureset(p, fs);
mask = hvm_hap_supported() ?
@@ -780,6 +798,10 @@ static void __init calculate_hvm_def_pol
const uint32_t *mask;
*p = hvm_max_cpu_policy;
+
+ /* Default to the same max_subleaf as the host. */
+ p->feat.max_subleaf = host_cpu_policy.feat.max_subleaf;
+
x86_cpu_policy_to_featureset(p, fs);
mask = hvm_hap_supported() ?
++++++ 663d05b5-x86-ucode-distinguish-up-to-date.patch ++++++
# Commit 648db37a155aca6f66d4cf3bb118417a728c3579
# Date 2024-05-09 18:19:49 +0100
# Author Andrew Cooper <andrew.coop...@citrix.com>
# Committer Andrew Cooper <andrew.coop...@citrix.com>
x86/ucode: Distinguish "ucode already up to date"
Right now, Xen returns -ENOENT for both "the provided blob isn't correct for
this CPU", and "the blob isn't newer than what's loaded".
This in turn causes xen-ucode to exit with an error, when "nothing to do" is
more commonly a success condition.
Handle EEXIST specially and exit cleanly.
Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com>
Acked-by: Roger Pau Monné <roger....@citrix.com>
--- a/tools/misc/xen-ucode.c
+++ b/tools/misc/xen-ucode.c
@@ -125,8 +125,11 @@ int main(int argc, char *argv[])
exit(1);
}
+ errno = 0;
ret = xc_microcode_update(xch, buf, len);
- if ( ret )
+ if ( ret == -1 && errno == EEXIST )
+ printf("Microcode already up to date\n");
+ else if ( ret )
{
fprintf(stderr, "Failed to update microcode. (err: %s)\n",
strerror(errno));
--- a/xen/arch/x86/cpu/microcode/core.c
+++ b/xen/arch/x86/cpu/microcode/core.c
@@ -640,7 +640,7 @@ static long cf_check microcode_update_he
"microcode: couldn't find any newer%s revision in the
provided blob!\n",
opt_ucode_allow_same ? " (or the same)" : "");
microcode_free_patch(patch);
- ret = -ENOENT;
+ ret = -EEXIST;
goto put;
}
++++++ 663eaa27-libxl-XenStore-error-handling-in-device-creation.patch ++++++
# Commit 531d3bea5e9357357eaf6d40f5784a1b4c29b910
# Date 2024-05-11 00:13:43 +0100
# Author Demi Marie Obenour <d...@invisiblethingslab.com>
# Committer Andrew Cooper <andrew.coop...@citrix.com>
libxl: Fix handling XenStore errors in device creation
If xenstored runs out of memory it is possible for it to fail operations
that should succeed. libxl wasn't robust against this, and could fail
to ensure that the TTY path of a non-initial console was created and
read-only for guests. This doesn't qualify for an XSA because guests
should not be able to run xenstored out of memory, but it still needs to
be fixed.
Add the missing error checks to ensure that all errors are properly
handled and that at no point can a guest make the TTY path of its
frontend directory writable.
Signed-off-by: Demi Marie Obenour <d...@invisiblethingslab.com>
Reviewed-by: Juergen Gross <jgr...@suse.com>
--- a/tools/libs/light/libxl_console.c
+++ b/tools/libs/light/libxl_console.c
@@ -351,11 +351,10 @@ int libxl__device_console_add(libxl__gc
flexarray_append(front, "protocol");
flexarray_append(front, LIBXL_XENCONSOLE_PROTOCOL);
}
- libxl__device_generic_add(gc, XBT_NULL, device,
- libxl__xs_kvs_of_flexarray(gc, back),
- libxl__xs_kvs_of_flexarray(gc, front),
- libxl__xs_kvs_of_flexarray(gc, ro_front));
- rc = 0;
+ rc = libxl__device_generic_add(gc, XBT_NULL, device,
+ libxl__xs_kvs_of_flexarray(gc, back),
+ libxl__xs_kvs_of_flexarray(gc, front),
+ libxl__xs_kvs_of_flexarray(gc, ro_front));
out:
return rc;
}
@@ -665,6 +664,8 @@ int libxl_device_channel_getinfo(libxl_c
*/
if (!val) val = "/NO-SUCH-PATH";
channelinfo->u.pty.path = strdup(val);
+ if (channelinfo->u.pty.path == NULL)
+ abort();
break;
default:
break;
--- a/tools/libs/light/libxl_device.c
+++ b/tools/libs/light/libxl_device.c
@@ -177,8 +177,13 @@ int libxl__device_generic_add(libxl__gc
ro_frontend_perms[1].perms = backend_perms[1].perms = XS_PERM_READ;
retry_transaction:
- if (create_transaction)
+ if (create_transaction) {
t = xs_transaction_start(ctx->xsh);
+ if (t == XBT_NULL) {
+ LOGED(ERROR, device->domid, "xs_transaction_start failed");
+ return ERROR_FAIL;
+ }
+ }
/* FIXME: read frontend_path and check state before removing stuff */
@@ -195,42 +200,55 @@ retry_transaction:
if (rc) goto out;
}
- /* xxx much of this function lacks error checks! */
-
if (fents || ro_fents) {
- xs_rm(ctx->xsh, t, frontend_path);
- xs_mkdir(ctx->xsh, t, frontend_path);
+ if (!xs_rm(ctx->xsh, t, frontend_path) && errno != ENOENT)
+ goto out;
+ if (!xs_mkdir(ctx->xsh, t, frontend_path))
+ goto out;
/* Console 0 is a special case. It doesn't use the regular PV
* state machine but also the frontend directory has
* historically contained other information, such as the
* vnc-port, which we don't want the guest fiddling with.
*/
if ((device->kind == LIBXL__DEVICE_KIND_CONSOLE && device->devid == 0)
||
- (device->kind == LIBXL__DEVICE_KIND_VUART))
- xs_set_permissions(ctx->xsh, t, frontend_path,
- ro_frontend_perms,
ARRAY_SIZE(ro_frontend_perms));
- else
- xs_set_permissions(ctx->xsh, t, frontend_path,
- frontend_perms, ARRAY_SIZE(frontend_perms));
- xs_write(ctx->xsh, t, GCSPRINTF("%s/backend", frontend_path),
- backend_path, strlen(backend_path));
- if (fents)
- libxl__xs_writev_perms(gc, t, frontend_path, fents,
- frontend_perms, ARRAY_SIZE(frontend_perms));
- if (ro_fents)
- libxl__xs_writev_perms(gc, t, frontend_path, ro_fents,
- ro_frontend_perms,
ARRAY_SIZE(ro_frontend_perms));
+ (device->kind == LIBXL__DEVICE_KIND_VUART)) {
+ if (!xs_set_permissions(ctx->xsh, t, frontend_path,
+ ro_frontend_perms,
ARRAY_SIZE(ro_frontend_perms)))
+ goto out;
+ } else {
+ if (!xs_set_permissions(ctx->xsh, t, frontend_path,
+ frontend_perms,
ARRAY_SIZE(frontend_perms)))
+ goto out;
+ }
+ if (!xs_write(ctx->xsh, t, GCSPRINTF("%s/backend", frontend_path),
+ backend_path, strlen(backend_path)))
+ goto out;
+ if (fents) {
+ rc = libxl__xs_writev_perms(gc, t, frontend_path, fents,
+ frontend_perms,
ARRAY_SIZE(frontend_perms));
+ if (rc) goto out;
+ }
+ if (ro_fents) {
+ rc = libxl__xs_writev_perms(gc, t, frontend_path, ro_fents,
+ ro_frontend_perms,
ARRAY_SIZE(ro_frontend_perms));
+ if (rc) goto out;
+ }
}
if (bents) {
if (!libxl_only) {
- xs_rm(ctx->xsh, t, backend_path);
- xs_mkdir(ctx->xsh, t, backend_path);
- xs_set_permissions(ctx->xsh, t, backend_path, backend_perms,
- ARRAY_SIZE(backend_perms));
- xs_write(ctx->xsh, t, GCSPRINTF("%s/frontend", backend_path),
- frontend_path, strlen(frontend_path));
- libxl__xs_writev(gc, t, backend_path, bents);
+ if (!xs_rm(ctx->xsh, t, backend_path) && errno != ENOENT)
+ goto out;
+ if (!xs_mkdir(ctx->xsh, t, backend_path))
+ goto out;
+ if (!xs_set_permissions(ctx->xsh, t, backend_path, backend_perms,
+ ARRAY_SIZE(backend_perms)))
+ goto out;
+ if (!xs_write(ctx->xsh, t, GCSPRINTF("%s/frontend", backend_path),
+ frontend_path, strlen(frontend_path)))
+ goto out;
+ rc = libxl__xs_writev(gc, t, backend_path, bents);
+ if (rc) goto out;
}
/*
@@ -276,7 +294,7 @@ retry_transaction:
out:
if (create_transaction && t)
libxl__xs_transaction_abort(gc, &t);
- return rc;
+ return rc != 0 ? rc : ERROR_FAIL;
}
typedef struct {
--- a/tools/libs/light/libxl_xshelp.c
+++ b/tools/libs/light/libxl_xshelp.c
@@ -60,10 +60,15 @@ int libxl__xs_writev_perms(libxl__gc *gc
for (i = 0; kvs[i] != NULL; i += 2) {
path = GCSPRINTF("%s/%s", dir, kvs[i]);
if (path && kvs[i + 1]) {
- int length = strlen(kvs[i + 1]);
- xs_write(ctx->xsh, t, path, kvs[i + 1], length);
- if (perms)
- xs_set_permissions(ctx->xsh, t, path, perms, num_perms);
+ size_t length = strlen(kvs[i + 1]);
+ if (length > UINT_MAX)
+ return ERROR_FAIL;
+ if (!xs_write(ctx->xsh, t, path, kvs[i + 1], length))
+ return ERROR_FAIL;
+ if (perms) {
+ if (!xs_set_permissions(ctx->xsh, t, path, perms, num_perms))
+ return ERROR_FAIL;
+ }
}
}
return 0;
++++++ libxl.LIBXL_HOTPLUG_TIMEOUT.patch ++++++
--- /var/tmp/diff_new_pack.FLYKYP/_old 2024-05-23 15:34:36.582199123 +0200
+++ /var/tmp/diff_new_pack.FLYKYP/_new 2024-05-23 15:34:36.594199558 +0200
@@ -52,10 +52,8 @@
The change for libxl which handles this xenstore value will enable
additional logging if the key is found. That extra logging will show how
the execution time of each script.
-Index: xen-4.18.0-testing/tools/libs/light/libxl_aoutils.c
-===================================================================
---- xen-4.18.0-testing.orig/tools/libs/light/libxl_aoutils.c
-+++ xen-4.18.0-testing/tools/libs/light/libxl_aoutils.c
+--- a/tools/libs/light/libxl_aoutils.c
++++ b/tools/libs/light/libxl_aoutils.c
@@ -529,6 +529,8 @@ static void async_exec_timeout(libxl__eg
{
libxl__async_exec_state *aes = CONTAINER_OF(ev, *aes, time);
@@ -85,10 +83,8 @@
libxl__ev_time_deregister(gc, &aes->time);
-Index: xen-4.18.0-testing/tools/libs/light/libxl_create.c
-===================================================================
---- xen-4.18.0-testing.orig/tools/libs/light/libxl_create.c
-+++ xen-4.18.0-testing/tools/libs/light/libxl_create.c
+--- a/tools/libs/light/libxl_create.c
++++ b/tools/libs/light/libxl_create.c
@@ -1323,6 +1323,7 @@ static void initiate_domain_create(libxl
* build info around just to know if the domain has a device model or not.
*/
@@ -97,11 +93,9 @@
for (i = 0; i < d_config->num_disks; i++) {
ret = libxl__disk_devtype.set_default(gc, domid, &d_config->disks[i],
-Index: xen-4.18.0-testing/tools/libs/light/libxl_device.c
-===================================================================
---- xen-4.18.0-testing.orig/tools/libs/light/libxl_device.c
-+++ xen-4.18.0-testing/tools/libs/light/libxl_device.c
-@@ -1278,7 +1278,7 @@ static void device_hotplug(libxl__egc *e
+--- a/tools/libs/light/libxl_device.c
++++ b/tools/libs/light/libxl_device.c
+@@ -1296,7 +1296,7 @@ static void device_hotplug(libxl__egc *e
}
aes->ao = ao;
@@ -110,7 +104,7 @@
aes->env = env;
aes->args = args;
aes->callback = device_hotplug_child_death_cb;
-@@ -1287,6 +1287,15 @@ static void device_hotplug(libxl__egc *e
+@@ -1305,6 +1305,15 @@ static void device_hotplug(libxl__egc *e
aes->stdfds[1] = 2;
aes->stdfds[2] = -1;
@@ -126,10 +120,8 @@
rc = libxl__async_exec_start(aes);
if (rc)
goto out;
-Index: xen-4.18.0-testing/tools/libs/light/libxl_event.c
-===================================================================
---- xen-4.18.0-testing.orig/tools/libs/light/libxl_event.c
-+++ xen-4.18.0-testing/tools/libs/light/libxl_event.c
+--- a/tools/libs/light/libxl_event.c
++++ b/tools/libs/light/libxl_event.c
@@ -1032,27 +1032,29 @@ static void devstate_callback(libxl__egc
{
EGC_GC;
@@ -176,10 +168,8 @@
rc = libxl__xswait_start(gc, &ds->w);
if (rc) goto out;
-Index: xen-4.18.0-testing/tools/libs/light/libxl_internal.c
-===================================================================
---- xen-4.18.0-testing.orig/tools/libs/light/libxl_internal.c
-+++ xen-4.18.0-testing/tools/libs/light/libxl_internal.c
+--- a/tools/libs/light/libxl_internal.c
++++ b/tools/libs/light/libxl_internal.c
@@ -18,6 +18,97 @@
#include "libxl_internal.h"
#include "libxl_arch.h"
@@ -278,10 +268,8 @@
void libxl__alloc_failed(libxl_ctx *ctx, const char *func,
size_t nmemb, size_t size) {
#define M "libxl: FATAL ERROR: memory allocation failure"
-Index: xen-4.18.0-testing/tools/libs/light/libxl_internal.h
-===================================================================
---- xen-4.18.0-testing.orig/tools/libs/light/libxl_internal.h
-+++ xen-4.18.0-testing/tools/libs/light/libxl_internal.h
+--- a/tools/libs/light/libxl_internal.h
++++ b/tools/libs/light/libxl_internal.h
@@ -50,6 +50,7 @@
#include <sys/un.h>
#include <sys/file.h>
++++++ xen.libxl.dmmd.patch ++++++
--- /var/tmp/diff_new_pack.FLYKYP/_old 2024-05-23 15:34:36.722204203 +0200
+++ /var/tmp/diff_new_pack.FLYKYP/_new 2024-05-23 15:34:36.726204349 +0200
@@ -7,10 +7,8 @@
tools/libxl/libxlu_disk_l.l | 2 ++
4 files changed, 37 insertions(+), 6 deletions(-)
-Index: xen-4.18.0-testing/tools/libs/light/libxl_disk.c
-===================================================================
---- xen-4.18.0-testing.orig/tools/libs/light/libxl_disk.c
-+++ xen-4.18.0-testing/tools/libs/light/libxl_disk.c
+--- a/tools/libs/light/libxl_disk.c
++++ b/tools/libs/light/libxl_disk.c
@@ -203,7 +203,7 @@ static int libxl__device_disk_setdefault
return rc;
}
@@ -31,11 +29,9 @@
flexarray_append(back, "params");
flexarray_append(back, GCSPRINTF("%s:%s",
libxl__device_disk_string_of_format(disk->format),
-Index: xen-4.18.0-testing/tools/libs/light/libxl_device.c
-===================================================================
---- xen-4.18.0-testing.orig/tools/libs/light/libxl_device.c
-+++ xen-4.18.0-testing/tools/libs/light/libxl_device.c
-@@ -333,7 +333,8 @@ static int disk_try_backend(disk_try_bac
+--- a/tools/libs/light/libxl_device.c
++++ b/tools/libs/light/libxl_device.c
+@@ -351,7 +351,8 @@ static int disk_try_backend(disk_try_bac
return 0;
case LIBXL_DISK_BACKEND_QDISK:
@@ -45,10 +41,8 @@
return backend;
case LIBXL_DISK_BACKEND_STANDALONE:
-Index: xen-4.18.0-testing/tools/libs/light/libxl_dm.c
-===================================================================
---- xen-4.18.0-testing.orig/tools/libs/light/libxl_dm.c
-+++ xen-4.18.0-testing/tools/libs/light/libxl_dm.c
+--- a/tools/libs/light/libxl_dm.c
++++ b/tools/libs/light/libxl_dm.c
@@ -1197,6 +1197,30 @@ out:
return rc;
}
@@ -93,10 +87,8 @@
if (dev_number == -1) {
LOGD(WARN, guest_domid, "unable to determine"" disk number
for %s",
disks[i].vdev);
-Index: xen-4.18.0-testing/tools/libs/util/libxlu_disk_l.l
-===================================================================
---- xen-4.18.0-testing.orig/tools/libs/util/libxlu_disk_l.l
-+++ xen-4.18.0-testing/tools/libs/util/libxlu_disk_l.l
+--- a/tools/libs/util/libxlu_disk_l.l
++++ b/tools/libs/util/libxlu_disk_l.l
@@ -253,6 +253,8 @@ target=.* { STRIP(','); SAVESTRING("targ
free(newscript);
}
@@ -106,10 +98,8 @@
tapdisk:/.* { DPC->had_depr_prefix=1; DEPRECATE(0); }
tap2?:/.* { DPC->had_depr_prefix=1; DEPRECATE(0); }
aio:/.* { DPC->had_depr_prefix=1; DEPRECATE(0); }
-Index: xen-4.18.0-testing/tools/libs/light/libxl_internal.h
-===================================================================
---- xen-4.18.0-testing.orig/tools/libs/light/libxl_internal.h
-+++ xen-4.18.0-testing/tools/libs/light/libxl_internal.h
+--- a/tools/libs/light/libxl_internal.h
++++ b/tools/libs/light/libxl_internal.h
@@ -2073,6 +2073,10 @@ _hidden char *libxl__object_to_json(libx
_hidden int libxl__cpuid_legacy(libxl_ctx *ctx, uint32_t domid, bool retore,
libxl_domain_build_info *info);
