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

[Anthony Liguori <anthony@codemonkey.ws>]

Alexander Graf wrote:
>
> 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 <agraf@suse.de>
>>> ---
>>> 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.

Couldn't we just as easily put the check in qemu_ram_alloc under a 
TARGET_S390 && kvm_enabled()?

That's far better than introducing a function who's only name difference 
is an underscore.

Regards,

Anthony Liguori
> Alex