From: Paolo Bonzini <pbonzini@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Igor Mitsyanko <i.mitsyanko@gmail.com>,
qemu-devel@nongnu.org, anthony@codemonkey.ws, afaerber@suse.de
Subject: Re: [Qemu-devel] [PATCH 0/3] Fix memory migration for exynos 4210 SoC
Date: Tue, 07 May 2013 15:14:03 +0200 [thread overview]
Message-ID: <5188FE1B.3070809@redhat.com> (raw)
In-Reply-To: <CAFEAcA8s8KrcxdJX6iq1pfmZ3=NjwDk4m=87YkDN6=abbjOLbw@mail.gmail.com>
Il 07/05/2013 15:09, Peter Maydell ha scritto:
> On 10 March 2013 14:21, Igor Mitsyanko <i.mitsyanko@gmail.com> wrote:
>> First two patches fix issues in exynos4210 code which were blocking proper memory
>> migration.
>>
>> Third patch makes memory_region_init_ram_ptr assert if memory region size is not a
>> multiple of TARGET_PAGE_SIZE.
>>
>> Igor Mitsyanko (3):
>> hw/exynos4210.c: set chipid_and_omr array size to TARGET_PAGE_SIZE
>> exynos4210.c: register chipid_mem and rom_mem with vmstate
>> memory.c: only allow memory sizes which are a multiple of target page
>> size
>
> I was talking to Paolo about this patchset on IRC, and we came to
> the conclusion that for the chipid_and_omr bit the right solution
> is not to misuse memory_region_init_ram_ptr() for this, but just
> to implement it as a device with an mmio region.
... or at least, just use memory_region_init_ram() and copy the initial
contents to it with address_space_rw. There are probably some bugs in
small memory_region_init_ram regions too, but some problems you're
seeing are exclusive to memory_region_init_ram_ptr, and the others are
more easily fixed if you concentrate on memory_region_init_ram.
I think memory_region_init_ram_ptr should assert that the size is a
multiple of the page size. It is a special interface that is meant to
be used for things like mmap-ed files (not coincidentially, pci-assign
and VFIO are the main users). Besides exynos4210, hw/display/g364fb.c
would also be better off using address_space_map/unmap.
Paolo
> We should probably still look at fixing the bugs with small
> ramblocks and/or asserting if you try to create them, though.
>
> thanks
> -- PMM
>
prev parent reply other threads:[~2013-05-07 13:14 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-10 14:21 [Qemu-devel] [PATCH 0/3] Fix memory migration for exynos 4210 SoC Igor Mitsyanko
2013-03-10 14:21 ` [Qemu-devel] [PATCH 1/3] hw/exynos4210.c: set chipid_and_omr array size to TARGET_PAGE_SIZE Igor Mitsyanko
2013-03-10 14:21 ` [Qemu-devel] [PATCH 2/3] exynos4210.c: register chipid_mem and rom_mem with vmstate Igor Mitsyanko
2013-03-10 14:21 ` [Qemu-devel] [PATCH 3/3] memory_region_init_ram_ptr: only allow n*TARGET_PAGE_SIZE memory sizes Igor Mitsyanko
2013-03-10 14:27 ` Peter Maydell
2013-03-10 18:39 ` Igor Mitsyanko
2013-05-07 13:09 ` [Qemu-devel] [PATCH 0/3] Fix memory migration for exynos 4210 SoC Peter Maydell
2013-05-07 13:14 ` Paolo Bonzini [this message]
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=5188FE1B.3070809@redhat.com \
--to=pbonzini@redhat.com \
--cc=afaerber@suse.de \
--cc=anthony@codemonkey.ws \
--cc=i.mitsyanko@gmail.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).