qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] hw/arm/virt: Replace memory_region_init_ram wit


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH] hw/arm/virt: Replace memory_region_init_ram with memory_region_allocate_system_memory
Date: Tue, 14 Oct 2014 07:42:11 +0200

On 14 October 2014 07:10, Paolo Bonzini <address@hidden> wrote:
> Il 14/10/2014 06:54, Peter Maydell ha scritto:
>> Why is this patch only changing this board? What's special
>> about virt that means we don't want to also make this
>> change for the other ARM boards? What about all the other
>> boards for the other architectures?
>
> -mem-path is not too useful without KVM (TCG is too slow to
> notice the difference.  PPC and S390 have already been fixed.

MIPS has KVM too now...

> For other boards, I have patches but I had no time to submit
> them until now.
>
>> The commit message for 0b183fc871 suggests we decided to
>> just break -mem-path for all those boards, which seems an
>> odd thing to do... Paolo?
>
> The plan _was_ in fact to fix it up. :(
>
>> Incidentally I can't see anything that guards against
>> calling memory_region_allocate_system_memory() twice,
>> so I think you would end up with two blocks of RAM
>> both backed by the same file then. Or have I misread
>> the code?
>
> That would be a bug in the board, it is caught here:
>
>         if (memory_region_is_mapped(seg)) {
>             char *path = object_get_canonical_path_component(OBJECT(backend));
>             error_report("memory backend %s is used multiple times. Each "
>                          "-numa option must use a different memdev value.",
>                          path);
>             exit(1);
>         }
>
> The error message gives the common user error rather than
> the less common developer error, but still you catch it.

That's only in the NUMA code path though, isn't it?
I was looking at the non-numa codepath, which is what
all the boards I care about are going to be taking :-)

What's the right thing for a board where the system
RAM isn't contiguous, by the way?

thanks
-- PMM



reply via email to

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