Gleb Natapov wrote:
On Thu, Apr 08, 2010 at 10:17:01AM +0300, Avi Kivity wrote:
On 04/08/2010 08:27 AM, Yoshiaki Tamura wrote:
The requirement is that the guest must always be able to replay at
least the instruction which triggered the synchronization on the
primary.
You have two choices:
- complete execution of the instruction in both the kernel and the
device model
This is what live migration does currently. Any mmio and pio
requests are completed, the last instruction is finalized, and state
is saved.
- complete execution of the instruction in the kernel, but queue
execution of mmio/pio requests
This is more in line with what you describe. vcpu state will be
after the instruction, device model state will be before instruction
completion, when you replay the queue, the device model state will
be consistent with the vcpu state.
For "in" or "mmio read" you can't complete instruction without doing
actual IO.
So, if the mmio/pio requests in the queue are only "out" or "mmio write" Avi's
suggestion No.2 would work. But if "in" or "mmio read" are mixed with these, (We
don't have to think if the queue is filled with only "in" or "mmio read" because
we're currently transferring only in case of "out" or "mmio write")
the story gets complicated.
From that point of view, I think I need to transfer the vcpu
state before the instruction. If I post a signal and let the
guest or emulator proceed, I'm not sure whether the guest on the
secondary can be replay as expected. Please point out if I were
misunderstanding.
If the responses to the mmio or pio request are exactly the same,
then the replay will happen exactly the same.
I agree. What I'm wondering is how can we guarantee that the responses are the
same...
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
