[Qemu-devel] Re: [PATCH 6/7] Set slots more carefully

[Alexander Graf]

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 <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