Ok, thanks, I'll think about it.
On 27.01.2016 15:42, Dr. David Alan Gilbert wrote:
* Vladimir Sementsov-Ogievskiy (vsement...@virtuozzo.com) wrote:
Hello, Dr. Gilbert!
Hi Vladimir,
As I understand this is not a complete realization of post-copy stage of
migration, but only realization of ra
* Vladimir Sementsov-Ogievskiy (vsement...@virtuozzo.com) wrote:
> Hello, Dr. Gilbert!
Hi Vladimir,
> As I understand this is not a complete realization of post-copy stage of
> migration, but only realization of ram post-copy.
Yes, that's correct; RAM was the only one we'd had much interest in;
Hello, Dr. Gilbert!
As I understand this is not a complete realization of post-copy stage of
migration, but only realization of ram post-copy.. I need to implement
post-copy migration of block-dirty-bitmaps. And it should work
with/without ram post-copy. Did you plan a possibility of post-copy
* Juan Quintela (quint...@redhat.com) wrote:
> "Dr. David Alan Gilbert (git)" wrote:
> > From: "Dr. David Alan Gilbert"
> >
> > This is the 9th cut of my version of postcopy.
> >
> > The userfaultfd linux kernel code is now in the upstream kernel
> > tree, and so 4.3 can be used without modific
"Dr. David Alan Gilbert (git)" wrote:
> From: "Dr. David Alan Gilbert"
>
> This is the 9th cut of my version of postcopy.
>
> The userfaultfd linux kernel code is now in the upstream kernel
> tree, and so 4.3 can be used without modification.
>
> This qemu series can be found at:
> https://gith
* Bharata B Rao (bhar...@linux.vnet.ibm.com) wrote:
> On Mon, Nov 09, 2015 at 11:03:02AM +, Dr. David Alan Gilbert wrote:
> >
> >
> > Oh, I think I see it; the following is untested, I'll grab a machine to
> > try it on but it will take a little while:
> >
> > diff --git a/migration/ram.c b/
On Mon, Nov 09, 2015 at 11:03:02AM +, Dr. David Alan Gilbert wrote:
>
>
> Oh, I think I see it; the following is untested, I'll grab a machine to
> try it on but it will take a little while:
>
> diff --git a/migration/ram.c b/migration/ram.c
> index 62cf42b..e6db965 100644
> --- a/migration/
* Bharata B Rao (bhar...@linux.vnet.ibm.com) wrote:
> On Mon, Nov 09, 2015 at 09:08:33AM +, Dr. David Alan Gilbert wrote:
> > * Bharata B Rao (bhar...@linux.vnet.ibm.com) wrote:
> > > On Fri, Nov 06, 2015 at 03:48:11PM +, Dr. David Alan Gilbert wrote:
> > > > * Bharata B Rao (bhar...@linux.
* Bharata B Rao (bhar...@linux.vnet.ibm.com) wrote:
> On Fri, Nov 06, 2015 at 03:48:11PM +, Dr. David Alan Gilbert wrote:
> > * Bharata B Rao (bhar...@linux.vnet.ibm.com) wrote:
> >
> > > > Where we have iterable, but non-postcopiable devices (e.g. htab
> > > > or block migration), complete th
On 09/11/2015 05:13, David Gibson wrote:
> Which makes me think it's a bit odd that we're not already getting
> most of the htab data across during the precopy phase. Don't we
> already delay entering the postcopy phase until precopy is
> "complete" in the sense that the remaining non-postcopi
On Fri, Nov 06, 2015 at 12:22:23PM +, Dr. David Alan Gilbert wrote:
> * Bharata B Rao (bharata@gmail.com) wrote:
> > On Fri, Nov 6, 2015 at 2:39 PM, Dr. David Alan Gilbert
> > wrote:
> > > * Bharata B Rao (bhar...@linux.vnet.ibm.com) wrote:
> > >> On Thu, Nov 05, 2015 at 06:10:27PM +,
On Fri, Nov 06, 2015 at 03:48:11PM +, Dr. David Alan Gilbert wrote:
> * Bharata B Rao (bhar...@linux.vnet.ibm.com) wrote:
>
> > > Where we have iterable, but non-postcopiable devices (e.g. htab
> > > or block migration), complete them before forming the 'package'
> > > but with the CPUs stoppe
* Bharata B Rao (bhar...@linux.vnet.ibm.com) wrote:
> > Where we have iterable, but non-postcopiable devices (e.g. htab
> > or block migration), complete them before forming the 'package'
> > but with the CPUs stopped. This stops them filling up the package.
>
> That helps and the migration suce
On Fri, Nov 06, 2015 at 01:43:42PM +, Dr. David Alan Gilbert wrote:
> * Dr. David Alan Gilbert (dgilb...@redhat.com) wrote:
> > * Bharata B Rao (bharata@gmail.com) wrote:
> > > On Fri, Nov 6, 2015 at 2:39 PM, Dr. David Alan Gilbert
> > > wrote:
> > > > * Bharata B Rao (bhar...@linux.vnet.i
* Dr. David Alan Gilbert (dgilb...@redhat.com) wrote:
> * Bharata B Rao (bharata@gmail.com) wrote:
> > On Fri, Nov 6, 2015 at 2:39 PM, Dr. David Alan Gilbert
> > wrote:
> > > * Bharata B Rao (bhar...@linux.vnet.ibm.com) wrote:
> > >> On Thu, Nov 05, 2015 at 06:10:27PM +, Dr. David Alan Gil
* Bharata B Rao (bharata@gmail.com) wrote:
> On Fri, Nov 6, 2015 at 2:39 PM, Dr. David Alan Gilbert
> wrote:
> > * Bharata B Rao (bhar...@linux.vnet.ibm.com) wrote:
> >> On Thu, Nov 05, 2015 at 06:10:27PM +, Dr. David Alan Gilbert (git)
> >> wrote:
> >> > From: "Dr. David Alan Gilbert"
>
On Fri, Nov 6, 2015 at 2:39 PM, Dr. David Alan Gilbert
wrote:
> * Bharata B Rao (bhar...@linux.vnet.ibm.com) wrote:
>> On Thu, Nov 05, 2015 at 06:10:27PM +, Dr. David Alan Gilbert (git) wrote:
>> > From: "Dr. David Alan Gilbert"
>> >
>> > This is the 9th cut of my version of postcopy.
>> >
* Bharata B Rao (bhar...@linux.vnet.ibm.com) wrote:
> On Thu, Nov 05, 2015 at 06:10:27PM +, Dr. David Alan Gilbert (git) wrote:
> > From: "Dr. David Alan Gilbert"
> >
> > This is the 9th cut of my version of postcopy.
> >
> > The userfaultfd linux kernel code is now in the upstream kernel
On Thu, Nov 05, 2015 at 06:10:27PM +, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert"
>
> This is the 9th cut of my version of postcopy.
>
> The userfaultfd linux kernel code is now in the upstream kernel
> tree, and so 4.3 can be used without modification.
>
> This q
From: "Dr. David Alan Gilbert"
This is the 9th cut of my version of postcopy.
The userfaultfd linux kernel code is now in the upstream kernel
tree, and so 4.3 can be used without modification.
This qemu series can be found at:
https://github.com/orbitfp7/qemu.git
on the wp3-postcopy-v9 tag
T
20 matches
Mail list logo
