Re: [Qemu-devel] [PATCH 1/9] Export function for VA defined ram allocation

[Alexander Graf]

On 21.10.2009, at 16:29, Anthony Liguori wrote:

> Alexander Graf wrote:
> > S390 requires vmas for guests to be < 256 GB. So we need to  
> > directly export
> > mmaps "try to use this vma as start address" feature to not  
> > accidently get
> > over that limit.
> >
> > Signed-off-by: Alexander Graf <address@hidden>
> > ---
> > cpu-common.h |    1 +
> > exec.c       |   15 +++++++++++++--
> > 2 files changed, 14 insertions(+), 2 deletions(-)
> >
> > diff --git a/cpu-common.h b/cpu-common.h
> > index 6302372..ecaf9e3 100644
> > --- a/cpu-common.h
> > +++ b/cpu-common.h
> > @@ -30,6 +30,7 @@ static inline void cpu_register_physical_memory 
> > (target_phys_addr_t start_addr,
> >  ram_addr_t cpu_get_physical_page_desc(target_phys_addr_t addr);
> > ram_addr_t qemu_ram_alloc(ram_addr_t);
> > +ram_addr_t _qemu_ram_alloc(ram_addr_t size, void *map_at);
>
> I don't like this interface very much.  Couldn't the fact that we  
> need a va starting at 0 for s390 kvm be hidden behind the existing  
> qemu_ram_alloc?

We don't need a va starting at 0. We need a max va ending < 256 GB.

Carsten did mention in a previous mail that he has getting rid of that  
limitation on his todo list, but for now that's what we have. As soon  
as the kvm module is updated to support arbitrary addresses we can  
just revert this patch and be happy.

For the time being all we need to check is that nobody else uses  
_qemu_ram_alloc, so we really can revert it safely then.

Alex