All of lore.kernel.org
 help / color / mirror / Atom feed
* [Qemu-devel] Recording I/O activity after KVM does a VMEXIT
@ 2018-05-31  3:19 Arnabjyoti Kalita
  2018-05-31  8:50 ` Stefan Hajnoczi
  0 siblings, 1 reply; 7+ messages in thread
From: Arnabjyoti Kalita @ 2018-05-31  3:19 UTC (permalink / raw)
  To: qemu-devel

Hello all,

I am trying to implement a 'minimal' record-replay mechanism for KVM, which
is similar to the one existing for TCG via -icount. I am trying to record
I/O events only (specifically disk and network events) when KVM does a
VMEXIT. This has led me to the function kvm_cpu_exec where I can clearly
see the different ways of handling all of the possible VMExit cases (like
PIO, MMIO etc.). To record network packets, I am working with the e1000
hardware device.

Can I make sure that all of the network I/O, atleast for the e1000 device
happens through the KVM_EXIT_MMIO case and subsequent use of the
address_space_rw() function ? Do I also need to look at other functions as
well ? Also for recording disk activity, can I make sure that looking out
for the KVM_EXIT_MMIO and/or KVM_EXIT_PIO cases in the vmexit mechanism,
will be enough ?

Let me know if there are other details that I need to take care of. I am
using QEMU 2.11 on a x86-64 CPU and the guest runs a Linux Kernel 4.4 with
Ubuntu 16.04.

Thanks and Regards,
Arnab

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [Qemu-devel] Recording I/O activity after KVM does a VMEXIT
  2018-05-31  3:19 [Qemu-devel] Recording I/O activity after KVM does a VMEXIT Arnabjyoti Kalita
@ 2018-05-31  8:50 ` Stefan Hajnoczi
  2018-05-31 12:44   ` Pavel Dovgalyuk
  0 siblings, 1 reply; 7+ messages in thread
From: Stefan Hajnoczi @ 2018-05-31  8:50 UTC (permalink / raw)
  To: Arnabjyoti Kalita; +Cc: qemu-devel, Pavel Dovgalyuk

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

On Wed, May 30, 2018 at 11:19:13PM -0400, Arnabjyoti Kalita wrote:
> I am trying to implement a 'minimal' record-replay mechanism for KVM, which
> is similar to the one existing for TCG via -icount. I am trying to record
> I/O events only (specifically disk and network events) when KVM does a
> VMEXIT. This has led me to the function kvm_cpu_exec where I can clearly
> see the different ways of handling all of the possible VMExit cases (like
> PIO, MMIO etc.). To record network packets, I am working with the e1000
> hardware device.
> 
> Can I make sure that all of the network I/O, atleast for the e1000 device
> happens through the KVM_EXIT_MMIO case and subsequent use of the
> address_space_rw() function ? Do I also need to look at other functions as
> well ? Also for recording disk activity, can I make sure that looking out
> for the KVM_EXIT_MMIO and/or KVM_EXIT_PIO cases in the vmexit mechanism,
> will be enough ?
> 
> Let me know if there are other details that I need to take care of. I am
> using QEMU 2.11 on a x86-64 CPU and the guest runs a Linux Kernel 4.4 with
> Ubuntu 16.04.

I have CCed Pavel Dovgalyuk, the record/replay maintainer.

Stefan

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [Qemu-devel] Recording I/O activity after KVM does a VMEXIT
  2018-05-31  8:50 ` Stefan Hajnoczi
@ 2018-05-31 12:44   ` Pavel Dovgalyuk
  2018-05-31 20:14     ` Arnabjyoti Kalita
  0 siblings, 1 reply; 7+ messages in thread
From: Pavel Dovgalyuk @ 2018-05-31 12:44 UTC (permalink / raw)
  To: 'Stefan Hajnoczi', 'Arnabjyoti Kalita'
  Cc: qemu-devel, 'Pavel Dovgalyuk'

