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 <ag...@suse.de> >>> Signed-off-by: Paolo Bonzini <pbonz...@redhat.com> >> >> 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. Christian
