qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Cleber Rosa <crosa@redhat.com>
To: Wainer dos Santos Moschetta <wainersm@redhat.com>
Cc: wrampazz@redhat.com, alex.bennee@linaro.org,
	qemu-devel@nongnu.org, pavel.dovgaluk@ispras.ru,
	pbonzini@redhat.com, philmd@redhat.com, aurelien@aurel32.net
Subject: Re: [PATCH 0/3] tests/acceptance: Handle tests with "cpu" tag
Date: Tue, 9 Mar 2021 13:52:37 -0500	[thread overview]
Message-ID: <20210309185237.GB2155904@amachine.somewhere> (raw)
In-Reply-To: <20210224212654.1146167-1-wainersm@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 2409 bytes --]

On Wed, Feb 24, 2021 at 06:26:51PM -0300, Wainer dos Santos Moschetta wrote:
> Currently the acceptance tests tagged with "machine" have the "-M TYPE"
> automatically added to the list of arguments of the QEMUMachine object.
> In other words, that option is passed to the launched QEMU. On this
> series it is implemented the same feature but instead for tests marked
> with "cpu".
>

Good!

> There is a caveat, however, in case the test needs additional arguments to
> the CPU type they cannot be passed via tag, because the tags parser split
> values by comma. For example, in tests/acceptance/x86_cpu_model_versions.py,
> there are cases where:
> 
>   * -cpu is set to "Cascadelake-Server,x-force-features=on,check=off,enforce=off"
>   * if it was tagged like "cpu:Cascadelake-Server,x-force-features=on,check=off,enforce=off"
>     then the parser would break it into 4 tags ("cpu:Cascadelake-Server",
>     "x-force-features=on", "check=off", "enforce=off")
>   * resulting on "-cpu Cascadelake-Server" and the remaining arguments are ignored.
> 
> For the example above, one should tag it (or not at all) as "cpu:Cascadelake-Server"
> AND self.vm.add_args('-cpu', "Cascadelake-Server,x-force-features=on,check=off,enforce=off"),
> and that results on something like:
> 
>   "qemu-system-x86_64 (...) -cpu Cascadelake-Server -cpu Cascadelake-Server,x-force-features=on,check=off,enforce=off".
>

There are clearly two problems here:

1) the tag is meant to be succinct, so that it can be used by users
   selecting which tests to run.  At the same time, it's a waste
   to throw away the other information or keep it duplicate or
   incosistent.

2) QEMUMachine doesn't keep track of command line arguments
   (add_args() makes it pretty clear what's doing).  But, on this type
   of use case, a "set_args()" is desirable, in which case it would
   overwrite the existing arguments for a given command line option.

> QEMU is going to ignore the first -cpu argument. See the patch 0003 for a reference.
>

But this would still be creating a QEMU command line with multiple
'-cpu' arguments, right?  I understand this could be useful for
testing the behavior of the parameter parsing (if that's intended) but
it's bad practice to be generating incorrect command line in tests.

Maybe just by tackling issue #2 this could be avoided.

Cheers,
- Cleber.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  parent reply	other threads:[~2021-03-09 20:30 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-24 21:26 [PATCH 0/3] tests/acceptance: Handle tests with "cpu" tag Wainer dos Santos Moschetta
2021-02-24 21:26 ` [PATCH 1/3] tests/acceptance: Automatic set -cpu to the test vm Wainer dos Santos Moschetta
2021-03-09 18:40   ` Cleber Rosa
2021-02-24 21:26 ` [PATCH 2/3] tests/acceptance: Let the framework handle "cpu:VALUE" tagged tests Wainer dos Santos Moschetta
2021-03-09 19:04   ` Cleber Rosa
2021-02-24 21:26 ` [PATCH 3/3] tests/acceptance: Tagging tests with "cpu:VALUE" Wainer dos Santos Moschetta
2021-03-09 19:18   ` Cleber Rosa
2021-03-09 18:52 ` Cleber Rosa [this message]
2021-03-17 19:16   ` [PATCH 0/3] tests/acceptance: Handle tests with "cpu" tag Wainer dos Santos Moschetta
2021-03-23 21:01     ` John Snow
2021-04-07 20:01       ` Eduardo Habkost
2021-04-09 14:53         ` Wainer dos Santos Moschetta
2021-05-14 19:36           ` John Snow

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=20210309185237.GB2155904@amachine.somewhere \
    --to=crosa@redhat.com \
    --cc=alex.bennee@linaro.org \
    --cc=aurelien@aurel32.net \
    --cc=pavel.dovgaluk@ispras.ru \
    --cc=pbonzini@redhat.com \
    --cc=philmd@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=wainersm@redhat.com \
    --cc=wrampazz@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).