exec.c | 39 ++++++++++++++++++++++++++++++++++---- hw/ppc/spapr_caps.c | 4 ++-- hw/s390x/s390-virtio-ccw.c | 12 ++++++++++++ hw/vfio/spapr.c | 2 +- target/ppc/kvm.c | 2 +- target/s390x/cpu.c | 7 +++++++ target/s390x/cpu.h | 1 + target/s390x/kvm-stub.c | 4 ++++ target/s390x/kvm.c | 35 ++++++++++++++-------------------- target/s390x/kvm_s390x.h | 1 + 10 files changed, 78 insertions(+), 29 deletions(-)
This is based on the patch
[PATCH for-4.0?] exec: Only count mapped memory backends for
qemu_getrampagesize()
While the detection on s390x of the maximum ram pagesize works by pure luck,
we should try to do better. Especially, once "-mem-path" is replaced
by memory backends, the current approach will break.
Configure the maximum page size after configuring initital memory. Provide
a function to detect the maximum ram pagesize
I think this can be deferred to 4.1 as I don't think anything is actually
broken right now.
v1 -> v2:
- Add a better comment describing that only initial memory is considered
- Add "exec: Introduce qemu_getmaxrampagesize() and rename
qemu_getrampagesize()"
David Hildenbrand (2):
s390x/kvm: Configure page size after memory has actually been
initialized
exec: Introduce qemu_getmaxrampagesize() and rename
qemu_getrampagesize()
exec.c | 39 ++++++++++++++++++++++++++++++++++----
hw/ppc/spapr_caps.c | 4 ++--
hw/s390x/s390-virtio-ccw.c | 12 ++++++++++++
hw/vfio/spapr.c | 2 +-
target/ppc/kvm.c | 2 +-
target/s390x/cpu.c | 7 +++++++
target/s390x/cpu.h | 1 +
target/s390x/kvm-stub.c | 4 ++++
target/s390x/kvm.c | 35 ++++++++++++++--------------------
target/s390x/kvm_s390x.h | 1 +
10 files changed, 78 insertions(+), 29 deletions(-)
--
2.17.2
Patchew URL: https://patchew.org/QEMU/20190328113458.8405-1-david@redhat.com/
Hi,
This series failed the asan build test. Please find the testing commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
#!/bin/bash
time make docker-test-debug@fedora TARGET_LIST=x86_64-softmmu J=14 NETWORK=1
=== TEST SCRIPT END ===
CC x86_64-softmmu/target/i386/mem_helper.o
CC x86_64-softmmu/target/i386/misc_helper.o
CC x86_64-softmmu/target/i386/mpx_helper.o
/tmp/qemu-test/src/hw/vfio/spapr.c:151:24: error: implicit declaration of function 'qemu_getminrampagesize' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
long rampagesize = qemu_getminrampagesize();
^
/tmp/qemu-test/src/hw/vfio/spapr.c:151:24: note: did you mean 'qemu_getrampagesize'?
/tmp/qemu-test/src/include/exec/ram_addr.h:76:6: note: 'qemu_getrampagesize' declared here
long qemu_getrampagesize(void);
^
/tmp/qemu-test/src/hw/vfio/spapr.c:151:24: error: this function declaration is not a prototype [-Werror,-Wstrict-prototypes]
long rampagesize = qemu_getminrampagesize();
^
2 errors generated.
make[1]: *** [/tmp/qemu-test/src/rules.mak:69: hw/vfio/spapr.o] Error 1
make[1]: *** Waiting for unfinished jobs....
/tmp/qemu-test/src/exec.c:1721:6: error: no previous prototype for function 'qemu_getminrampagesize' [-Werror,-Wmissing-prototypes]
long qemu_getminrampagesize(void)
^
/tmp/qemu-test/src/exec.c:1765:6: error: no previous prototype for function 'qemu_getmaxrampagesize' [-Werror,-Wmissing-prototypes]
long qemu_getmaxrampagesize(void)
^
2 errors generated.
The full log is available at
http://patchew.org/logs/20190328113458.8405-1-david@redhat.com/testing.asan/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-devel@redhat.com
Patchew URL: https://patchew.org/QEMU/20190328113458.8405-1-david@redhat.com/
Hi,
This series failed the docker-mingw@fedora build test. Please find the testing commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
#!/bin/bash
time make docker-test-mingw@fedora SHOW_ENV=1 J=14 NETWORK=1
=== TEST SCRIPT END ===
CC aarch64-softmmu/gdbstub-xml.o
CC aarch64-softmmu/trace/generated-helpers.o
CC aarch64-softmmu/target/arm/translate-sve.o
/tmp/qemu-test/src/exec.c:1776:6: error: no previous prototype for 'qemu_getminrampagesize' [-Werror=missing-prototypes]
long qemu_getminrampagesize(void)
^~~~~~~~~~~~~~~~~~~~~~
/tmp/qemu-test/src/exec.c:1780:6: error: no previous prototype for 'qemu_getmaxrampagesize' [-Werror=missing-prototypes]
long qemu_getmaxrampagesize(void)
^~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
make[1]: *** [/tmp/qemu-test/src/rules.mak:69: exec.o] Error 1
make: *** [Makefile:449: subdir-x86_64-softmmu] Error 2
make: *** Waiting for unfinished jobs....
/tmp/qemu-test/src/exec.c:1776:6: error: no previous prototype for 'qemu_getminrampagesize' [-Werror=missing-prototypes]
long qemu_getminrampagesize(void)
^~~~~~~~~~~~~~~~~~~~~~
/tmp/qemu-test/src/exec.c:1780:6: error: no previous prototype for 'qemu_getmaxrampagesize' [-Werror=missing-prototypes]
long qemu_getmaxrampagesize(void)
^~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
The full log is available at
http://patchew.org/logs/20190328113458.8405-1-david@redhat.com/testing.docker-mingw@fedora/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-devel@redhat.com
On 28.03.19 13:38, no-reply@patchew.org wrote: > Patchew URL: https://patchew.org/QEMU/20190328113458.8405-1-david@redhat.com/ > > > > Hi, > > This series failed the docker-mingw@fedora build test. Please find the testing commands and > their output below. If you have Docker installed, you can probably reproduce it > locally. > > === TEST SCRIPT BEGIN === > #!/bin/bash > time make docker-test-mingw@fedora SHOW_ENV=1 J=14 NETWORK=1 > === TEST SCRIPT END === > > CC aarch64-softmmu/gdbstub-xml.o > CC aarch64-softmmu/trace/generated-helpers.o > CC aarch64-softmmu/target/arm/translate-sve.o > /tmp/qemu-test/src/exec.c:1776:6: error: no previous prototype for 'qemu_getminrampagesize' [-Werror=missing-prototypes] > long qemu_getminrampagesize(void) > ^~~~~~~~~~~~~~~~~~~~~~ > /tmp/qemu-test/src/exec.c:1780:6: error: no previous prototype for 'qemu_getmaxrampagesize' [-Werror=missing-prototypes] > long qemu_getmaxrampagesize(void) > ^~~~~~~~~~~~~~~~~~~~~~ > cc1: all warnings being treated as errors > make[1]: *** [/tmp/qemu-test/src/rules.mak:69: exec.o] Error 1 > make: *** [Makefile:449: subdir-x86_64-softmmu] Error 2 > make: *** Waiting for unfinished jobs.... > /tmp/qemu-test/src/exec.c:1776:6: error: no previous prototype for 'qemu_getminrampagesize' [-Werror=missing-prototypes] > long qemu_getminrampagesize(void) > ^~~~~~~~~~~~~~~~~~~~~~ > /tmp/qemu-test/src/exec.c:1780:6: error: no previous prototype for 'qemu_getmaxrampagesize' [-Werror=missing-prototypes] > long qemu_getmaxrampagesize(void) > ^~~~~~~~~~~~~~~~~~~~~~ Yes, missed to commit a change. But let's see first if this is the right approach. -- Thanks, David / dhildenb
On Thu, 28 Mar 2019 12:34:56 +0100 David Hildenbrand <david@redhat.com> wrote: > This is based on the patch > [PATCH for-4.0?] exec: Only count mapped memory backends for > qemu_getrampagesize() > > While the detection on s390x of the maximum ram pagesize works by pure luck, > we should try to do better. Especially, once "-mem-path" is replaced > by memory backends, the current approach will break. > > Configure the maximum page size after configuring initital memory. Provide > a function to detect the maximum ram pagesize > > I think this can be deferred to 4.1 as I don't think anything is actually > broken right now. I agree. > > v1 -> v2: > - Add a better comment describing that only initial memory is considered > - Add "exec: Introduce qemu_getmaxrampagesize() and rename > qemu_getrampagesize()" > > David Hildenbrand (2): > s390x/kvm: Configure page size after memory has actually been > initialized I can queue that one to s390-next (not s390-fixes)... has this been tested? > exec: Introduce qemu_getmaxrampagesize() and rename > qemu_getrampagesize() > > exec.c | 39 ++++++++++++++++++++++++++++++++++---- > hw/ppc/spapr_caps.c | 4 ++-- > hw/s390x/s390-virtio-ccw.c | 12 ++++++++++++ > hw/vfio/spapr.c | 2 +- > target/ppc/kvm.c | 2 +- > target/s390x/cpu.c | 7 +++++++ > target/s390x/cpu.h | 1 + > target/s390x/kvm-stub.c | 4 ++++ > target/s390x/kvm.c | 35 ++++++++++++++-------------------- > target/s390x/kvm_s390x.h | 1 + > 10 files changed, 78 insertions(+), 29 deletions(-) >
>> David Hildenbrand (2): >> s390x/kvm: Configure page size after memory has actually been >> initialized > > I can queue that one to s390-next (not s390-fixes)... has this been tested? I will resend both patches (once I find some spare time ;) ). I will also try to test, nly have to find a setup where I can use huge pages. -- Thanks, David / dhildenb
© 2016 - 2024 Red Hat, Inc.