[Qemu-devel] Asynchronous / synchronous IO emulation

[Qemu-devel] Asynchronous / synchronous IO emulation

[Dong, Eddie]

Hi:
         Under certain situation, we have a requirement to apply the virtual DMA event in a deterministic way. Current Qemu uses asynchronous approach to emulate the virtual IO events since quite long time ago. I am wondering if we still have an option to choose the synchronous emulation solution.

         Thanks, Eddie

Re: [Qemu-devel] Asynchronous / synchronous IO emulation

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 409 bytes --]

On Thu, Nov 24, 2016 at 08:44:06AM +0000, Dong, Eddie wrote:
>          Under certain situation, we have a requirement to apply the virtual DMA event in a deterministic way. Current Qemu uses asynchronous approach to emulate the virtual IO events since quite long time ago. I am wondering if we still have an option to choose the synchronous emulation solution.

Please explain exactly what you mean.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [Qemu-devel] Asynchronous / synchronous IO emulation

[Dong, Eddie]

> 
> On Thu, Nov 24, 2016 at 08:44:06AM +0000, Dong, Eddie wrote:
> >          Under certain situation, we have a requirement to apply the
> virtual DMA event in a deterministic way. Current Qemu uses asynchronous
> approach to emulate the virtual IO events since quite long time ago. I am
> wondering if we still have an option to choose the synchronous emulation
> solution.
> 
> Please explain exactly what you mean.
> 
The usage is to construct a secondary hot standby VM (SVM), identical with the primary VM (PVM).
When an virtual DMA happens in PVM side, we need to know at which instruction boundary the virtual DMA is delivered, so that we can replay the virtual DMA event at the 2nd VM side, to keep them identical at any time.

Asynchronous IO emulations seems to be a little bit more complicate to be deterministic...
I might be wrong.

Thx Eddie

Re: [Qemu-devel] Asynchronous / synchronous IO emulation

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 1245 bytes --]

On Fri, Nov 25, 2016 at 09:17:08AM +0000, Dong, Eddie wrote:
> > On Thu, Nov 24, 2016 at 08:44:06AM +0000, Dong, Eddie wrote:
> > >          Under certain situation, we have a requirement to apply the
> > virtual DMA event in a deterministic way. Current Qemu uses asynchronous
> > approach to emulate the virtual IO events since quite long time ago. I am
> > wondering if we still have an option to choose the synchronous emulation
> > solution.
> > 
> > Please explain exactly what you mean.
> > 
> The usage is to construct a secondary hot standby VM (SVM), identical with the primary VM (PVM).
> When an virtual DMA happens in PVM side, we need to know at which instruction boundary the virtual DMA is delivered, so that we can replay the virtual DMA event at the 2nd VM side, to keep them identical at any time.
> 
> Asynchronous IO emulations seems to be a little bit more complicate to be deterministic...
> I might be wrong.

There is a record-replay mode that might be worth investigating.  See
docs/replay.txt.

It sounds like you are not using live migration for micro-checkpoints?
The live migration mechanism would keep memory in sync at each
checkpoint.

Is this work releated to the COLO effort?

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [Qemu-devel] Asynchronous / synchronous IO emulation

[Dong, Eddie]

> > The usage is to construct a secondary hot standby VM (SVM), identical with
> the primary VM (PVM).
> > When an virtual DMA happens in PVM side, we need to know at which
> instruction boundary the virtual DMA is delivered, so that we can replay the
> virtual DMA event at the 2nd VM side, to keep them identical at any time.
> >
> > Asynchronous IO emulations seems to be a little bit more complicate to be
> deterministic...
> > I might be wrong.
> 
> There is a record-replay mode that might be worth investigating.  See
> docs/replay.txt.
> 
> It sounds like you are not using live migration for micro-checkpoints?
> The live migration mechanism would keep memory in sync at each
> checkpoint.
> 
> Is this work releated to the COLO effort?
> 
> Stefan

Thanks Stefan.  COLO is one what we push for high availability.
This is yet another project leveraging KVM for deterministic execution, which is still in room. I use VM replicating to explain the concept, but it is not used for high availability. 
Eddie