On 01.06.2012, at 00:24, Scott Wood wrote: > On 05/31/2012 05:18 PM, Alexander Graf wrote: >> >> On 01.06.2012, at 00:07, Scott Wood wrote: >> >>> On 05/30/2012 06:00 AM, Alexander Graf wrote: >>>> We're passing the ram size as uint32_t, capping it to 32 bits atm. >>>> Change to target_phys_addr_t (uint64_t) to make sure we have all >>>> the bits. >>> >>> Wouldn't ram_addr_t be more appropriate? >> >> I never quite grasped the difference, but wasn't ram_addr_t something for >> the host? > > I don't fully understand QEMU's RAM handling, but from what I recall RAM > is treated differently from arbitrary guest physical addresses, with a > QEMU-internal contiguous address space. Guest RAM needs to be mappable > by QEMU as well as the target, so ram_addr_t is 32-bit on a 32-bit host, > even if target_phys_addr_t is different. > > But again, it was a while ago that I looked at this, and I didn't fully > understand it then, so I may be missing or misremembering something.
Right, so target_phys_addr_t is what we want, because that's what describes the guest's physical memory layout the best, which is what we're describing here, right? It should definitely be independent of the host's virtual memory layout. Alex
