From: Yoshiaki Tamura <tamura.yoshiaki@lab.ntt.co.jp>
To: Gleb Natapov <gleb@redhat.com>
Cc: Avi Kivity <avi@redhat.com>,
kvm@vger.kernel.org, Marcelo Tosatti <mtosatti@redhat.com>
Subject: Re: Question on skip_emulated_instructions()
Date: Thu, 08 Apr 2010 17:10:28 +0900 [thread overview]
Message-ID: <4BBD8F74.8070401@lab.ntt.co.jp> (raw)
In-Reply-To: <20100408071953.GI303@redhat.com>
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...
next prev parent reply other threads:[~2010-04-08 8:10 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-06 4:11 Question on skip_emulated_instructions() Yoshiaki Tamura
2010-04-06 10:05 ` Gleb Natapov
2010-04-07 6:25 ` Yoshiaki Tamura
2010-04-07 15:43 ` Gleb Natapov
2010-04-07 17:21 ` Yoshiaki Tamura
2010-04-07 17:37 ` Avi Kivity
2010-04-08 5:27 ` Yoshiaki Tamura
2010-04-08 5:41 ` Gleb Natapov
2010-04-08 6:18 ` Yoshiaki Tamura
2010-04-08 6:56 ` Gleb Natapov
2010-04-08 7:30 ` Yoshiaki Tamura
2010-04-08 7:37 ` Avi Kivity
2010-04-08 8:30 ` Yoshiaki Tamura
2010-04-08 8:38 ` Avi Kivity
2010-04-08 7:17 ` Avi Kivity
2010-04-08 7:19 ` Gleb Natapov
2010-04-08 8:10 ` Yoshiaki Tamura [this message]
2010-04-08 8:40 ` Avi Kivity
2010-04-08 9:14 ` Yoshiaki Tamura
2010-04-08 11:49 ` Avi Kivity
2010-04-08 13:42 ` Yoshiaki Tamura
2010-04-08 13:47 ` Avi Kivity
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4BBD8F74.8070401@lab.ntt.co.jp \
--to=tamura.yoshiaki@lab.ntt.co.jp \
--cc=avi@redhat.com \
--cc=gleb@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=mtosatti@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox