Gleb Natapov wrote:
On Thu, Apr 08, 2010 at 02:27:53PM +0900, Yoshiaki Tamura wrote:
Avi Kivity wrote:
On 04/07/2010 08:21 PM, Yoshiaki Tamura wrote:
The problem here is that, I needed to transfer the VM state which is
just *before* the output to the devices. Otherwise, the VM state has
On Thu, Apr 08, 2010 at 02:27:53PM +0900, Yoshiaki Tamura wrote:
Currently we complete instructions for output operations and leave them
incomplete for input operations. Deferring completion for output
operations should work, except it may break the vmware backdoor port
(see hw/vmport.c),
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
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
Gleb Natapov wrote:
On Thu, Apr 08, 2010 at 02:27:53PM +0900, Yoshiaki Tamura wrote:
Currently we complete instructions for output operations and leave them
incomplete for input operations. Deferring completion for output
operations should work, except it may break the vmware backdoor port
(see
On 04/08/2010 10:30 AM, Yoshiaki Tamura wrote:
To answer your question, it should be possible to implement.
The down side is that after going into KVM to make the guest state to
consistent, we need to go back to qemu to actually transfer the guest,
and this bounce would introduce another
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:
Avi Kivity wrote:
On 04/08/2010 10:30 AM, Yoshiaki Tamura wrote:
To answer your question, it should be possible to implement.
The down side is that after going into KVM to make the guest state to
consistent, we need to go back to qemu to actually transfer the guest,
and this bounce would
On 04/08/2010 11:30 AM, Yoshiaki Tamura wrote:
If I transferred a VM after I/O operations, let's say the VM sent an
TCP ACK to the client, and if a hardware failure occurred to the
primary during the VM transferring *but the client received the TCP
ACK*, the secondary will resume from the
On 04/08/2010 11:10 AM, Yoshiaki Tamura wrote:
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...
I don't think you can in the general case.
Avi Kivity wrote:
On 04/08/2010 11:30 AM, Yoshiaki Tamura wrote:
If I transferred a VM after I/O operations, let's say the VM sent an
TCP ACK to the client, and if a hardware failure occurred to the
primary during the VM transferring *but the client received the TCP
ACK*, the secondary will
On 04/08/2010 12:14 PM, Yoshiaki Tamura wrote:
I don't think you can in the general case. But if you gate output at the
device level, instead of the instruction level, the problem goes
away, no?
Yes, it should.
To implement this, we need to make No.3 to be called asynchronously.
If qemu is
2010/4/8 Avi Kivity a...@redhat.com:
On 04/08/2010 12:14 PM, Yoshiaki Tamura wrote:
I don't think you can in the general case. But if you gate output at the
device level, instead of the instruction level, the problem goes away,
no?
Yes, it should.
To implement this, we need to make No.3 to
On 04/08/2010 04:42 PM, Yoshiaki Tamura wrote:
Yes, you can release the I/O from the iothread instead of the vcpu thread.
You can make virtio_net_handle_tx() disable virtio notifications and
initiate state sync and return, when state sync continues you can call the
original
@vger.kernel.org/msg25141.html) mainly in
userland qemu, we encountered a problem that synchronizing the content of
VCPU
before handling I/O in qemu is too late because rip is already proceeded in
KVM,
Although we avoided this issue with temporal hack, I would like to ask a few
question
avoided this issue with temporal hack, I would like to ask a
few
question on skip_emulated_instructions.
1. Does rip need to be proceeded before having I/O handled by qemu?
In current kvm.git rip is proceeded before I/O is handled by qemu only
in case of out instruction. From architecture
is already proceeded
in KVM,
Although we avoided this issue with temporal hack, I would like to ask a
few
question on skip_emulated_instructions.
1. Does rip need to be proceeded before having I/O handled by qemu?
In current kvm.git rip is proceeded before I/O is handled by qemu only
On 04/07/2010 08:21 PM, Yoshiaki Tamura wrote:
The problem here is that, I needed to transfer the VM state which is
just *before* the output to the devices. Otherwise, the VM state has
already been proceeded, and after failover, some I/O didn't work as I expected.
I tracked down this issue,
Avi Kivity wrote:
On 04/07/2010 08:21 PM, Yoshiaki Tamura wrote:
The problem here is that, I needed to transfer the VM state which is
just *before* the output to the devices. Otherwise, the VM state has
already been proceeded, and after failover, some I/O didn't work as I
expected.
I tracked
On Thu, Apr 08, 2010 at 02:27:53PM +0900, Yoshiaki Tamura wrote:
Avi Kivity wrote:
On 04/07/2010 08:21 PM, Yoshiaki Tamura wrote:
The problem here is that, I needed to transfer the VM state which is
just *before* the output to the devices. Otherwise, the VM state has
already been proceeded,
in
userland qemu, we encountered a problem that synchronizing the content of VCPU
before handling I/O in qemu is too late because rip is already proceeded in
KVM,
Although we avoided this issue with temporal hack, I would like to ask a few
question on skip_emulated_instructions.
1. Does rip
of VCPU
before handling I/O in qemu is too late because rip is already proceeded in KVM,
Although we avoided this issue with temporal hack, I would like to ask a few
question on skip_emulated_instructions.
1. Does rip need to be proceeded before having I/O handled by qemu?
2. If no, is it possible
22 matches
Mail list logo
