On 19/01/2016 04:17, Li, Liang Z wrote:
> > Paolo is right, for VM in destination, QEMU may write VM's memory before
> > VM starts.
> > So your assumption that "VM's RAM pages are initialized to zero" is
> > incorrect.
> > This patch will break LM.
>
> Which portion of the VM's RAM pages will
This patch will break LM.
> >
> > Which portion of the VM's RAM pages will be written by QEMU? Do you
> know some exact information?
> > I can't wait for Paolo's response.
>
> It is basically anything that uses rom_add_file_fixed or rom_add_blob_fixed
> with an address that points into RAM.
>
>
On 2016/1/16 2:57, Dr. David Alan Gilbert wrote:
* Liang Li (liang.z...@intel.com) wrote:
Now that VM's RAM pages are initialized to zero, (VM's RAM is allcated
with the mmap() and MAP_ANONYMOUS option, or mmap() without MAP_SHARED
if hugetlbfs is used.) so there is no need to send the zero
Hi,
On 2016/1/15 18:24, Li, Liang Z wrote:
It seems that this patch is incorrect, if the no-zero pages are zeroed again
during !ram_bulk_stage, we didn't send the new zeroed page, there will be
an error.
If not in ram_bulk_stage, still send the header, could you explain why it's
wrong?
* Li, Liang Z (liang.z...@intel.com) wrote:
> > * Liang Li (liang.z...@intel.com) wrote:
> > > Now that VM's RAM pages are initialized to zero, (VM's RAM is allcated
> > > with the mmap() and MAP_ANONYMOUS option, or mmap() without
> > MAP_SHARED
> > > if hugetlbfs is used.) so there is no need to
> On 2016/1/15 18:24, Li, Liang Z wrote:
> >> It seems that this patch is incorrect, if the no-zero pages are
> >> zeroed again during !ram_bulk_stage, we didn't send the new zeroed
> >> page, there will be an error.
> >>
> >
> > If not in ram_bulk_stage, still send the header, could you explain
On 2016/1/19 11:11, Hailiang Zhang wrote:
On 2016/1/19 9:26, Li, Liang Z wrote:
On 2016/1/15 18:24, Li, Liang Z wrote:
It seems that this patch is incorrect, if the no-zero pages are
zeroed again during !ram_bulk_stage, we didn't send the new zeroed
page, there will be an error.
If not in
> > Not yet, I saw Dave's comment's, it will beak post copy, it's not hard to
> > fix
> this.
> > A more important thing is Paolo's comments, I don't know in which case
> this patch will break LM. Do you have any idea about this?
> > Hope that QEMU don't write data to the block 'pc.ram'.
> >
>
>
> Actually, someone has done like that before and cause a migration bug, See
> commit f1c72795af573b24a7da5eb52375c9aba8a37972, and the fixing patch is
> commit 9ef051e5536b6368a1076046ec6c4ec4ac12b5c6
> Revert "migration: do not sent zero pages in bulk stage"
Thanks for your information, I
On 2016/1/19 9:26, Li, Liang Z wrote:
On 2016/1/15 18:24, Li, Liang Z wrote:
It seems that this patch is incorrect, if the no-zero pages are
zeroed again during !ram_bulk_stage, we didn't send the new zeroed
page, there will be an error.
If not in ram_bulk_stage, still send the header, could
> On 15/01/2016 10:48, Liang Li wrote:
> > Now that VM's RAM pages are initialized to zero, (VM's RAM is allcated
> > with the mmap() and MAP_ANONYMOUS option, or mmap() without
> MAP_SHARED
> > if hugetlbfs is used.) so there is no need to send the zero page
> > header to destination.
> >
> > For
> * Liang Li (liang.z...@intel.com) wrote:
> > Now that VM's RAM pages are initialized to zero, (VM's RAM is allcated
> > with the mmap() and MAP_ANONYMOUS option, or mmap() without
> MAP_SHARED
> > if hugetlbfs is used.) so there is no need to send the zero page
> > header to destination.
> >
> >
On 2016/1/15 17:48, Liang Li wrote:
Now that VM's RAM pages are initialized to zero, (VM's RAM is allcated
with the mmap() and MAP_ANONYMOUS option, or mmap() without MAP_SHARED
if hugetlbfs is used.) so there is no need to send the zero page header
to destination.
It seems that this patch is
> It seems that this patch is incorrect, if the no-zero pages are zeroed again
> during !ram_bulk_stage, we didn't send the new zeroed page, there will be
> an error.
>
If not in ram_bulk_stage, still send the header, could you explain why it's
wrong?
Liang
> > For guest just uses a small
On 15/01/2016 10:48, Liang Li wrote:
> Now that VM's RAM pages are initialized to zero, (VM's RAM is allcated
> with the mmap() and MAP_ANONYMOUS option, or mmap() without MAP_SHARED
> if hugetlbfs is used.) so there is no need to send the zero page header
> to destination.
>
> For guest just
* Liang Li (liang.z...@intel.com) wrote:
> Now that VM's RAM pages are initialized to zero, (VM's RAM is allcated
> with the mmap() and MAP_ANONYMOUS option, or mmap() without MAP_SHARED
> if hugetlbfs is used.) so there is no need to send the zero page header
> to destination.
>
> For guest just
Now that VM's RAM pages are initialized to zero, (VM's RAM is allcated
with the mmap() and MAP_ANONYMOUS option, or mmap() without MAP_SHARED
if hugetlbfs is used.) so there is no need to send the zero page header
to destination.
For guest just uses a small portions of RAM, this change can avoid
17 matches
Mail list logo
