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

[Peter Maydell]

On 10 November 2011 01:45, Alexander Graf <address@hidden> wrote:
> On 10.11.2011, at 02:36, Peter Maydell wrote:
>> This looks a bit fishy -- cpu_physical_memory_map() takes a
>> target_phys_addr_t but you're passing it a ram_addr_t.
>
> Meh. Always those types ... :)

In the simple case ("ram starts at 0, not multiply mapped, guest
and host pointer widths the same") target_phys_addr_t's and
ram_addr_t's are the same, but this isn't necessarily so; indeed
one ram_addr_t can be mapped to multiple target_phys_addr_t's
in some system models. So the two things aren't trivially
interconvertible. (As it happens I think in this case you're
actually just doing physical address calculations using the wrong
type...)

> On 10.11.2011, at 02:36, Peter Maydell wrote:
>> Also isn't this second-guessing the ram_addr_t of the region allocated
>> inside memory_region_init_ram() ?
>
> Not sure I understand? On s390-virtio we have to following ram layout:
>
> [ ----- RAM ---- | --- virtio device structs --- ]
>
> The size of the latter is added to my_ram_size by
> s390_virtio_bus_init. All I'm trying to do is make sure that this
> latter part of RAM is always 0, while the first part can still be
> dynamically allocated.

That comment was written on the assumption that you were actually
trying to manipulate a ram_addr_t in your variable of type
ram_addr_t; to expand on it a bit:

I think that conceptually the only way to get the ram_addr_t for a
bit of RAM should be that you got it back from qemu_ram_alloc()
(or that you did the obvious arithmetic to get a ram_addr_t within
a block given the start of one). As it happens qemu_ram_alloc()
starts ram_addr_t's at 0 and works up with no gaps, but that's
an implementation detail. (Also if anybody ever did something that
meant there was another qemu_ram_alloc() call before the one done
inside that memory_region_init_ram() then things would break.)

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().

-- PMM