Fabiano, I think you forgot to reply-to-all.. adding back the list and
people in the loop.

On Thu, Feb 01, 2024 at 10:12:44AM -0300, Fabiano Rosas wrote:
> Peter Xu <pet...@redhat.com> writes:
> 
> > On Wed, Jan 31, 2024 at 10:09:16AM -0300, Fabiano Rosas wrote:
> >> If we ask for KVM and it falls back to TCG, we need a cpu that supports
> >> both. We don't have that. I've put some command-line combinations at the
> >> end of the email[1], take a look.
> >
> > Thanks a lot, Fabiano.  I think I have a better picture now.
> >
> > Now the question is whether it'll be worthwhile we (migration) explicitly
> > provide code to workaround such issue in qtest, or we wait for ARM side
> > until we have a processor that can be both stable and support KVM+TCG.
> >
> > I actually personally prefer to wait - it's not too bad after all, because
> > it only affects the new "n-1" migration test.  Most of the migration
> > functionality will still be covered there in CI for ARM.
> 
> That's fine with me. We just need to do something about the arm CI job
> which is currently disabled waiting for a fix. We could remove it or add
> some words somewhere explaining the situation. I can do that once we
> reach an agreement here.

Yes.  IMHO we can keep the test (with SKIPPED=1) but amend the message,
which will start to state inaccurately:

        # This job is disabled until we release 9.0. The existing
        # migration-test in 8.2 is broken on aarch64. The fix was already
        # commited, but it will only take effect once 9.0 is out.

IMHO then it won't mean 9.0 will have it fixed, but we'll simply wait for a
cpu model that is ready for both kvm+tcg, then we replace "max".

For gic_version, I knew 3 was there for quite some time so maybe we can
start from that?  Or we need suggestions from ARM people.

-- 
Peter Xu


Reply via email to