|
From: | Alexander Graf |
Subject: | [Qemu-devel] Re: [PATCH 6/7] Set slots more carefully |
Date: | Fri, 17 Jul 2009 15:53:39 +0200 |
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 OSsets the framebuffer to some odd size though, causing the current codeto 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 andgets handled too - just slower. Signed-off-by: Alexander Graf <address@hidden> --- 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?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.
Better be safe than sorry.
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?
Alex
[Prev in Thread] | Current Thread | [Next in Thread] |