> From: Stefan Hajnoczi [mailto:stefanha@gmail.com]
> On Wed, May 30, 2018 at 11:19:13PM -0400, Arnabjyoti Kalita wrote:
> > I am trying to implement a 'minimal' record-replay mechanism for KVM, which
> > is similar to the one existing for TCG via -icount. I am trying to record
> > I/O events only (specifically disk and network events) when KVM does a
> > VMEXIT. This has led me to the function kvm_cpu_exec where I can clearly
> > see the different ways of handling all of the possible VMExit cases (like
> > PIO, MMIO etc.). To record network packets, I am working with the e1000
> > hardware device.
> >
> > Can I make sure that all of the network I/O, atleast for the e1000 device
> > happens through the KVM_EXIT_MMIO case and subsequent use of the
> > address_space_rw() function ? Do I also need to look at other functions as
> > well ? Also for recording disk activity, can I make sure that looking out
> > for the KVM_EXIT_MMIO and/or KVM_EXIT_PIO cases in the vmexit mechanism,
> > will be enough ?
> >
> > Let me know if there are other details that I need to take care of. I am
> > using QEMU 2.11 on a x86-64 CPU and the guest runs a Linux Kernel 4.4 with
> > Ubuntu 16.04.

The main icount-based record/replay advantage is that we don't record
any CPU IO. We record only VM IO (e.g., by using the network filter).

Disk devices may transfer data to CPU using DMA, therefore intercepting
only VMExit cases will not be enough.

Pavel Dovgalyuk

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [Qemu-devel] Recording I/O activity after KVM does a VMEXIT
  2018-05-31 12:44   ` Pavel Dovgalyuk
@ 2018-05-31 20:14     ` Arnabjyoti Kalita
  2018-06-01  5:31       ` Pavel Dovgalyuk
  0 siblings, 1 reply; 7+ messages in thread
From: Arnabjyoti Kalita @ 2018-05-31 20:14 UTC (permalink / raw)
  To: Pavel Dovgalyuk; +Cc: Stefan Hajnoczi, qemu-devel, Pavel Dovgalyuk

Dear Pavel,

Thank you for your answer. I am not being able to understand the difference
between CPU I/Os and VM I/Os. Would any network packet that comes into the
Guest OS from the outside be a part of VM I/O or CPU I/O ? I am only
interested in "recording" and "replaying" those network packets that come
from the outside into the networking backend and not the other way around.
Say for example when I get a VMExit because of the arrival of a network
packet, I will use the VMExit reason : "KVM_EXIT_MMIO"  to trace back to
"e1000_mmio_write()" which I expect should be enough to record network
packets that come from the outside and write to the guest address space for
"e1000" devices. In such a case, I think I will not have to use the
"network-filter" backend that you use to record VM I/O only. Let me know if
you find errors in my approach.

I will try to see how I can record disk packets. If disk packets use other
ways of writing to the guest memory apart from a normal VMExit, I will try
to find it out. Eventually I hope that it will use one of the available
disk front-end functions to write to the guest memory from the disk, just
like e1000 does with an "e1000_mmio_write()" call.

Thanks and best regards,
Arnab







On Thu, May 31, 2018 at 8:44 AM, Pavel Dovgalyuk <dovgaluk@ispras.ru> wrote:

> > From: Stefan Hajnoczi [mailto:stefanha@gmail.com]
> > On Wed, May 30, 2018 at 11:19:13PM -0400, Arnabjyoti Kalita wrote:
> > > I am trying to implement a 'minimal' record-replay mechanism for KVM,
> which
> > > is similar to the one existing for TCG via -icount. I am trying to
> record
> > > I/O events only (specifically disk and network events) when KVM does a
> > > VMEXIT. This has led me to the function kvm_cpu_exec where I can
> clearly
> > > see the different ways of handling all of the possible VMExit cases
> (like
> > > PIO, MMIO etc.). To record network packets, I am working with the e1000
> > > hardware device.
> > >
> > > Can I make sure that all of the network I/O, atleast for the e1000
> device
> > > happens through the KVM_EXIT_MMIO case and subsequent use of the
> > > address_space_rw() function ? Do I also need to look at other
> functions as
> > > well ? Also for recording disk activity, can I make sure that looking
> out
> > > for the KVM_EXIT_MMIO and/or KVM_EXIT_PIO cases in the vmexit
> mechanism,
> > > will be enough ?
> > >
> > > Let me know if there are other details that I need to take care of. I
> am
> > > using QEMU 2.11 on a x86-64 CPU and the guest runs a Linux Kernel 4.4
> with
> > > Ubuntu 16.04.
>
> The main icount-based record/replay advantage is that we don't record
> any CPU IO. We record only VM IO (e.g., by using the network filter).
>
> Disk devices may transfer data to CPU using DMA, therefore intercepting
> only VMExit cases will not be enough.
>
> Pavel Dovgalyuk
>
>

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [Qemu-devel] Recording I/O activity after KVM does a VMEXIT
  2018-05-31 20:14     ` Arnabjyoti Kalita
