qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCHv2 6/6] dump: fix memory region handling


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCHv2 6/6] dump: fix memory region handling
Date: Sun, 24 Mar 2013 20:18:34 +0000

On 24 March 2013 19:35, Rabin Vincent <address@hidden> wrote:
> 2013/3/24 Peter Maydell <address@hidden>:
>> On 24 March 2013 17:27, Rabin Vincent <address@hidden> wrote:
>>>  /**
>>> + * memory_region_get_addr: Get the address of a memory region
>>> + *
>>> + * @mr: the memory region
>>> + */
>>> +hwaddr memory_region_get_addr(MemoryRegion *mr);
>>
>> I'm afraid this doesn't make sense. A MemoryRegion by itself has
>> no "address" -- it could be mapped into several places in several
>> different address maps or none at all.
>
> OK.  Do you mean that such a function can be used internally to the dump
> code where it gets the MemoryRegion only from the RAMBlock.mr or do you
> mean the dump code also shouldn't be doing it that way?

I mean that the dump code is wrong if it's trying to ask "what
is the address of this MemoryRegion (or RAMBlock)" at all. That
question doesn't have a well defined single answer.

> If you mean the latter, could you please suggest an alternative way to
> handle this?  The problem is that the dump code assumes that
> RAMBlock.offset provides the physical address, and this appears to not
> be the case.

That is also wrong, both for the reason you state and also because
ramblocks can be aliased into multiple physical addresses too.
I suspect you need to change anything that's trying to iterate
through memory with "for each block in ram_list" to instead actually
iterate through the system address space and say "if this is RAM
then...". For instance with the vexpress-a9 you presumably want
a LOAD section for both physaddr 0 (the alias) and physaddr
0x60000000 (the usual address).

-- PMM



reply via email to

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