[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
Re: [Qemu-devel] [PATCHv2 0/6] ARM dump-guest-memory support, Andreas Färber, 2013/03/25