[Top][All Lists]

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

Re: [Qemu-devel] [PATCH 0/3] Fix memory migration for exynos 4210 SoC

From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 0/3] Fix memory migration for exynos 4210 SoC
Date: Tue, 07 May 2013 15:14:03 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4

Il 07/05/2013 15:09, Peter Maydell ha scritto:
> On 10 March 2013 14:21, Igor Mitsyanko <address@hidden> 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.


> We should probably still look at fixing the bugs with small
> ramblocks and/or asserting if you try to create them, though.
> thanks
> -- PMM

reply via email to

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