qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] exec.c: check RAMBlock validity before changing


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH] exec.c: check RAMBlock validity before changing its flag
Date: Thu, 5 Jul 2018 14:01:42 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0

On 05/07/2018 07:56, Cédric Le Goater wrote:
> Hello Paolo,
> 
> On 07/04/2018 02:16 PM, Paolo Bonzini wrote:
>> On 04/07/2018 11:55, Peter Xu wrote:
>>>>     commit b0e56e0b63f350691b52d3e75e89bb64143fbeff
>>>>     Author: Hu Tao <address@hidden>
>>>>     Date:   Wed Apr 2 15:13:27 2014 +0800
>>>>
>>>>     unset RAMBlock idstr when unregister MemoryRegion
>>>>
>>>>     Signed-off-by: Hu Tao <address@hidden>
>>>>     Signed-off-by: Paolo Bonzini <address@hidden>
>>>>
>>>> whose commit message is a bit lacking, but
>>>> http://lists.gnu.org/archive/html/qemu-devel/2014-04/msg00282.html helps
>>>> more.  It seems like the original bug was a reference count issue.
>>>>
>>>> Clearing the new migratable flag should also be unnecessary.
>>> But even if we get rid of vmstate_unregister_ram(), the leak could
>>> still be there?
>>>
>>> I'm not sure what was leaked when b0e56e0b6 was introduced, I feel
>>> like it's the RAMBlock of the memdev.  Here I think the ROM memory
>>> region seems to be leaked as well (along with the RAMBlock inside)?
>>
>> The leak would be another bug that vmstate_unregister_ram is just
>> papering over.  We need to test memory unplug with
>> vmstate_unregister_ram removed, and fix bugs if any.
> 
> So for the time being, you would just get rid of pci_del_option_rom()
> which only does vmstate_unregister_ram() ? 

Yes, I think so.

Paolo



reply via email to

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