[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] qtest: add a reproducer for LP#1878642
From: |
Philippe Mathieu-Daudé |
Subject: |
Re: [PATCH] qtest: add a reproducer for LP#1878642 |
Date: |
Tue, 16 Feb 2021 18:31:08 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 |
On 2/16/21 4:00 PM, Alexander Bulekov wrote:
> On 210216 1325, Peter Maydell wrote:
>> On Mon, 2 Nov 2020 at 16:35, Alexander Bulekov <alxndr@bu.edu> wrote:
>>>
>>> https://bugs.launchpad.net/qemu/+bug/1878642
>>>
>>> Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
>>> Signed-off-by: Alexander Bulekov <alxndr@bu.edu>
>>> ---
>>>
>>> Based-on: <20200717151705.18611-1-f4bug@amsat.org>
>>>
>>> The added testcase will fail, unless this ^^^ patch is applied.
>>>
>>> tests/qtest/fuzz-test.c | 15 +++++++++++++++
>>> 1 file changed, 15 insertions(+)
>>>
>>> diff --git a/tests/qtest/fuzz-test.c b/tests/qtest/fuzz-test.c
>>> index 2f38bb1ec2..9cb4c42bde 100644
>>> --- a/tests/qtest/fuzz-test.c
>>> +++ b/tests/qtest/fuzz-test.c
>>> @@ -34,6 +34,19 @@ static void test_lp1878263_megasas_zero_iov_cnt(void)
>>> qtest_quit(s);
>>> }
>>>
>>> +static void test_lp1878642_pci_bus_get_irq_level_assert(void)
>>> +{
>>> + QTestState *s;
>>> +
>>> + s = qtest_init("-M pc-q35-5.0 "
>>> + "-nographic -monitor none -serial none "
>>> + "-d guest_errors -trace pci*");
>>> +
>>> + qtest_outl(s, 0xcf8, 0x8400f841);
>>> + qtest_outl(s, 0xcfc, 0xebed205d);
>>> + qtest_outl(s, 0x5d02, 0xebed205d);
>>> +}
>>
>> Hi; I just noticed this, but why does this test case pass
>> "-trace pci*" to QEMU? It doesn't look like it does anything to
>> try to capture the trace output, which thus winds up just going
>> to the stdout/stderr of the "make check" run. Similarly I'm not
>> sure '-d guest_errors' is going to do anything helpful unless
>> you take steps to capture the output and check it.
I suppose Alex took it from commit 4177b062fc5 ("hw/isa/lpc_ich9:
Ignore reserved/invalid SCI IRQ") where it is used to show the
problem the fuzzer reproducer triggers. Not useful in regular testing.
> Ah, I sometimes include those in the initial report, if the device has
> trace-events. I can remove this from fuzz-test.c, if it is slowing
> things down.
I doubt it is slowing things down, but it probably make it harder to
find other problems (I suppose Peter got confused when looking for
another failure and found these traces).