qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] s390x: initialize virtio dev region


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH] s390x: initialize virtio dev region
Date: Fri, 11 Nov 2011 16:11:56 +0000

On 11 November 2011 15:59, Alexander Graf <address@hidden> wrote:
> This is the machine init function. The s390 virtio machine's ram layout is
> defined to be exactly as I posted in the previous post. So there won't be
> any ram starts at != 0 or multiple mappings :).

That's the layout of the RAM in target_phys_addr_t space.
The layout of the ram in ram_addr_t space is not guaranteed
to be the same, it just happens to be in this case.

>>> On 10.11.2011, at 02:36, Peter Maydell wrote:
>> In summary, either:
>> (1) you need to ask the memory region for its ram_addr_t
>> [there doesn't seem to be an API for this at the moment],
>> do arithmetic on ram_addr_t's and use qemu_get_ram_ptr() to
>> get a host pointer corresponding to that ram_addr_t
>> or (2) you need to do your arithmetic in target_phys_addr_t's
>> (and then you can say your RAM starts at physaddr 0, which
>> is guaranteed, rather than at ram_addr_t 0, which isn't)
>> and use cpu_physical_memory_map/unmap().
>
> I still don't get it. What I want is:
>
>  for (i = ram_size; i < my_ram_size; i++)
>    stb_phys(env, i, 0);
>
> cpu_physical_memory_map gives me a pointer to the memory region between
> ram_size and my_ram_size. I memset(0) it. I don't see how I could possibly
> have different offsets anywhere. If cpu_physical_memory_map would take
> anything different than physical address, a lot of assumptions in QEMU code
> would break.

Yes, so that's option (2) and you need to be using a target_phys_addr_t.

-- PMM



reply via email to

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