@ 2018-06-01  5:31       ` Pavel Dovgalyuk
  2018-06-01  8:27         ` Arnabjyoti Kalita
  0 siblings, 1 reply; 7+ messages in thread
From: Pavel Dovgalyuk @ 2018-06-01  5:31 UTC (permalink / raw)
  To: 'Arnabjyoti Kalita'
  Cc: 'Stefan Hajnoczi', qemu-devel, 'Pavel Dovgalyuk'

Hi,

 

I’m not familiar with KVM, but I know successful attempts of replaying the execution by logging IO and MMIO in TCG mode.

The difference in CPU I/O and VM I/O is the following. In icount we record anything coming into the VM, but not into the CPU.

It means that the whole packet is recorded. Virtual hardware behaves deterministically and therefore CPU will get identical

input in case of replay, because the whole recorded packet is injected again by the filter.

 

Pavel Dovgalyuk

 

From: Arnabjyoti Kalita [mailto:akalita@cs.stonybrook.edu] 
Sent: Thursday, May 31, 2018 11:14 PM
To: Pavel Dovgalyuk
Cc: Stefan Hajnoczi; qemu-devel@nongnu.org; Pavel Dovgalyuk
Subject: Re: [Qemu-devel] Recording I/O activity after KVM does a VMEXIT

 

Dear Pavel,

 

Thank you for your answer. I am not being able to understand the difference between CPU I/Os and VM I/Os. Would any network packet that comes into the Guest OS from the outside be a part of VM I/O or CPU I/O ? I am only interested in "recording" and "replaying" those network packets that come from the outside into the networking backend and not the other way around. Say for example when I get a VMExit because of the arrival of a network packet, I will use the VMExit reason : "KVM_EXIT_MMIO"  to trace back to "e1000_mmio_write()" which I expect should be enough to record network packets that come from the outside and write to the guest address space for "e1000" devices. In such a case, I think I will not have to use the "network-filter" backend that you use to record VM I/O only. Let me know if you find errors in my approach.

 

I will try to see how I can record disk packets. If disk packets use other ways of writing to the guest memory apart from a normal VMExit, I will try to find it out. Eventually I hope that it will use one of the available disk front-end functions to write to the guest memory from the disk, just like e1000 does with an "e1000_mmio_write()" call. 

 

Thanks and best regards,

Arnab

 

 

 

 

 

    

 

On Thu, May 31, 2018 at 8:44 AM, Pavel Dovgalyuk <dovgaluk@ispras.ru> wrote:

