qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Juan Quintela <quintela@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: "Fabiano Rosas" <farosas@suse.de>,
	"Philippe Mathieu-Daudé" <philmd@linaro.org>,
	qemu-devel@nongnu.org, "Peter Xu" <peterx@redhat.com>,
	"Thomas Huth" <thuth@redhat.com>,
	"Laurent Vivier" <lvivier@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Leonardo Bras" <leobras@redhat.com>,
	"Alex Bennée" <alex.bennee@linaro.org>
Subject: Re: [RFC PATCH 1/1] qtest/migration: Support more than one QEMU binary
Date: Wed, 04 Oct 2023 20:09:49 +0200	[thread overview]
Message-ID: <875y3ms1hu.fsf@secure.mitica> (raw)
In-Reply-To: <ZR2nTmmf8AaUV1g2@redhat.com> ("Daniel P. Berrangé"'s message of "Wed, 4 Oct 2023 18:56:30 +0100")

Daniel P. Berrangé <berrange@redhat.com> wrote:
> On Wed, Oct 04, 2023 at 12:59:49PM -0300, Fabiano Rosas wrote:
>> Juan Quintela <quintela@redhat.com> writes:
>> 
>> > Fabiano Rosas <farosas@suse.de> wrote:
>> >> Daniel P. Berrangé <berrange@redhat.com> writes:
>> >>
>> >>> On Tue, Oct 03, 2023 at 05:24:50PM +0200, Philippe Mathieu-Daudé wrote:
>> > [...]

>> I'm working on a cleanup of this patch to make it more integrated with
>> libqtest. If we teach qtest_get_machines() to sometimes refresh the list
>> of machines then it becomes way less code.
>> 
>> > I think that it is just easier to pass the machine type we want to test
>> > to whatever script we have.  Specially where [sane] architectures like
>> > arm don't have a default machine type (no, I haven't double checked if
>> > that has changed lately).
>> 
>> We still need to enforce the same machine type for both binaries and a
>> sane range of QEMU versions. I think our docs state that we only support
>> migration from QEMU n->n+1 and vice versa? If the test will know what
>> combinations are allowed, it could just go ahead and use those.
>
> Query the 'pc' (or 'q35' as appropriate) alias on both QEMU versions,
> to resolve them into versioned machines.
>
> Then find which resolved machine version(s) exist in both QEMUs, and
> prefer the src machine if multiple matches exist.

We only change Machine Type with each qemu version, so having to change
it by hand don't look so complicated.

Let's assume for a moment that "pc" and "q35" machine types don't exist
(rest of architectures needs to do a similar thing)

latest qemu has:
pc-i440fx-8.2        Standard PC (i440FX + PIIX, 1996) (default)
pc-i440fx-8.1        Standard PC (i440FX + PIIX, 1996) (default)
pc-i440fx-8.0        Standard PC (i440FX + PIIX, 1996) (default)
pc-i440fx-7.2        Standard PC (i440FX + PIIX, 1996) (default)

Previous version one has everything except 8.2

We want to test:

(this is what we do now)
qemu-8.2 -M pc-i440fx-8.2  -> qemu-8.2 -M pc-i440fx-8.2

And we want to test additionally:

qemu-8.1 -M pc-i440fx-8.1  -> qemu-8.2 -M pc-i440fx-8.1
qemu-8.2 -M pc-i440fx-8.1  -> qemu-8.1 -M pc-i440fx-8.1

And that is it.

So the thing that we need is a sane way to get qtest_init() to use the
right machine type without inventing what machine type they want.  Not
having a default machine type has other advantages, but that is a
different discussion.

Later, Juan.



  reply	other threads:[~2023-10-04 18:10 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-03 14:19 [RFC PATCH 0/1] tests/migration-test: Allow testing older machine types Fabiano Rosas
2023-10-03 14:19 ` [RFC PATCH 1/1] qtest/migration: Support more than one QEMU binary Fabiano Rosas
2023-10-03 15:24   ` Philippe Mathieu-Daudé
2023-10-03 15:54     ` Daniel P. Berrangé
2023-10-03 16:24       ` Fabiano Rosas
2023-10-04  8:45         ` Juan Quintela
2023-10-04 15:59           ` Fabiano Rosas
2023-10-04 17:56             ` Daniel P. Berrangé
2023-10-04 18:09               ` Juan Quintela [this message]
2023-10-04 18:21                 ` Thomas Huth

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=875y3ms1hu.fsf@secure.mitica \
    --to=quintela@redhat.com \
    --cc=alex.bennee@linaro.org \
    --cc=berrange@redhat.com \
    --cc=farosas@suse.de \
    --cc=leobras@redhat.com \
    --cc=lvivier@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=philmd@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).