On Mon, 18 Jul 2016 11:33:16 +0200 Thomas Huth <th...@redhat.com> wrote:
> On 18.07.2016 11:26, Greg Kurz wrote:
> > On Mon, 18 Jul 2016 11:04:39 +0200
> > Thomas Huth <th...@redhat.com> wrote:
> >
> >> On 18.07.2016 10:59, Greg Kurz wrote:
> >>> On Mon, 18 Jul 2016 10:52:36 +1000
> >>> David Gibson <da...@gibson.dropbear.id.au> 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 <th...@redhat.com>
> >>>>> ---
> >>>>> 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 ?
And BTW, I'm not sure to understand why it is wrong to specify both pc-dimm and
numa pointing to the same memory backend.
Cheers.
--
Greg
pgpf7etdHQbZB.pgp
Description: OpenPGP digital signature