> From: Stefan Hajnoczi [mailto:stefanha@gmail.com]
> On Wed, May 30, 2018 at 11:19:13PM -0400, Arnabjyoti Kalita wrote:
> > I am trying to implement a 'minimal' record-replay mechanism for KVM, which
> > is similar to the one existing for TCG via -icount. I am trying to record
> > I/O events only (specifically disk and network events) when KVM does a
> > VMEXIT. This has led me to the function kvm_cpu_exec where I can clearly
> > see the different ways of handling all of the possible VMExit cases (like
> > PIO, MMIO etc.). To record network packets, I am working with the e1000
> > hardware device.
> >
> > Can I make sure that all of the network I/O, atleast for the e1000 device
> > happens through the KVM_EXIT_MMIO case and subsequent use of the
> > address_space_rw() function ? Do I also need to look at other functions as
> > well ? Also for recording disk activity, can I make sure that looking out
> > for the KVM_EXIT_MMIO and/or KVM_EXIT_PIO cases in the vmexit mechanism,
> > will be enough ?
> >
> > Let me know if there are other details that I need to take care of. I am
> > using QEMU 2.11 on a x86-64 CPU and the guest runs a Linux Kernel 4.4 with
> > Ubuntu 16.04.

The main icount-based record/replay advantage is that we don't record
any CPU IO. We record only VM IO (e.g., by using the network filter).

Disk devices may transfer data to CPU using DMA, therefore intercepting
only VMExit cases will not be enough.

Pavel Dovgalyuk

 

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [Qemu-devel] Recording I/O activity after KVM does a VMEXIT
  2018-06-01  5:31       ` Pavel Dovgalyuk
@ 2018-06-01  8:27         ` Arnabjyoti Kalita
  2018-06-01  9:32           ` Pavel Dovgalyuk
  0 siblings, 1 reply; 7+ messages in thread
From: Arnabjyoti Kalita @ 2018-06-01  8:27 UTC (permalink / raw)
  To: Pavel Dovgalyuk; +Cc: Stefan Hajnoczi, qemu-devel, Pavel Dovgalyuk

Dear Pavel,

Thank you for providing me with all the details. Let us take an example of
a Network packet. In icount mode, when the network backend, receives a
network packet, you record the whole packet with the help of the
replay-filter. This packet will be written to the log file. Now when the
time comes for replay, you stop accepting any packets from the network
backend and directly inject all of the packets that you have already
recorded in the log file into the guest address space memory. Am I correct
in understanding this ?

Thanks and Regards,
Arnab

On Fri, Jun 1, 2018 at 1:31 AM, Pavel Dovgalyuk <dovgaluk@ispras.ru> wrote:

> Hi,
>
>
>
> I’m not familiar with KVM, but I know successful attempts of replaying the
> execution by logging IO and MMIO in TCG mode.
>
> The difference in CPU I/O and VM I/O is the following. In icount we record
> anything coming into the VM, but not into the CPU.
>
> It means that the whole packet is recorded. Virtual hardware behaves
> deterministically and therefore CPU will get identical
>
> input in case of replay, because the whole recorded packet is injected
> again by the filter.
>
>
>
> Pavel Dovgalyuk
>
>
>
> *From:* Arnabjyoti Kalita [mailto:akalita@cs.stonybrook.edu]
> *Sent:* Thursday, May 31, 2018 11:14 PM
> *To:* Pavel Dovgalyuk
> *Cc:* Stefan Hajnoczi; qemu-devel@nongnu.org; Pavel Dovgalyuk
> *Subject:* Re: [Qemu-devel] Recording I/O activity after KVM does a VMEXIT
>
>
>
> Dear Pavel,
>
>
>
> Thank you for your answer. I am not being able to understand the
> difference between CPU I/Os and VM I/Os. Would any network packet that
> comes into the Guest OS from the outside be a part of VM I/O or CPU I/O ? I
> am only interested in "recording" and "replaying" those network packets
> that come from the outside into the networking backend and not the other
> way around. Say for example when I get a VMExit because of the arrival of a
> network packet, I will use the VMExit reason : "KVM_EXIT_MMIO"  to trace
> back to "e1000_mmio_write()" which I expect should be enough to record
> network packets that come from the outside and write to the guest address
> space for "e1000" devices. In such a case, I think I will not have to use
> the "network-filter" backend that you use to record VM I/O only. Let me
> know if you find errors in my approach.
>
>
>
> I will try to see how I can record disk packets. If disk packets use other
> ways of writing to the guest memory apart from a normal VMExit, I will try
> to find it out. Eventually I hope that it will use one of the available
> disk front-end functions to write to the guest memory from the disk, just
> like e1000 does with an "e1000_mmio_write()" call.
>
>
>
> Thanks and best regards,
>
> Arnab
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Thu, May 31, 2018 at 8:44 AM, Pavel Dovgalyuk <dovgaluk@ispras.ru>
> wrote:
>
> > From: Stefan Hajnoczi [mailto:stefanha@gmail.com]
> > On Wed, May 30, 2018 at 11:19:13PM -0400, Arnabjyoti Kalita wrote:
> > > I am trying to implement a 'minimal' record-replay mechanism for KVM,
> which
> > > is similar to the one existing for TCG via -icount. I am trying to
> record
> > > I/O events only (specifically disk and network events) when KVM does a
> > > VMEXIT. This has led me to the function kvm_cpu_exec where I can
> clearly
> > > see the different ways of handling all of the possible VMExit cases
> (like
> > > PIO, MMIO etc.). To record network packets, I am working with the e1000
> > > hardware device.
> > >
> > > Can I make sure that all of the network I/O, atleast for the e1000
> device
> > > happens through the KVM_EXIT_MMIO case and subsequent use of the
> > > address_space_rw() function ? Do I also need to look at other
> functions as
> > > well ? Also for recording disk activity, can I make sure that looking
> out
> > > for the KVM_EXIT_MMIO and/or KVM_EXIT_PIO cases in the vmexit
> mechanism,
> > > will be enough ?
> > >
> > > Let me know if there are other details that I need to take care of. I
> am
> > > using QEMU 2.11 on a x86-64 CPU and the guest runs a Linux Kernel 4.4
> with
> > > Ubuntu 16.04.
>
> The main icount-based record/replay advantage is that we don't record
> any CPU IO. We record only VM IO (e.g., by using the network filter).
>
> Disk devices may transfer data to CPU using DMA, therefore intercepting
> only VMExit cases will not be enough.
>
> Pavel Dovgalyuk
>
>
>

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [Qemu-devel] Recording I/O activity after KVM does a VMEXIT
  2018-06-01  8:27         ` Arnabjyoti Kalita
