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.
next prev parent 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.