qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] hmp: fix "dump-quest-memory" segfault (ppc)


From: Laurent Vivier
Subject: Re: [Qemu-devel] [PATCH] hmp: fix "dump-quest-memory" segfault (ppc)
Date: Mon, 11 Sep 2017 14:15:17 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0

On 11/09/2017 14:13, Daniel P. Berrange wrote:
> On Mon, Sep 11, 2017 at 02:10:14PM +0200, Laurent Vivier wrote:
>> On 11/09/2017 14:04, Dr. David Alan Gilbert wrote:
>>> * Daniel P. Berrange (address@hidden) wrote:
>>>> On Mon, Sep 11, 2017 at 01:41:58PM +0200, Cornelia Huck wrote:
>>>>> On Mon, 11 Sep 2017 12:06:15 +0100
>>>>> "Daniel P. Berrange" <address@hidden> wrote:
>>>>>
>>>>>> On Mon, Sep 11, 2017 at 01:00:37PM +0200, Laurent Vivier wrote:
>>>>>>> Commit fd5d23babf (hmp: fix "dump-quest-memory" segfault)
>>>>>>> fixes the problem for i386, do the same for ppc.  
>>>>>>
>>>>>> What about all the other targets QEMU supports ?  Have you checked if 
>>>>>> they
>>>>>> are similarly affected, as we don't want to wait another 6 months to get 
>>>>>> a
>>>>>> bug report that s390 or aarch64 crash in exactly the same way too.
>>>>>
>>>>> This patch actually prompted me to check s390, and the mentioned
>>>>> command line works fine.
>>>>>
>>>>> However, if we start a qemu with no guest memory defined and then call
>>>>> dump-guest-memory without filtering, we get a core dump instead of a
>>>>> guest dump (s390x or x86_64, machine none).
>>>>>
>>>>> I can take a stab at fixing that, unless someone beats me to it.
>>>>
>>>> I wonder if someone wants to write a qtest job to run dump-guest-memory
>>>> across all machine types, on all targets. Seems we have enough crashiness
>>>> in this code to make it worthwhile to test
>>>
>>> We do have - that's how we found this case;  it's part of test-hmp.
>>
>> The test-hmp runs by default with 0 MB of memory, the problem can only
>> be found with some memory added to the machine.
>>
>> Perhaps we can simply update the test to add memory?
> 
> Probably best to run it twice, 0MB and with say 2MB, as they're both
> fairly magic values.

OK, I'm going to update the test.

Laurent




reply via email to

[Prev in Thread] Current Thread [Next in Thread]