@ 2018-06-01  9:32           ` Pavel Dovgalyuk
  0 siblings, 0 replies; 7+ messages in thread
From: Pavel Dovgalyuk @ 2018-06-01  9:32 UTC (permalink / raw)
  To: 'Arnabjyoti Kalita'
  Cc: 'Stefan Hajnoczi', qemu-devel, 'Pavel Dovgalyuk'

That’s right.

 

Pavel Dovgalyuk

 

From: Arnabjyoti Kalita [mailto:akalita@cs.stonybrook.edu] 
Sent: Friday, June 01, 2018 11:27 AM
To: Pavel Dovgalyuk
Cc: Stefan Hajnoczi; qemu-devel@nongnu.org; Pavel Dovgalyuk
Subject: Re: [Qemu-devel] Recording I/O activity after KVM does a VMEXIT

 

Dear Pavel,

 

Thank you for providing me with all the details. Let us take an example of a Network packet. In icount mode, when the network backend, receives a network packet, you record the whole packet with the help of the replay-filter. This packet will be written to the log file. Now when the time comes for replay, you stop accepting any packets from the network backend and directly inject all of the packets that you have already recorded in the log file into the guest address space memory. Am I correct in understanding this ?

 

Thanks and Regards,

Arnab  

 

On Fri, Jun 1, 2018 at 1:31 AM, Pavel Dovgalyuk <dovgaluk@ispras.ru> wrote:

Hi,

 

I’m not familiar with KVM, but I know successful attempts of replaying the execution by logging IO and MMIO in TCG mode.

The difference in CPU I/O and VM I/O is the following. In icount we record anything coming into the VM, but not into the CPU.

It means that the whole packet is recorded. Virtual hardware behaves deterministically and therefore CPU will get identical

input in case of replay, because the whole recorded packet is injected again by the filter.

 

Pavel Dovgalyuk

 

From: Arnabjyoti Kalita [mailto:akalita@cs.stonybrook.edu] 
Sent: Thursday, May 31, 2018 11:14 PM
To: Pavel Dovgalyuk
Cc: Stefan Hajnoczi; qemu-devel@nongnu.org; Pavel Dovgalyuk
Subject: Re: [Qemu-devel] Recording I/O activity after KVM does a VMEXIT

 

Dear Pavel,

 

Thank you for your answer. I am not being able to understand the difference between CPU I/Os and VM I/Os. Would any network packet that comes into the Guest OS from the outside be a part of VM I/O or CPU I/O ? I am only interested in "recording" and "replaying" those network packets that come from the outside into the networking backend and not the other way around. Say for example when I get a VMExit because of the arrival of a network packet, I will use the VMExit reason : "KVM_EXIT_MMIO"  to trace back to "e1000_mmio_write()" which I expect should be enough to record network packets that come from the outside and write to the guest address space for "e1000" devices. In such a case, I think I will not have to use the "network-filter" backend that you use to record VM I/O only. Let me know if you find errors in my approach.

 

I will try to see how I can record disk packets. If disk packets use other ways of writing to the guest memory apart from a normal VMExit, I will try to find it out. Eventually I hope that it will use one of the available disk front-end functions to write to the guest memory from the disk, just like e1000 does with an "e1000_mmio_write()" call. 

 

Thanks and best regards,

Arnab

 

 

 

 

 

    

 

On Thu, May 31, 2018 at 8:44 AM, Pavel Dovgalyuk <dovgaluk@ispras.ru> wrote:

> From: Stefan Hajnoczi [mailto:stefanha@gmail.com]
> On Wed, May 30, 2018 at 11:19:13PM -0400, Arnabjyoti Kalita wrote:
> > I am trying to implement a 'minimal' record-replay mechanism for KVM, which
> > is similar to the one existing for TCG via -icount. I am trying to record
> > I/O events only (specifically disk and network events) when KVM does a
> > VMEXIT. This has led me to the function kvm_cpu_exec where I can clearly
> > see the different ways of handling all of the possible VMExit cases (like
> > PIO, MMIO etc.). To record network packets, I am working with the e1000
> > hardware device.
> >
> > Can I make sure that all of the network I/O, atleast for the e1000 device
> > happens through the KVM_EXIT_MMIO case and subsequent use of the
> > address_space_rw() function ? Do I also need to look at other functions as
> > well ? Also for recording disk activity, can I make sure that looking out
> > for the KVM_EXIT_MMIO and/or KVM_EXIT_PIO cases in the vmexit mechanism,
> > will be enough ?
> >
> > Let me know if there are other details that I need to take care of. I am
> > using QEMU 2.11 on a x86-64 CPU and the guest runs a Linux Kernel 4.4 with
> > Ubuntu 16.04.

The main icount-based record/replay advantage is that we don't record
any CPU IO. We record only VM IO (e.g., by using the network filter).

Disk devices may transfer data to CPU using DMA, therefore intercepting
only VMExit cases will not be enough.

Pavel Dovgalyuk

 

 

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2018-06-01  9:32 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-05-31  3:19 [Qemu-devel] Recording I/O activity after KVM does a VMEXIT Arnabjyoti Kalita
2018-05-31  8:50 ` Stefan Hajnoczi
2018-05-31 12:44   ` Pavel Dovgalyuk
2018-05-31 20:14     ` Arnabjyoti Kalita
2018-06-01  5:31       ` Pavel Dovgalyuk
2018-06-01  8:27         ` Arnabjyoti Kalita
2018-06-01  9:32           ` Pavel Dovgalyuk

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.