qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH v2 00/49] Series short description


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [RFC PATCH v2 00/49] Series short description
Date: Mon, 28 Jul 2014 12:12:32 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0

Il 28/07/2014 09:50, Pavel Dovgaluk ha scritto:
>> - patches 2 to 13 probably should try to use subsections, so that VMs
>> that do not use the devices try not to save the extra data and keep
>> backwards migration compatibility (at least try to)
> 
>  Could you give me and example?
>  As I know, subsection is loaded when some predicate function returns true. 
> How can I 
> construct such a function for integratorcp module? What kind of condition 
> should it check?
>  In this module I just added missed vmstates (it does not saved/restored at 
> all
> by the master version).

I tried to review the x86 ones.  These are the most interesting ones,
because it's the only board where we support cross-version migration.

Parallel is (quite obviously) unsalvageable, and I think HPET is too.

>> - patch 16 should also use subsections, and perhaps apply to all other
>> CPUs too?
> 
>  We implemented replay only for i386 and ARM. If we'll change other targets, 
> it will not
> add record/replay capabilities to them, but can confuse the reviewers.

Why are these fields only required by record/replay?

>> - patches 23-24-25 perhaps could try using icount, like Konrad's patch do?
> 
>  Using faster icount (like in Konrad's patches) is the our next aim. It 
> obviously will 
> increase the speed of recording process. But now I submitted slower, but more 
> conservative
> version of icount which we had already tested.

I see.

>> - patch 27 makes sense but VIRTUAL is used to skip blinking when the VM
>> is stopped
> 
>  Right, this is kind of hack. I haven't found better solution yet.

I think it's okay to use REALTIME, just add runstate_is_running() to the
"if (now >= s->cursor_blink_time)".

That said, "every read to virtual clock is written to the
replay log" worries me a bit from the point of view of thread-safety.
Do you need to log all reads because you don't use icount?  Reads can
only happen at given points if you use icount, and you could simply log
the icount value at each synchronization point.

Paolo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]