We plan to drop unsupported CPU types for AArch64. We should do that first, as it may allow us to drop downstream-only changes and build dependencies we currently have in the QEMU RHEL rebase patch series.

QE bot(pre verify): Set 'Verified:Tested,SanityOnly' as gating/tier1 test pass.

Jing, Yanan, I need your help understanding something before the rebase makes it to the nightly; I'm removing the Verified:Tested that was set automatically by the QE bot. We can set the flag again ASAP but would like to know your thoughts. I'm sorry if there have been discussion already that I missed.

In short,

a) The last time we rebased, we broke the nightly for a while until libvirt could deliver their changes[1]
b) In the "Depends On" of this BZ, there are several BZs that have an even later DTM than the ITM of this BZ - this is something that confuses me; does it mean we have to finish the machine compatibility type before the rebase can be tested?
   More specifically for [2], the DTM is set to 

IIRC, in order to target a) in the s390x team we discussed we'd like to minimally want to run our Critical Regression tests (Tier1/Acceptance Tests) with minimal libvirt-integration coverage for this rebase.

Please can you help me? I'm somewhat confused as to understand if we should - if possible - urgently look into [2] in the s390x team, or should we maybe reach out to the "Depends On" assignees?


[1]https://bugzilla.redhat.com/show_bug.cgi?id=2027697#c6
[2]https://bugzilla.redhat.com/show_bug.cgi?id=2064782

(In reply to smitterl from comment #3)
> Jing, Yanan, I need your help understanding something before the rebase
> makes it to the nightly; I'm removing the Verified:Tested that was set
> automatically by the QE bot. We can set the flag again ASAP but would like
> to know your thoughts. I'm sorry if there have been discussion already that
> I missed.
> 
> In short,
> 
> a) The last time we rebased, we broke the nightly for a while until libvirt
> could deliver their changes[1]
> b) In the "Depends On" of this BZ, there are several BZs that have an even
> later DTM than the ITM of this BZ - this is something that confuses me; does
> it mean we have to finish the machine compatibility type before the rebase
> can be tested?
    More specifically for [2], the DTM is set to 11 > ITM of this rebase BZ.
    And for the [3], that doesn't seem to even have a release+ yet.
> 
> IIRC, in order to target a) in the s390x team we discussed we'd like to
> minimally want to run our Critical Regression tests (Tier1/Acceptance Tests)
> with minimal libvirt-integration coverage for this rebase.
> 
> Please can you help me? I'm somewhat confused as to understand if we should
> - if possible - urgently look into [2] in the s390x team, or should we maybe
> reach out to the "Depends On" assignees?
> 
> 
> [1]https://bugzilla.redhat.com/show_bug.cgi?id=2027697#c6
> [2]https://bugzilla.redhat.com/show_bug.cgi?id=2064782
[3]https://bugzilla.redhat.com/show_bug.cgi?id=2066824

(In reply to smitterl from comment #3)
> Jing, Yanan, I need your help understanding something before the rebase
...
> IIRC, in order to target a) in the s390x team we discussed we'd like to
> minimally want to run our Critical Regression tests (Tier1/Acceptance Tests)
> with minimal libvirt-integration coverage for this rebase.
...before it make it into the nightly (ie. before setting Verified:Tested).

(Sorry, I've been re-reading my comment several times and want to be extra-sure to be very explicit and avoid any misunderstandings.)
> Please can you help me? I'm somewhat confused as to understand if we should
> - if possible - urgently look into [2] in the s390x team, or should we maybe
> reach out to the "Depends On" assignees?
> 
> 
> [1]https://bugzilla.redhat.com/show_bug.cgi?id=2027697#c6
> [2]https://bugzilla.redhat.com/show_bug.cgi?id=2064782

(In reply to smitterl from comment #4)
> > b) In the "Depends On" of this BZ, there are several BZs that have an even
> > later DTM than the ITM of this BZ - this is something that confuses me; does
> > it mean we have to finish the machine compatibility type before the rebase
> > can be tested?
>     More specifically for [2], the DTM is set to 11 > ITM of this rebase BZ.
>     And for the [3], that doesn't seem to even have a release+ yet.
> > 
> > IIRC, in order to target a) in the s390x team we discussed we'd like to
> > minimally want to run our Critical Regression tests (Tier1/Acceptance Tests)
> > with minimal libvirt-integration coverage for this rebase.
> > 
> > Please can you help me? I'm somewhat confused as to understand if we should
> > - if possible - urgently look into [2] in the s390x team, or should we maybe
> > reach out to the "Depends On" assignees?
> > 
> > [1]https://bugzilla.redhat.com/show_bug.cgi?id=2027697#c6
> > [2]https://bugzilla.redhat.com/show_bug.cgi?id=2064782

The DTM in [2] is likely just my bad - I thought I had to wait for the upstream QEMU v.7.0.0 release here first, but actually the work could already be done with the rebases to the release candidates that Mirek did. I've now changed it to DTM 8 instead. And the patch has already been included in the 7.0 rebase version - so we could maybe even already close 2064782 if that works better for you now (if you just want to test this BZ here instead).

Concerning BZ 2066824 , I guess the dependency should rather be the other way round, so that this BZ here blocks the aarch64 BZ? @drjones ?

Removed cpu removal bz dependency as we do not need this for the rebase (it was added as good to do but wasn't done).

Thanks everybody,

to sum up, also considering the offline email thread and sync with Boqiao, I understand the following, please shout if I misunderstood:

1. "Depends On": only missing s390x machine type compatibility pre-verification; scope:
    - qemu-level and libvirt-level critical regression tests
    - bi-directional cross-migration test 8.7 -> 9.1 -> 8.7
2. the missing s390x machine type compatibility is now in MODIFIED and aligned with this BZ's DTM/ITM
3. Boqiao and I will prioritize scope in 1. above - most likely running the tests today already - and expect to set Verified:Tested on 1. and then on this very BZ latest EOW.

Thanks everybody for their help! :D

(removing needinfo: Jing because we clarified offline)

(In reply to Thomas Huth from comment #6)
> Concerning BZ 2066824 , I guess the dependency should rather be the other
> way round, so that this BZ here blocks the aarch64 BZ? @drjones ?

Actually I was hoping to work bug 2066824 jointly, as removing CPU types allows downstream-only hacks to be removed from the rebase. If it's easier to do the rebase as it is now and then for me to fixup the rebase after removing CPU types, then we can indeed flip the dependency for 9.1. For 9.2, the rebase can merge in the fixups.

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: qemu-kvm 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:7967