qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 12/15] s390x: reduce TARGET_PHYS_ADDR_SPACE_BITS


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 12/15] s390x: reduce TARGET_PHYS_ADDR_SPACE_BITS to 62
Date: Mon, 27 May 2013 09:28:04 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6

Il 26/05/2013 23:08, Christian Borntraeger ha scritto:
> On 26/05/13 21:07, Paolo Bonzini wrote:
>> Il 26/05/2013 16:14, Andreas Färber ha scritto:
>>>> With the next patch, the memory API will complain if the
>>>> TARGET_PHYS_ADDR_SPACE_BITS gets dangerously close to an
>>>> overflow.  s390x can handle up to 64 bit of physical address
>>>> space from its page tables, but we never use that much.  Just
>>>> decrease the value.
>>>>
>>>> Cc: Alexander Graf <address@hidden>
>>>> Signed-off-by: Paolo Bonzini <address@hidden>
>>>
>>> Didn't Avi introduce 128-bit arithmetic into QEMU to avoid 64-bit values
>>> overflowing? Why are you limiting Memory API to 62-bit now?
>>
>> The next patch makes a difference between artificial memory regions
>> (containers and aliases) which can have arbitrary placement and width,
>> and the final view of the address space which cannot have a full 64-bit
>> size.
>>
>> 63 bits probably would work, but I preferred to be safe since 62 is the
>> largest used by other targets.
>>
>> It should be fixable, but if it is not a problem I wouldn't worry much
>> about it.
> 
> I would prefer to allow 64bit of address space. Memory on s390x can be 
> discontiguous. It is currently not used under KVM and it might not make
> a lot of sense, but the current KVM code  would allow a guest that has a 
> layout of lets say 0...1GB + 16EB-1GB...16EB. 
> 
> Furthermore, I know of some (prototype only) hw memory devices that actually
> populated the upper memory addresses. If such a thing becomes reality in the
> future we cannot provide virtualization of those.

Ok, I'll drop this patch and the next one from the pull request.

Paolo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]