From: Alexander Graf <agraf@suse.de>
To: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: Jens Freimann <jfrei@de.ibm.com>,
Cornelia Huck <cornelia.huck@de.ibm.com>,
Jens Freimann <jfrei@linux.vnet.ibm.com>,
Heinz Graalfs <graalfs@linux.vnet.ibm.com>,
qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH 2/8] s390: autodetect map private
Date: Tue, 12 Jun 2012 13:57:54 +0200 [thread overview]
Message-ID: <4FD72EC2.2010105@suse.de> (raw)
In-Reply-To: <4FD725EB.7050501@de.ibm.com>
On 06/12/2012 01:20 PM, Christian Borntraeger wrote:
>> Is there any way we can move the above code to target-s390x? Having the
>> branch below is already invasive enough for generic code, but we really
>> don't need all the special s390 quirks to live here.
>
> Hmm, we have to have a special hook somehow.
> What about this approach?
>
> -----------------------
>
> By default qemu will use MAP_PRIVATE for guest pages. This will write
> protect pages and thus break on s390 systems that dont support this feature.
> Therefore qemu has a hack to always use MAP_SHARED for s390. But MAP_SHARED
> has other problems (no dirty pages tracking, a lot more swap overhead etc.)
> Newer systems allow the distinction via KVM_CAP_S390_COW. With this feature
> qemu can use the standard qemu alloc if available, otherwise it will use
> the old s390 hack.
>
> Signed-off-by: Christian Borntraeger<borntraeger@de.ibm.com>
> ---
> exec.c | 19 ++++---------------
> kvm.h | 1 +
> oslib-posix.c | 3 +++
> target-s390x/kvm.c | 34 ++++++++++++++++++++++++++++++++++
> 4 files changed, 42 insertions(+), 15 deletions(-)
>
> diff --git a/exec.c b/exec.c
> index a587e7a..9b9b8e1 100644
> --- a/exec.c
> +++ b/exec.c
> @@ -2645,26 +2645,15 @@ ram_addr_t qemu_ram_alloc_from_ptr(ram_addr_t size, void *host,
> exit(1);
> #endif
> } else {
> -#if defined(TARGET_S390X)&& defined(CONFIG_KVM)
> - /* S390 KVM requires the topmost vma of the RAM to be smaller than
> - an system defined value, which is at least 256GB. Larger systems
> - have larger values. We put the guest between the end of data
> - segment (system break) and this value. We use 32GB as a base to
> - have enough room for the system break to grow. */
> - new_block->host = mmap((void*)0x800000000, size,
> - PROT_EXEC|PROT_READ|PROT_WRITE,
> - MAP_SHARED | MAP_ANONYMOUS | MAP_FIXED, -1, 0);
> - if (new_block->host == MAP_FAILED) {
> - fprintf(stderr, "Allocating RAM failed\n");
> - abort();
> - }
> -#else
> if (xen_enabled()) {
> xen_ram_alloc(new_block->offset, size, mr);
> +#if defined(TARGET_S390X)
> + } else if (kvm_enabled()) {
> + new_block->host = kvm_arch_alloc(size);
Since it lives in an s390 specific branch, the function name should
probably be called s390 specific. If we ever need another architecture
to have a kvm specific ram allocator, we can make it generic when that
time comes. Until then, let's treat s390 as the oddball it is :).
Apart from that, this approach looks a lot nicer, yes.
Alex
> +#endif
> } else {
> new_block->host = qemu_vmalloc(size);
> }
> -#endif
> qemu_madvise(new_block->host, size, QEMU_MADV_MERGEABLE);
> }
> }
> diff --git a/kvm.h b/kvm.h
> index 9c7b0ea..9d50016 100644
> --- a/kvm.h
> +++ b/kvm.h
> @@ -102,6 +102,7 @@ int kvm_vcpu_ioctl(CPUArchState *env, int type, ...);
>
> extern const KVMCapabilityInfo kvm_arch_required_capabilities[];
>
> +void *kvm_arch_alloc(ram_addr_t size);
> void kvm_arch_pre_run(CPUArchState *env, struct kvm_run *run);
> void kvm_arch_post_run(CPUArchState *env, struct kvm_run *run);
>
> diff --git a/oslib-posix.c b/oslib-posix.c
> index b6a3c7f..93902ac 100644
> --- a/oslib-posix.c
> +++ b/oslib-posix.c
> @@ -41,6 +41,9 @@ extern int daemon(int, int);
> therefore we need special code which handles running on Valgrind. */
> # define QEMU_VMALLOC_ALIGN (512 * 4096)
> # define CONFIG_VALGRIND
> +#elif defined(__linux__)&& defined(__s390x__)
> + /* Use 1 MiB (segment size) alignment so gmap can be used by KVM. */
> +# define QEMU_VMALLOC_ALIGN (256 * 4096)
> #else
> # define QEMU_VMALLOC_ALIGN getpagesize()
> #endif
> diff --git a/target-s390x/kvm.c b/target-s390x/kvm.c
> index 90aad61..ccf5daa 100644
> --- a/target-s390x/kvm.c
> +++ b/target-s390x/kvm.c
> @@ -135,6 +135,40 @@ int kvm_arch_get_registers(CPUS390XState *env)
> return 0;
> }
>
> +/*
> + * Legacy layout for s390:
> + * Older S390 KVM requires the topmost vma of the RAM to be
> + * smaller than an system defined value, which is at least 256GB.
> + * Larger systems have larger values. We put the guest between
> + * the end of data segment (system break) and this value. We
> + * use 32GB as a base to have enough room for the system break
> + * to grow. We also have to use MAP parameters that avoid
> + * read-only mapping of guest pages.
> + */
> +static void *legacy_s390_alloc(ram_addr_t size)
> +{
> + void *mem;
> +
> + mem = mmap((void *) 0x800000000ULL, size,
> + PROT_EXEC|PROT_READ|PROT_WRITE,
> + MAP_SHARED | MAP_ANONYMOUS | MAP_FIXED, -1, 0);
> + if (mem == MAP_FAILED) {
> + fprintf(stderr, "Allocating RAM failed\n");
> + abort();
> + }
> + return mem;
> +}
> +
> +void *kvm_arch_alloc(ram_addr_t size)
> +{
> + if (kvm_check_extension(kvm_state, KVM_CAP_S390_GMAP)&&
> + kvm_check_extension(kvm_state, KVM_CAP_S390_COW)) {
> + return qemu_vmalloc(size);
> + } else {
> + return legacy_s390_alloc(size);
> + }
> +}
> +
> int kvm_arch_insert_sw_breakpoint(CPUS390XState *env, struct kvm_sw_breakpoint *bp)
> {
> static const uint8_t diag_501[] = {0x83, 0x24, 0x05, 0x01};
>
next prev parent reply other threads:[~2012-06-12 11:58 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-06 12:05 [Qemu-devel] [PATCH 0/8] s390: SCLP console and misc Jens Freimann
2012-06-06 12:05 ` [Qemu-devel] [PATCH 1/8] s390: add new define for KVM_CAP_S390_COW Jens Freimann
2012-06-06 12:05 ` [Qemu-devel] [PATCH 2/8] s390: autodetect map private Jens Freimann
2012-06-12 9:32 ` Alexander Graf
2012-06-12 11:20 ` Christian Borntraeger
2012-06-12 11:57 ` Alexander Graf [this message]
2012-06-12 12:02 ` Christian Borntraeger
2012-06-12 12:12 ` Alexander Graf
2012-06-13 10:30 ` Jan Kiszka
2012-06-13 10:54 ` Alexander Graf
2012-06-13 10:58 ` Jan Kiszka
2012-06-13 11:27 ` Christian Borntraeger
2012-06-13 11:41 ` Jan Kiszka
2012-06-13 12:33 ` Alexander Graf
2012-06-13 12:35 ` Jan Kiszka
2012-06-15 14:01 ` [Qemu-devel] Next version of memory allocation fixup Christian Borntraeger
2012-06-15 14:01 ` [Qemu-devel] [PatchV2] s390: autodetect map private Christian Borntraeger
2012-06-15 15:10 ` [Qemu-devel] One more fix Christian Borntraeger
2012-06-15 15:10 ` [Qemu-devel] [PATCH v3] s390: autodetect map private Christian Borntraeger
2012-06-15 17:01 ` Jan Kiszka
2012-06-18 13:44 ` Alexander Graf
2012-06-06 12:05 ` [Qemu-devel] [PATCH 3/8] s390: make kvm_stat work on s390 Jens Freimann
2012-06-06 12:05 ` [Qemu-devel] [PATCH 4/8] s390: stop target cpu on sigp initial reset Jens Freimann
2012-06-12 9:42 ` Alexander Graf
2012-06-12 10:15 ` Christian Borntraeger
2012-06-06 12:05 ` [Qemu-devel] [PATCH 5/8] s390: Cleanup sclp functions Jens Freimann
2012-06-12 9:58 ` Alexander Graf
2012-06-12 10:07 ` Christian Borntraeger
2012-06-12 10:09 ` Alexander Graf
2012-06-12 10:10 ` Alexander Graf
2012-06-12 12:24 ` Christian Borntraeger
2012-06-12 12:32 ` Alexander Graf
2012-06-12 22:41 ` Anthony Liguori
2012-06-12 22:38 ` Anthony Liguori
2012-06-06 12:05 ` [Qemu-devel] [PATCH 6/8] s390: sclp event facility and signal quiesce support via system_powerdown Jens Freimann
2012-06-12 11:38 ` Alexander Graf
2012-06-13 7:00 ` Heinz Graalfs
2012-06-13 13:12 ` Andreas Färber
2012-06-06 12:05 ` [Qemu-devel] [PATCH 7/8] s390: Add SCLP vt220 console support Jens Freimann
2012-06-12 11:52 ` Alexander Graf
2012-06-13 7:27 ` Heinz Graalfs
2012-06-13 7:53 ` Alexander Graf
2012-06-06 12:05 ` [Qemu-devel] [PATCH 8/8] s390: Fix the storage increment size calculation Jens Freimann
2012-06-12 11:53 ` Alexander Graf
2012-06-12 14:57 ` Jeng-fang Wang
2012-06-18 13:46 ` Alexander Graf
2012-06-18 19:30 ` Christian Borntraeger
2012-06-18 12:35 ` [Qemu-devel] [PATCH 0/8] s390: SCLP console and misc Christian Borntraeger
2012-06-18 13:33 ` Alexander Graf
2012-06-18 13:41 ` Christian Borntraeger
2012-06-18 13:51 ` Alexander Graf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FD72EC2.2010105@suse.de \
--to=agraf@suse.de \
--cc=borntraeger@de.ibm.com \
--cc=cornelia.huck@de.ibm.com \
--cc=graalfs@linux.vnet.ibm.com \
--cc=jfrei@de.ibm.com \
--cc=jfrei@linux.vnet.ibm.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.