Script 'mail_helper' called by obssrc
Hello community,
here is the log from the commit of package xen for openSUSE:Factory checked in
at 2023-03-11 18:23:10
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Comparing /work/SRC/openSUSE:Factory/xen (Old)
and /work/SRC/openSUSE:Factory/.xen.new.31432 (New)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Package is "xen"
Sat Mar 11 18:23:10 2023 rev:329 rq:1070523 version:4.17.0_04
Changes:
--------
--- /work/SRC/openSUSE:Factory/xen/xen.changes 2023-03-02 23:03:15.903323840
+0100
+++ /work/SRC/openSUSE:Factory/.xen.new.31432/xen.changes 2023-03-11
18:23:12.274619379 +0100
@@ -1,0 +2,8 @@
+Thu Mar 2 10:33:46 MST 2023 - carn...@suse.com
+
+- bsc#1208736 - GCC 13: xen package fails
+ bunzip-gcc13.patch
+ altp2m-gcc13.patch
+- Drop gcc13-fixes.patch
+
+-------------------------------------------------------------------
Old:
----
gcc13-fixes.patch
New:
----
altp2m-gcc13.patch
bunzip-gcc13.patch
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Other differences:
------------------
++++++ xen.spec ++++++
--- /var/tmp/diff_new_pack.JuKbCg/_old 2023-03-11 18:23:13.814627404 +0100
+++ /var/tmp/diff_new_pack.JuKbCg/_new 2023-03-11 18:23:13.814627404 +0100
@@ -207,7 +207,8 @@
# Needs to go upstream
Patch420: suspend_evtchn_lock.patch
Patch421: vif-route.patch
-Patch422: gcc13-fixes.patch
+Patch422: bunzip-gcc13.patch
+Patch423: altp2m-gcc13.patch
# Other bug fixes or features
Patch450: xen.sysconfig-fillup.patch
Patch451: xenconsole-no-multiple-connections.patch
++++++ altp2m-gcc13.patch ++++++
x86/altp2m: help gcc13 to avoid it emitting a warning
Switches of altp2m-s always expect a valid altp2m to be in place (and
indeed altp2m_vcpu_initialise() sets the active one to be at index 0).
The compiler, however, cannot know that, and hence it cannot eliminate
p2m_get_altp2m()'s case of returnin (literal) NULL. If then the compiler
decides to special case that code path, the dereference in instances of
atomic_dec(&p2m_get_altp2m(v)->active_vcpus);
will, to the code generator, appear to be NULL dereferences, leading to
In function 'atomic_dec',
inlined from '...' at ...:
./arch/x86/include/asm/atomic.h:182:5: error: array subscript 0 is outside
array bounds of 'int[0]' [-Werror=array-bounds=]
Aid the compiler by adding a BUG_ON() checking the return value of the
problematic p2m_get_altp2m(). Since with the use of the local variable
the 2nd p2m_get_altp2m() each will look questionable at the first glance
(Why is the local variable not used here?), open-code the only relevant
piece of p2m_get_altp2m() there.
To avoid repeatedly doing these transformations, and also to limit how
"bad" the open-coding really is, convert the entire operation to an
inline helper, used by all three instances (and accepting the redundant
BUG_ON(idx >= MAX_ALTP2M) in two of the three cases).
Reported-by: Charles Arnold <carn...@suse.com>
Signed-off-by: Jan Beulich <jbeul...@suse.com>
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -4063,13 +4063,7 @@ void vmx_vmexit_handler(struct cpu_user_
}
}
- if ( idx != vcpu_altp2m(v).p2midx )
- {
- BUG_ON(idx >= MAX_ALTP2M);
- atomic_dec(&p2m_get_altp2m(v)->active_vcpus);
- vcpu_altp2m(v).p2midx = idx;
- atomic_inc(&p2m_get_altp2m(v)->active_vcpus);
- }
+ p2m_set_altp2m(v, idx);
}
if ( unlikely(currd->arch.monitor.vmexit_enabled) )
--- a/xen/arch/x86/include/asm/p2m.h
+++ b/xen/arch/x86/include/asm/p2m.h
@@ -879,6 +879,26 @@ static inline struct p2m_domain *p2m_get
return v->domain->arch.altp2m_p2m[index];
}
+/* set current alternate p2m table */
+static inline bool p2m_set_altp2m(struct vcpu *v, unsigned int idx)
+{
+ struct p2m_domain *orig;
+
+ BUG_ON(idx >= MAX_ALTP2M);
+
+ if ( idx == vcpu_altp2m(v).p2midx )
+ return false;
+
+ orig = p2m_get_altp2m(v);
+ BUG_ON(!orig);
+ atomic_dec(&orig->active_vcpus);
+
+ vcpu_altp2m(v).p2midx = idx;
+ atomic_inc(&v->domain->arch.altp2m_p2m[idx]->active_vcpus);
+
+ return true;
+}
+
/* Switch alternate p2m for a single vcpu */
bool_t p2m_switch_vcpu_altp2m_by_id(struct vcpu *v, unsigned int idx);
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1787,13 +1787,8 @@ bool_t p2m_switch_vcpu_altp2m_by_id(stru
if ( d->arch.altp2m_eptp[idx] != mfn_x(INVALID_MFN) )
{
- if ( idx != vcpu_altp2m(v).p2midx )
- {
- atomic_dec(&p2m_get_altp2m(v)->active_vcpus);
- vcpu_altp2m(v).p2midx = idx;
- atomic_inc(&p2m_get_altp2m(v)->active_vcpus);
+ if ( p2m_set_altp2m(v, idx) )
altp2m_vcpu_update_p2m(v);
- }
rc = 1;
}
@@ -2070,13 +2065,8 @@ int p2m_switch_domain_altp2m_by_id(struc
if ( d->arch.altp2m_visible_eptp[idx] != mfn_x(INVALID_MFN) )
{
for_each_vcpu( d, v )
- if ( idx != vcpu_altp2m(v).p2midx )
- {
- atomic_dec(&p2m_get_altp2m(v)->active_vcpus);
- vcpu_altp2m(v).p2midx = idx;
- atomic_inc(&p2m_get_altp2m(v)->active_vcpus);
+ if ( p2m_set_altp2m(v, idx) )
altp2m_vcpu_update_p2m(v);
- }
rc = 0;
}
++++++ bunzip-gcc13.patch ++++++
bunzip: work around gcc13 warning
While provable that length[0] is always initialized (because symCount
cannot be zero), upcoming gcc13 fails to recognize this and warns about
the unconditional use of the value immediately following the loop.
See also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106511.
Reported-by: Martin Liška <martin.li...@suse.com>
Signed-off-by: Jan Beulich <jbeul...@suse.com>
---
RFC: We've cloned this code from Linux and the code is unchanged there.
Therefore the same issue should exist there, and we may better get
whatever workaround is going to be applied there. But I'm unaware
of the issue, so far, having been observed in and reported against
Linux.
--- unstable.orig/xen/common/bunzip2.c 2022-03-29 15:48:15.000000000 +0200
+++ unstable/xen/common/bunzip2.c 2023-03-01 10:29:24.209241950 +0100
@@ -233,7 +233,7 @@ static int __init get_next_block(struct
becomes negative, so an unsigned inequality catches
it.) */
t = get_bits(bd, 5)-1;
- for (i = 0; i < symCount; i++) {
+ for (length[0] = i = 0; i < symCount; i++) {
for (;;) {
if (((unsigned)t) > (MAX_HUFCODE_BITS-1))
return RETVAL_DATA_ERROR;
