From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MRoGP-0005CB-Nn for qemu-devel@nongnu.org; Fri, 17 Jul 2009 10:18:17 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MRoGL-00054e-Si for qemu-devel@nongnu.org; Fri, 17 Jul 2009 10:18:17 -0400 Received: from [199.232.76.173] (port=49161 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MRoGL-00054U-CA for qemu-devel@nongnu.org; Fri, 17 Jul 2009 10:18:13 -0400 Received: from lizzard.sbs.de ([194.138.37.39]:19438) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MRoGK-0003JP-QG for qemu-devel@nongnu.org; Fri, 17 Jul 2009 10:18:13 -0400 Message-ID: <4A608822.5020901@siemens.com> Date: Fri, 17 Jul 2009 16:18:10 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1247831508-19023-1-git-send-email-agraf@suse.de> <1247831508-19023-2-git-send-email-agraf@suse.de> <1247831508-19023-3-git-send-email-agraf@suse.de> <1247831508-19023-4-git-send-email-agraf@suse.de> <1247831508-19023-5-git-send-email-agraf@suse.de> <1247831508-19023-6-git-send-email-agraf@suse.de> <1247831508-19023-7-git-send-email-agraf@suse.de> <4A60811A.4040508@siemens.com> <45DEB839-8E65-4F44-A318-DC3E88B7889A@suse.de> In-Reply-To: <45DEB839-8E65-4F44-A318-DC3E88B7889A@suse.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 6/7] Set slots more carefully List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: qemu-devel@nongnu.org, hollisb@us.ibm.com Alexander Graf wrote: > > On 17.07.2009, at 15:48, Jan Kiszka wrote: > >> Alexander Graf wrote: >>> KVM only supports slot sizes of PAGE_SIZE granilarity. On PPC the OS >>> sets the framebuffer to some odd size though, causing the current code >>> to simply abort(). >>> >>> So let's bet graceful here. We can just allocate memory sizes that >>> are of >>> PAGE_SIZE granularity and everything that exceeds that comes in as >>> MMIO and >>> gets handled too - just slower. >>> >>> Signed-off-by: Alexander Graf >>> --- >>> kvm-all.c | 2 +- >>> 1 files changed, 1 insertions(+), 1 deletions(-) >>> >>> diff --git a/kvm-all.c b/kvm-all.c >>> index 961fa32..60b76cf 100644 >>> --- a/kvm-all.c >>> +++ b/kvm-all.c >>> @@ -134,7 +134,7 @@ static int kvm_set_user_memory_region(KVMState >>> *s, KVMSlot *slot) >>> >>> mem.slot = slot->slot; >>> mem.guest_phys_addr = slot->start_addr; >>> - mem.memory_size = slot->memory_size; >>> + mem.memory_size = slot->memory_size & ~(TARGET_PAGE_SIZE - 1); >> >> TARGET_PAGE_MASK? And I bet you want to round up here... > > > Eh - yeah. Same thing, no? Just look at its definition... > > And no, I don't want to round up. After the memory backed slot could > easily be real MMIO space. I had such strange configurations with the > ESCC overlapping in the same page as graphic memory once. Overlapping is handled by the kvm layer in user space. For sure, if there is a mapping conflict, we are in trouble (kvm-wise) as the second request overwrites the mapping type of the overlapping page(s). > > Better be safe than sorry. No, something wrong. If you cut off the odd "overhead", you effectively exclude that page. So either the caller should not include it in the first place as it is unused or kvm should try to map the whole page just like the rest of the slot. If there remains an unresolvable conflict, we need to enhance the slot management with some sub-page dispatching mechanism. > >> Does the caller use the odd size consistently (i.e. also for dirty log >> enable/disable)? Otherwise we may run into troubles while looking up >> that slot as it will be registered in user space via its odd end >> address. Not sure yet, but maybe it's better to round up at the call >> sites of kvm_set_user_memory_region. > > Well if the destroyer does not call with the same region it's totally > broken, no? Yes, but I was more concerned about consistency between registration and (potentially partial) logging updates. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux