Hello guys I got to bisect it reliably (2/2) to the commit:

f5cc5a5c168674f84bf061cdb307c2d25fba5448 is the first bad commit
commit f5cc5a5c168674f84bf061cdb307c2d25fba5448
Author: Claudio Fontana <cfontana>
Date:   Mon Mar 22 14:27:40 2021 +0100

    i386: split cpu accelerators from cpu.c, using AccelCPUClass
    
    i386 is the first user of AccelCPUClass, allowing to split
    cpu.c into:
    
    cpu.c            cpuid and common x86 cpu functionality
    host-cpu.c       host x86 cpu functions and "host" cpu type
    kvm/kvm-cpu.c    KVM x86 AccelCPUClass
    hvf/hvf-cpu.c    HVF x86 AccelCPUClass
    tcg/tcg-cpu.c    TCG x86 AccelCPUClass
    
    Signed-off-by: Claudio Fontana <cfontana>
    Reviewed-by: Alex Bennée <alex.bennee>
    Reviewed-by: Richard Henderson <richard.henderson>
    
    [claudio]:
    Rebased on commit b8184135 ("target/i386: allow modifying TCG phys-addr-bits")
    
    Signed-off-by: Claudio Fontana <cfontana>
    Message-Id: <20210322132800.7470-5-cfontana>
    Signed-off-by: Paolo Bonzini <pbonzini>


Bisect log:
# bad: [c8616fc7670b884de5f74d2767aade224c1c5c3a] Merge remote-tracking branch 'remotes/philmd/tags/gitlab-ci-20210527' into staging
# good: [d90f154867ec0ec22fd719164b88716e8fd48672] Merge remote-tracking branch 'remotes/dg-gitlab/tags/ppc-for-6.1-20210504' into staging
git bisect start 'c8616fc7670b884de5f74d2767aade224c1c5c3a' 'd90f154867ec0ec22fd719164b88716e8fd48672'
# bad: [068479e1e1d680ac246f12aaaacf2c5e1a0bd97b] hw/ppc/spapr.c: Extract MMU mode error reporting into a function
git bisect bad 068479e1e1d680ac246f12aaaacf2c5e1a0bd97b
# bad: [052b66e7211af64964e005126eaa3c944b296b0e] pc-bios/s390-ccw: Fix inline assembly for older versions of Clang
git bisect bad 052b66e7211af64964e005126eaa3c944b296b0e
# good: [a5ccdccc97d6e0d75282ede5b866cf694e9602b0] Merge remote-tracking branch 'remotes/kraxel/tags/vga-20210510-pull-request' into staging
git bisect good a5ccdccc97d6e0d75282ede5b866cf694e9602b0
# good: [c30a0757f094c107e491820e3d35224eb68859c7] target/riscv: Fix the RV64H decode comment
git bisect good c30a0757f094c107e491820e3d35224eb68859c7
# bad: [5ecfb76ccc056eb6127e44268e475827ae73b9e0] configure: fix detection of gdbus-codegen
git bisect bad 5ecfb76ccc056eb6127e44268e475827ae73b9e0
# bad: [30493a030ff154fc9ea5f91a848c6ec7a018efa1] i386: split seg_helper into user-only and sysemu parts
git bisect bad 30493a030ff154fc9ea5f91a848c6ec7a018efa1
# bad: [9ea057dc641b150ecbfd45acfe18fe043641a551] accel-cpu: make cpu_realizefn return a bool
git bisect bad 9ea057dc641b150ecbfd45acfe18fe043641a551
# bad: [f5cc5a5c168674f84bf061cdb307c2d25fba5448] i386: split cpu accelerators from cpu.c, using AccelCPUClass
git bisect bad f5cc5a5c168674f84bf061cdb307c2d25fba5448
# good: [0ac2b197430ebf19b5575ea48fe3b76d62110ab9] target/i386: Split out do_fsave, do_frstor, do_fxsave, do_fxrstor
git bisect good 0ac2b197430ebf19b5575ea48fe3b76d62110ab9
# first bad commit: [f5cc5a5c168674f84bf061cdb307c2d25fba5448] i386: split cpu accelerators from cpu.c, using AccelCPUClass

Assigned to Amnon for initial triage per bz process and age of bug created or assigned to virt-maint without triage.

Hello guys, I noticed the pipeline seems to be working well now so I bisected the fix up to:

4db4385a7ab6512e9af08305f5725b26c8a980ee is the first bad commit
commit 4db4385a7ab6512e9af08305f5725b26c8a980ee
Author: Claudio Fontana <cfontana>
Date:   Thu Jun 3 14:30:01 2021 +0200

    i386: run accel_cpu_instance_init as post_init
    
    This fixes host and max cpu initialization, by running the accel cpu
    initialization only after all instance init functions are called for all
    X86 cpu subclasses.
    
    The bug this is fixing is related to the "max" and "host" i386 cpu
    subclasses, which set cpu->max_features, which is then used at cpu
    realization time.
    
    In order to properly split the accel-specific max features code that
    needs to be executed at cpu instance initialization time,
    
    we cannot call the accel cpu initialization at the end of the x86 base
    class initialization, or we will have no way to specialize
    "max features" cpu behavior, overriding the "max" cpu class defaults,
    and checking for the "max features" flag itself.
    
    This patch moves the accel-specific cpu instance initialization to after
    all x86 cpu instance code has been executed, including subclasses,
    
    so that proper initialization of cpu "host" and "max" can be restored.
    
    Fixes: f5cc5a5c ("i386: split cpu accelerators from cpu.c,"...)
    Cc: Eduardo Habkost <ehabkost>
    Cc: Paolo Bonzini <pbonzini>
    Signed-off-by: Claudio Fontana <cfontana>
    Message-Id: <20210603123001.17843-3-cfontana>
    Signed-off-by: Paolo Bonzini <pbonzini>

 target/i386/cpu.c | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)
bisect run success

I think it makes sense and hopefully this issue is resolved (we just need to make sure this patch is in after rebase)

I don't understand what we're supposed to do with this BZ.  The bug is already fixed upstream and it was never present in an official RHEL-8 build or even in a released upstream version.

What's the right state for this BZ?  I don't think it makes sense to keep it open.

I'm not sure either. Depends whether it requires additional QA coverage to prevent such regression or not.

(In reply to Lukas Doktor from comment #10)
> I'm not sure either. Depends whether it requires additional QA coverage to
> prevent such regression or not.

A question for QE and our maintainers: let's assume we want QE to verify this bug after we officially rebase to 6.1 (in 8.6).  What's the right status of this BZ if we want to do that?

Hi, could you please grant QA_ACK?

(In reply to Danilo Cesar Lemes de Paula from comment #13)
> Hi, could you please grant QA_ACK?

Sure and done, thanks.

Test PASS with configuration in attachments and guest works well.

Test Env:
    qemu-kvm-6.1.0-2.module+el8.6.0+12861+13975d62.x86_64
    4.18.0-348.4.el8.x86_64
Guest:4.18.0-348.2.el8.x86_64


Move this bug to verified now, thanks.



Best regards
Liu Nana

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: virt:rhel and virt-devel:rhel security, bug fix, and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2022:1759