From: Markus Armbruster <armbru@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: borntraeger@de.ibm.com, mtosatti@redhat.com,
qemu-devel@nongnu.org, stefano.stabellini@eu.citrix.com,
agraf@suse.de
Subject: Re: [Qemu-devel] [PATCH RFC 6/8] exec: Clean up unnecessary S390 ifdeffery
Date: Fri, 14 Jun 2013 10:06:11 +0200 [thread overview]
Message-ID: <87bo795d70.fsf@blackfin.pond.sub.org> (raw)
In-Reply-To: <51BA45E1.4030500@redhat.com> (Paolo Bonzini's message of "Thu, 13 Jun 2013 18:21:21 -0400")
Paolo Bonzini <pbonzini@redhat.com> writes:
> Il 13/06/2013 03:02, Markus Armbruster ha scritto:
>> + } else if (kvm_enabled() && kvm_arch_ram_alloc) {
>> + /* some s390/kvm configurations have special constraints */
>> + if (mem_path) {
>> + fprintf(stderr,
>> + "-mem-path not supported with this version of KVM\n");
>> + exit(1);
>> + }
>> + new_block->host = kvm_arch_ram_alloc(size);
>> + memory_try_enable_merging(new_block->host, size);
>
> Uh oh, now I see why you wanted the hook as a function pointer. Can you
> instead pass the file descriptor to kvm_ram_alloc?
I'm not sure I understand what you're suggesting. Here's my best guess.
I made kvm_arch_ram_alloc() an *optional* hook, implemented as function
pointer that may be null. It's actually non-null only with old S390
KVM.
Non-null value also suppresses -mem-path. Admittedly not the cleanest
possible solution, but (1) it's better than what we have now, and (2)
the whole thing should go away forever once we stop supporting old S390
kernels.
You seem to suggest to factor the actual allocation of guest memory out
of this part of qemu_ram_alloc_from_ptr():
if (host) {
new_block->host = host;
new_block->flags |= RAM_PREALLOC_MASK;
} else if (xen_enabled()) {
if (mem_path) {
fprintf(stderr, "-mem-path not supported with Xen\n");
exit(1);
}
xen_ram_alloc(new_block->offset, size, mr);
} else if (kvm_enabled() && kvm_arch_ram_alloc) {
/* some s390/kvm configurations have special constraints */
if (mem_path) {
fprintf(stderr,
"-mem-path not supported with this version of KVM\n");
exit(1);
}
new_block->host = kvm_arch_ram_alloc(size);
if (!new_block->host) {
no_guest_mem(new_block);
}
memory_try_enable_merging(new_block->host, size);
} else {
if (mem_path) {
new_block->host = file_ram_alloc(new_block, size, mem_path);
}
if (!new_block->host) {
new_block->host = qemu_anon_ram_alloc(size);
if (!new_block->host) {
no_guest_mem(new_block);
}
memory_try_enable_merging(new_block->host, size);
}
}
Three functions, one each for Xen, S390 KVM, and generic. Except the
one for Xen has only one caller, so we better leave that one alone.
Put a trivial wrapper around generic into each target-*/kvm.c other than
s390: arm, i386, ppc.
qemu_ram_alloc_from_ptr() then looks roughly like this:
if (host) {
new_block->host = host;
new_block->flags |= RAM_PREALLOC_MASK;
} else if (xen_enabled()) {
if (mem_path) {
fprintf(stderr, "-mem-path not supported with Xen\n");
exit(1);
}
xen_ram_alloc(new_block->offset, size, mr);
} else if (kvm_enabled()) {
new->block->host = kvm_arch_ram_alloc(size, new_block->fd);
if (!new_block->host) {
no_guest_mem(new_block);
}
} else {
new_block->host = qemu_guest_mem_alloc(size, new_block->fd);
if (!new_block->host) {
no_guest_mem(new_block);
}
}
Except new_block->fd still needs to be set. Need to split
file_ram_alloc() into two: first part yields the file descriptor, to be
called by qemu_ram_alloc_from_ptr(), second part does the actual
allocation, to be called by the allocation functions. The code in
qemu_ram_alloc_from_ptr() becomes:
if (host) {
new_block->host = host;
new_block->flags |= RAM_PREALLOC_MASK;
} else if (xen_enabled()) {
if (mem_path) {
fprintf(stderr, "-mem-path not supported with Xen\n");
exit(1);
}
xen_ram_alloc(new_block->offset, size, mr);
} else {
new->block->fd = file_ram_fd(mem_path);
new->block->host = kvm_enabled()
? kvm_arch_ram_alloc(size, new_block->fd);
: qemu_guest_mem_alloc(size, new_block->fd);
if (!new_block->host) {
no_guest_mem(new_block);
}
}
Is that what you have in mind?
It's a lot of restructuring and notational overhead just for this stupid
hack to support old S390 kernels.
Here's another way to keep the KVM hooks regular: make my function
pointers exec.c hooks instead of KVM hooks ;-P
next prev parent reply other threads:[~2013-06-14 8:06 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-13 7:02 [Qemu-devel] [PATCH RFC 0/8] Guest memory allocation fixes & cleanup Markus Armbruster
2013-06-13 7:02 ` [Qemu-devel] [PATCH RFC 1/8] exec: Fix Xen RAM allocation with unusual options Markus Armbruster
2013-06-13 11:54 ` Stefano Stabellini
2013-06-13 7:02 ` [Qemu-devel] [PATCH RFC 2/8] exec: Clean up fall back when -mem-path allocation fails Markus Armbruster
2013-06-13 22:12 ` Paolo Bonzini
2013-06-13 7:02 ` [Qemu-devel] [PATCH RFC 3/8] exec: Reduce ifdeffery around -mem-path Markus Armbruster
2013-06-13 7:02 ` [Qemu-devel] [PATCH RFC 4/8] s390: Simplify the RAM allocation hook Markus Armbruster
2013-06-13 8:19 ` Andreas Färber
2013-06-13 22:14 ` Paolo Bonzini
2013-06-13 7:02 ` [Qemu-devel] [PATCH RFC 5/8] s390: Make qemu_ram_remap() consistent with allocation Markus Armbruster
2013-06-13 22:19 ` Paolo Bonzini
2013-06-13 7:02 ` [Qemu-devel] [PATCH RFC 6/8] exec: Clean up unnecessary S390 ifdeffery Markus Armbruster
2013-06-13 22:21 ` Paolo Bonzini
2013-06-14 8:06 ` Markus Armbruster [this message]
2013-06-15 17:26 ` Paolo Bonzini
2013-06-13 7:02 ` [Qemu-devel] [PATCH RFC 7/8] exec: Don't abort when we can't allocate guest memory Markus Armbruster
2013-06-13 8:33 ` Andreas Färber
2013-06-13 16:02 ` Richard Henderson
2013-06-13 17:27 ` Markus Armbruster
2013-06-13 16:21 ` Peter Maydell
2013-06-13 17:27 ` Markus Armbruster
2013-06-13 7:02 ` [Qemu-devel] [PATCH RFC 8/8] pc_sysfw: Fix ISA BIOS init for ridiculously big flash Markus Armbruster
2013-06-13 7:05 ` [Qemu-devel] [PATCH RFC 0/8] Guest memory allocation fixes & cleanup Markus Armbruster
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=87bo795d70.fsf@blackfin.pond.sub.org \
--to=armbru@redhat.com \
--cc=agraf@suse.de \
--cc=borntraeger@de.ibm.com \
--cc=mtosatti@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefano.stabellini@eu.citrix.com \
/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.