Re: Questions about virtio DMA operations

[Arnabjyoti Kalita]

Dear Peter,

I had a few additional questions with regards to dma_memory_map(). So,
let's say I record the buffer that has been written/read from the
disk.

iov[num_sg].iov_base = dma_memory_map(vdev->dma_as, pa, &len, s_write ?
                     DMA_DIRECTION_FROM_DEVICE :
                     DMA_DIRECTION_TO_DEVICE);

addr[num_sg] = pa;
iov[num_sg].iov_len = len;

Is it correct to say that the host virtual address(in the case above,
iov[num_sg].iov_base) that dma_memory_map gives will contain the
actual buffer that has been read/written from/to the device?

And when dma_memory_unmap() happens, the contents of the buffer that
is pointed to by the host virtual address, will be finally written to
the guest physical memory which is pointed to by "pa" in the code
above?

Best Regards,
Arnabjyoti Kalita

On Mon, Aug 30, 2021 at 3:16 PM Arnabjyoti Kalita
<akalita@cs.stonybrook.edu> wrote:
>
> Thank you for the clarification, Peter.
>
> > This sounds to me like the wrong layer to do this. My first
> > stab at a design for this would be to record and replay
> > at the disk block API level.
>
>
> Yes, I did follow the upstream record-and-replay feature and did try
> it. I can see that it has used a different 'blkreplay' driver to
> record the completion "IDs". I am not trying to make the design very
> generic right now since our eventual goal isn't a 'design correct'
> record-replay system. We are using record-replay of network and disk
> I/O to eventually achieve something else. And directly using the
> upstream record-and-replay feature is a slight impediment for me since
> I record in KVM mode and replay in TCG mode. But I get your point. I
> might try a more generic design once I have a working system.
>
> Best Regards,
> Arnabjyoti Kalita
>
>
> On Mon, Aug 30, 2021 at 2:39 PM Peter Maydell <peter.maydell@linaro.org> 
> wrote:
> >
> > On Mon, 30 Aug 2021 at 03:30, Arnabjyoti Kalita
> > <akalita@cs.stonybrook.edu> wrote:
> > >
> > > > That's normal, yes, but you can't guarantee it. The guest can
> > > > choose to program it to any physical memory it likes.
> > >
> > > Is it ? If this is indeterministic, my approach will obviously not
> > > work.
> >
> > It's deterministic to the extent that the guest execution
> > is deterministic. But inside QEMU you can't tell what the
> > deterministic guest execution will or will not do.
> >
> > > Is the bounce buffer address determined at initial startup of
> > > the guest and does it always stay the same during the guest execution?
> >
> > The bounce buffer is at a fixed host address, because it
> > is the global "static BounceBuffer bounce;" in physmem.c.
> >
> > > > I'm not clear on what you're trying to do, but this doesn't
> > > > sound like the right way to go to me.
> > >
> > > So I am trying to record and replay virtio block disk I/O events. I
> > > plan to record the disk I/O by recording the "used" buffers that the
> > > virtio block device puts into the virtqueue after the actual disk I/O
> > > is complete.
> >
> > This sounds to me like the wrong layer to do this. My first
> > stab at a design for this would be to record and replay
> > at the disk block API level. That then does not need to care
> > at all about any of the details of the virtio device implementation
> > (and it would work with any block device, eg scsi, as a bonus).
> > This is how the upstream record-and-replay feature handles block
> > devices.
> >
> > -- PMM