All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Philippe Mathieu-Daudé" <philmd@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
	peter.maydell@linaro.org, vsementsov@virtuozzo.com,
	qemu-devel@nongnu.org, qemu-block@nongnu.org
Subject: Re: [PATCH] iotests: Revert emulator selection to old behaviour
Date: Tue, 2 Feb 2021 16:40:47 +0100	[thread overview]
Message-ID: <6cc48ce0-96d0-4ac4-bd5d-d0ebf7325f01@redhat.com> (raw)
In-Reply-To: <20210202145627.GM4168502@redhat.com>

On 2/2/21 3:56 PM, Daniel P. Berrangé wrote:
> On Tue, Feb 02, 2021 at 03:46:11PM +0100, Philippe Mathieu-Daudé wrote:
>> On 2/2/21 3:28 PM, Kevin Wolf wrote:
>>> If the qemu-system-{arch} binary for the host architecture can't be
>>> found, the old 'check' implementation selected the alphabetically first
>>> system emulator binary that it could find. The new Python implementation
>>> just uses the first result of glob.iglob(), which has an undefined
>>> order.
>>>
>>> This is a problem that breaks CI because the iotests aren't actually
>>> prepared to run on any emulator. They should be, so this is really a bug
>>> in the failing test cases that should be fixed there, but as a quick
>>> fix, let's revert to the old behaviour to let CI runs succeed again.
>>
>> FWIW this is the same problem I had 1 year ago and tried to
>> fix it by sending QMP 'query-version' (introduced in v0.14):
>> https://www.mail-archive.com/qemu-devel@nongnu.org/msg675075.html
> 
> In the current failures the issue isn't the version number. Rather some
> of the tests (mistakenly) assume the emulator supports PCI, and we're
> randomly sometimes picking emulator targets that lack PCI.

Then this patch from the same series:
https://www.mail-archive.com/qemu-devel@nongnu.org/msg675088.html

It queries TYPE_DEVICE, but we can query TYPE_PCI_DEVICE too,
which should be selected if a machine have a TYPE_PCI_HOST_BRIDGE
providing a TYPE_PCI_BUS.

Anyway the idea is to query the binary with QMP to see if it makes
sens to run the test with it.

Regards,

Phil.



  reply	other threads:[~2021-02-02 16:01 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-02 14:28 [PATCH] iotests: Revert emulator selection to old behaviour Kevin Wolf
2021-02-02 14:35 ` Philippe Mathieu-Daudé
2021-02-02 14:41 ` Daniel P. Berrangé
2021-02-02 14:51   ` Kevin Wolf
2021-02-02 14:46 ` Philippe Mathieu-Daudé
2021-02-02 14:48   ` Philippe Mathieu-Daudé
2021-02-02 14:56   ` Daniel P. Berrangé
2021-02-02 15:40     ` Philippe Mathieu-Daudé [this message]
2021-02-02 14:54 ` Eric Blake
2021-02-02 15:48 ` Vladimir Sementsov-Ogievskiy

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=6cc48ce0-96d0-4ac4-bd5d-d0ebf7325f01@redhat.com \
    --to=philmd@redhat.com \
    --cc=berrange@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=vsementsov@virtuozzo.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.