qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] assert in memory.c line 1934 (was: Yet another fix for the


From: Thomas Huth
Subject: [Qemu-devel] assert in memory.c line 1934 (was: Yet another fix for the huge page support detection mechanism)
Date: Mon, 18 Jul 2016 15:16:01 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2

On 18.07.2016 12:44, Greg Kurz wrote:
> On Mon, 18 Jul 2016 11:33:16 +0200
> Thomas Huth <address@hidden> wrote:
> 
>> On 18.07.2016 11:26, Greg Kurz wrote:
>>> On Mon, 18 Jul 2016 11:04:39 +0200
>>> Thomas Huth <address@hidden> wrote:
>>>   
>>>> On 18.07.2016 10:59, Greg Kurz wrote:  
>>>>> On Mon, 18 Jul 2016 10:52:36 +1000
>>>>> David Gibson <address@hidden> wrote:
>>>>>     
>>>>>> On Fri, Jul 15, 2016 at 10:10:25AM +0200, Thomas Huth wrote:    
>>>>>>> Commit 86b50f2e1bef ("Disable huge page support if it is not available
>>>>>>> for main RAM") already made sure that huge page support is not announced
>>>>>>> to the guest if the normal RAM of non-NUMA configurations is not backed
>>>>>>> by a huge page filesystem. However, there is one more case that can go
>>>>>>> wrong: NUMA is enabled, but the RAM of the NUMA nodes are not configured
>>>>>>> with huge page support (and only the memory of a DIMM is configured with
>>>>>>> it). When QEMU is started with the following command line for example,
>>>>>>> the Linux guest currently crashes because it is trying to use huge pages
>>>>>>> on a memory region that does not support huge pages:
>>>>>>>
>>>>>>>  qemu-system-ppc64 -enable-kvm ... -m 1G,slots=4,maxmem=32G -object \
>>>>>>>    
>>>>>>> memory-backend-file,policy=default,mem-path=/hugepages,size=1G,id=mem-mem1
>>>>>>>  \
>>>>>>>    -device pc-dimm,id=dimm-mem1,memdev=mem-mem1 -smp 2 \
>>>>>>>    -numa node,nodeid=0 -numa node,nodeid=1
>>>>>>>
>>>>>>> To fix this issue, we've got to make sure to disable huge page support,
>>>>>>> too, when there is a NUMA node that is not using a memory backend with
>>>>>>> huge page support.
>>>>>>>
>>>>>>> Fixes: 86b50f2e1befc33407bdfeb6f45f7b0d2439a740
>>>>>>> Signed-off-by: Thomas Huth <address@hidden>
>>>>>>> ---
>>>>>>>  target-ppc/kvm.c | 10 +++++++---
>>>>>>>  1 file changed, 7 insertions(+), 3 deletions(-)      
>>>>>>
>>>>>> Applied to ppc-for-2.7, thanks.
>>>>>>    
>>>>>
>>>>> It looks like my replies to this patch were ignored... no big deal though 
>>>>> :)    
>>>>
>>>> I'll try to come up with an additional patch that fixes the remaining
>>>> problem that you've found... Meanwhile, did you find out why you get
>>>> that assertion that I was not able to recreate? Could you maybe post the
>>>> exact command line to trigger that assertion?
>>>>  
>>>
>>> I hit the assertion when I specify pc-dimm devices on the command line:
>>>
>>> qemu-system-ppc64 -enable-kvm ... -m 2G,slots=4,maxmem=32G \
>>>  -object 
>>> memory-backend-file,policy=default,mem-path=/mnt/kvm_hugepage,size=1G,id=mem-mem1
>>>  \
>>>  -device pc-dimm,id=dimm-mem1,memdev=mem-mem1 \
>>>  -object 
>>> memory-backend-file,policy=default,mem-path=/mnt,size=1G,id=mem-mem2 \
>>>  -device pc-dimm,id=dimm-mem2,memdev=mem-mem2 \
>>>  -smp 2 -numa node,nodeid=0,memdev=mem-mem1 \
>>>  -numa node,nodeid=1,memdev=mem-mem2  
>>
>> FWIW, with that command line, I still don't get an assertion but a
>> normal error message:
>>
>> qemu-system-ppc64: -device pc-dimm,id=dimm-mem1,memdev=mem-mem1: can't
>> use already busy memdev: mem-mem1
>>
>>  Thomas
>>
> 
> I hit the assertion with this exact command line:
> 
> qemu-system-ppc64 -machine pseries,accel=kvm \
> -m 1G,slots=4,maxmem=32G \
> -object 
> memory-backend-file,policy=default,mem-path=/dev/hugepages,size=1G,id=mem-mem1
>  \
> -device pc-dimm,id=dimm-mem1,memdev=mem-mem1 \
> -numa node,nodeid=0,memdev=mem-mem1 \
> -S
> 
> QEMU was built against David's ppc-for-2.7 branch (commit 159d2e39a).
> 
> But I get the very same error as you with QEMU 2.6... regression ?

Not sure why I didn't get the assertion before, but after switching back
and forth between another and the current master branch, I now get the
assertion, too:

qemu-system-ppc64: /home/thuth/devel/qemu/memory.c:1934:
memory_region_add_subregion_common: Assertion `!subregion->container'
failed.

I've bisected it to the following commit:

        2aece63c8a9d2c3a8ff41d2febc4cdeff2633331
        hostmem: detect host backend memory is being used properly

Xiao, Paolo, do you have any idea why this assert() can be triggered now?

 Thomas


Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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