From: Paolo Bonzini <pbonzini@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: QEMU Developers <qemu-devel@nongnu.org>,
hangaohuai@huawei.com, peter.huangpeng@huawei.com,
zhuyijun <zhuyijun@huawei.com>
Subject: Re: [Qemu-devel] [PATCH] hw/arm/virt: Replace memory_region_init_ram with memory_region_allocate_system_memory
Date: Tue, 14 Oct 2014 14:39:41 +0200 [thread overview]
Message-ID: <543D198D.7060203@redhat.com> (raw)
In-Reply-To: <CAFEAcA_9LJZa=HsU88hM8tAwk3mGSChf+ZskGqq1=53szOYy7A@mail.gmail.com>
Il 14/10/2014 07:42, Peter Maydell ha scritto:
> On 14 October 2014 07:10, Paolo Bonzini <pbonzini@redhat.com> 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...
Yes.
>>> 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 :-)
The non-NUMA path will allocate memory from two separate files.
-mem-path takes a path, not a file.
> What's the right thing for a board where the system
> RAM isn't contiguous, by the way?
x86 allocates a big RAM region and uses aliases to split it into
non-contiguous areas.
Paolo
next prev parent reply other threads:[~2014-10-14 12:40 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-14 2:36 [Qemu-devel] [PATCH] hw/arm/virt: Replace memory_region_init_ram with memory_region_allocate_system_memory zhuyijun
2014-10-14 4:54 ` Peter Maydell
2014-10-14 5:10 ` Paolo Bonzini
2014-10-14 5:42 ` Peter Maydell
2014-10-14 12:39 ` Paolo Bonzini [this message]
2014-10-14 12:48 ` Peter Maydell
2014-10-17 12:05 ` Paolo Bonzini
2014-10-14 6:04 ` Yijun Zhu
2014-10-14 12:40 ` Paolo Bonzini
2014-10-15 0:40 ` Yijun Zhu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=543D198D.7060203@redhat.com \
--to=pbonzini@redhat.com \
--cc=hangaohuai@huawei.com \
--cc=peter.huangpeng@huawei.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=zhuyijun@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.