[Top][All Lists]

[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: Christian Borntraeger
Subject: Re: [Qemu-devel] [PATCH 12/15] s390x: reduce TARGET_PHYS_ADDR_SPACE_BITS to 62
Date: Sun, 26 May 2013 23:08:16 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6

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.


reply via email to

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