On Sat, 11/28 13:51, Peter Xu wrote:
> On Fri, Nov 27, 2015 at 01:14:25PM +0800, Fam Zheng wrote:
> > On Fri, 11/27 10:48, Peter Xu wrote:
>
> [snip]
>
> >
> > This patch doesn't handle the incoming migration case, i.e. when QEMU is
> > started with "-incoming", or "-incoming defer". Dump can go
On Fri, Nov 27, 2015 at 01:14:25PM +0800, Fam Zheng wrote:
> On Fri, 11/27 10:48, Peter Xu wrote:
[snip]
>
> This patch doesn't handle the incoming migration case, i.e. when QEMU is
> started with "-incoming", or "-incoming defer". Dump can go wrong when
> incoming
> migration happens at the sa
On 27/11/2015 12:26, Peter Xu wrote:
> On Fri, Nov 27, 2015 at 11:31:00AM +0100, Paolo Bonzini wrote:
>>
>
> [snip]
>
>>> +
>>> +static GlobalDumpState *dump_state_get_global(void)
>>> +{
>>> +static bool init = false;
>>> +static GlobalDumpState global_dump_state;
>>> +if (unlikely
On Fri, Nov 27, 2015 at 11:31:00AM +0100, Paolo Bonzini wrote:
>
[snip]
> > +
> > +static GlobalDumpState *dump_state_get_global(void)
> > +{
> > +static bool init = false;
> > +static GlobalDumpState global_dump_state;
> > +if (unlikely(!init)) {
> > +qemu_mutex_init(&global
On Fri, Nov 27, 2015 at 11:14:17AM +0100, Paolo Bonzini wrote:
>
>
> On 27/11/2015 07:27, Peter Xu wrote:
> > If embed the mr pointer into GuestPhyBlock, then we might need to
> > ref/unref one MemoryRegion for multiple times (and I am not sure how
> > many, maybe it could be a very big number es
On 27/11/2015 03:48, Peter Xu wrote:
> This patch implements "detach" for "dump-guest-memory" command. When
> specified, one background thread is created to do the dump work.
>
> When there is a dump running in background, the commands "stop",
> "cont" and "dump-guest-memory" will fail directly,
On 27/11/2015 07:27, Peter Xu wrote:
> If embed the mr pointer into GuestPhyBlock, then we might need to
> ref/unref one MemoryRegion for multiple times (and I am not sure how
> many, maybe it could be a very big number especially the
> MemoryRegionSections are scattered?). Not sure whether it is
On 11/27/2015 01:14 PM, Fam Zheng wrote:
> On Fri, 11/27 10:48, Peter Xu wrote:
>> This patch implements "detach" for "dump-guest-memory" command. When
>> specified, one background thread is created to do the dump work.
>>
>> When there is a dump running in background, the commands "stop",
>> "co
On Fri, 11/27 13:14, Fam Zheng wrote:
> But what I really wonder is why a single boolean is not enough: the DumpState
> pointer can be passed to dump_thread, so it doesn't need to be global, then
> you
> don't need the mutex.
Never mind, it's useful in later patches.
Fam
On Fri, 11/27 10:48, Peter Xu wrote:
> This patch implements "detach" for "dump-guest-memory" command. When
> specified, one background thread is created to do the dump work.
>
> When there is a dump running in background, the commands "stop",
> "cont" and "dump-guest-memory" will fail directly, w
This patch implements "detach" for "dump-guest-memory" command. When
specified, one background thread is created to do the dump work.
When there is a dump running in background, the commands "stop",
"cont" and "dump-guest-memory" will fail directly, with a hint
telling user: "there is a dump in pr
11 matches
Mail list logo
