On 08/19/13 19:48, Michael S. Tsirkin wrote:
> On Mon, Aug 19, 2013 at 07:37:44PM +0200, Laszlo Ersek wrote:
>> On 08/19/13 16:26, Michael S. Tsirkin wrote:
>>> Migration code assumes that each MR is a multiple of TARGET_PAGE_SIZE:
>>> MR size is divided by TARGET_PAGE_SIZE, so if it isn't migratio
On Mon, Aug 19, 2013 at 06:45:10PM +0100, Peter Maydell wrote:
> On 19 August 2013 18:37, Laszlo Ersek wrote:
> > ((3) memory_region_size() is slightly different from
> > int128_get64(mr->size); it has a special case for int128_2_64() -- and I
> > don't understand that.
>
> The special case is be
On Mon, Aug 19, 2013 at 07:37:44PM +0200, Laszlo Ersek wrote:
> On 08/19/13 16:26, Michael S. Tsirkin wrote:
> > Migration code assumes that each MR is a multiple of TARGET_PAGE_SIZE:
> > MR size is divided by TARGET_PAGE_SIZE, so if it isn't migration
> > never completes.
> > But this isn't really
On 19 August 2013 18:37, Laszlo Ersek wrote:
> ((3) memory_region_size() is slightly different from
> int128_get64(mr->size); it has a special case for int128_2_64() -- and I
> don't understand that.
The special case is because valid memory region sizes range
from 0 to 2^64, *inclusive*. [2^64-si
On 08/19/13 16:26, Michael S. Tsirkin wrote:
> Migration code assumes that each MR is a multiple of TARGET_PAGE_SIZE:
> MR size is divided by TARGET_PAGE_SIZE, so if it isn't migration
> never completes.
> But this isn't really required for regions set up with
> memory_region_init_ram, since that c
Migration code assumes that each MR is a multiple of TARGET_PAGE_SIZE:
MR size is divided by TARGET_PAGE_SIZE, so if it isn't migration
never completes.
But this isn't really required for regions set up with
memory_region_init_ram, since that calls qemu_ram_alloc
which aligns size up using TARGET_P
