qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [Qemu-ppc] [PATCH] ppc: Yet another fix for the huge pa


From: Thomas Huth
Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH] ppc: Yet another fix for the huge page support detection mechanism
Date: Mon, 18 Jul 2016 11:04:39 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2

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?

 Thomas


Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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