> > > > > > I'm just catching back up on this thread; so without
> > > > > > reference to any particular previous mail in the thread.
> > > > > >
> > > > > > 1) How many of the free pages do we tell the host about?
> > > > > > Your main change is telling the host about all the
> > > > > >
* Li, Liang Z (liang.z...@intel.com) wrote:
> > On Mon, Mar 14, 2016 at 05:03:34PM +, Dr. David Alan Gilbert wrote:
> > > * Li, Liang Z (liang.z...@intel.com) wrote:
> > > > >
> > > > > Hi,
> > > > > I'm just catching back up on this thread; so without reference
> > > > > to any particular pr
> On Mon, Mar 14, 2016 at 05:03:34PM +, Dr. David Alan Gilbert wrote:
> > * Li, Liang Z (liang.z...@intel.com) wrote:
> > > >
> > > > Hi,
> > > > I'm just catching back up on this thread; so without reference
> > > > to any particular previous mail in the thread.
> > > >
> > > > 1) How many
On Mon, Mar 14, 2016 at 05:03:34PM +, Dr. David Alan Gilbert wrote:
> * Li, Liang Z (liang.z...@intel.com) wrote:
> > >
> > > Hi,
> > > I'm just catching back up on this thread; so without reference to any
> > > particular previous mail in the thread.
> > >
> > > 1) How many of the free p
> > > Hi,
> > > I'm just catching back up on this thread; so without reference to
> > > any particular previous mail in the thread.
> > >
> > > 1) How many of the free pages do we tell the host about?
> > > Your main change is telling the host about all the
> > > free pages.
> >
> > Y
* Li, Liang Z (liang.z...@intel.com) wrote:
> >
> > Hi,
> > I'm just catching back up on this thread; so without reference to any
> > particular previous mail in the thread.
> >
> > 1) How many of the free pages do we tell the host about?
> > Your main change is telling the host about al
>
> Hi,
> I'm just catching back up on this thread; so without reference to any
> particular previous mail in the thread.
>
> 1) How many of the free pages do we tell the host about?
> Your main change is telling the host about all the
> free pages.
Yes, all the guest's free pages.
Hi,
I'm just catching back up on this thread; so without reference to any
particular previous mail in the thread.
1) How many of the free pages do we tell the host about?
Your main change is telling the host about all the
free pages.
If we tell the host about all the free pages,
> > Could provide more information on how to use virtio-serial to exchange
> data? Thread , Wiki or code are all OK.
> > I have not find some useful information yet.
>
> See this commit in the Linux sources:
>
> 108fc82596e3b66b819df9d28c1ebbc9ab5de14c
>
> that adds a way to send guest trace
On (Thu) 10 Mar 2016 [07:44:19], Li, Liang Z wrote:
>
> Hi Amit,
>
> Could provide more information on how to use virtio-serial to exchange data?
> Thread , Wiki or code are all OK.
> I have not find some useful information yet.
See this commit in the Linux sources:
108fc82596e3b66b819df9d
> > This patch set is the QEMU side implementation.
> >
> > The virtio-balloon is extended so that QEMU can get the free pages
> > information from the guest through virtio.
> >
> > After getting the free pages information (a bitmap), QEMU can use it
> > to filter out the guest's free pages in the
> Subject: Re: [RFC qemu 0/4] A PV solution for live migration optimization
>
> On (Thu) 03 Mar 2016 [18:44:24], Liang Li wrote:
> > The current QEMU live migration implementation mark the all the
> > guest's RAM pages as dirtied in the ram bulk stage, all these pages
On (Fri) 04 Mar 2016 [15:02:47], Jitendra Kolhe wrote:
> > >
> > > * Liang Li (liang.z...@intel.com) wrote:
> > > > The current QEMU live migration implementation mark the all the
> > > > guest's RAM pages as dirtied in the ram bulk stage, all these pages
> > > > will be processed and that takes qu
On (Thu) 03 Mar 2016 [18:44:24], Liang Li wrote:
> The current QEMU live migration implementation mark the all the
> guest's RAM pages as dirtied in the ram bulk stage, all these pages
> will be processed and that takes quit a lot of CPU cycles.
>
> From guest's point of view, it doesn't care abou
> > > * Liang Li (liang.z...@intel.com) wrote:
> > > > The current QEMU live migration implementation mark the all the
> > > > guest's RAM pages as dirtied in the ram bulk stage, all these
> > > > pages will be processed and that takes quit a lot of CPU cycles.
> > > >
> > > > From guest's point of
> Subject: Re: [RFC qemu 0/4] A PV solution for live migration optimization
>
> * Liang Li (liang.z...@intel.com) wrote:
> > The current QEMU live migration implementation mark the all the
> > guest's RAM pages as dirtied in the ram bulk stage, all these pages
> >
* Liang Li (liang.z...@intel.com) wrote:
> The current QEMU live migration implementation mark the all the
> guest's RAM pages as dirtied in the ram bulk stage, all these pages
> will be processed and that takes quit a lot of CPU cycles.
>
> From guest's point of view, it doesn't care about the co
17 matches
Mail list logo
