Re: Block I/O record and replay questions
Dear Pavel,
Thank you very much for your answers.
So if I understand correctly, the blkreplay layer would only record
disk events generated by the virtual device, so this solves the
problem of recording only the relevant disk events that change the
guest state.
Best Regards,
Arnabjyoti Kalita
On Thu, Aug 5, 2021 at 12:10 PM Pavel Dovgalyuk
wrote:
>
> On 05.08.2021 09:06, Arnabjyoti Kalita wrote:
> > Hello all,
> >
> > I was following the docs on QEMU replay
> > (https://github.com/qemu/qemu/blob/master/docs/replay.txt) and I had a
> > few questions about the implementation of block I/O record and replay
> > in QEMU.
> >
> > All my questions are numbered. And for context, I am running QEMU
> > 5.0.1 where both the host and target architecture is x86_64. I am
> > using the virtio-blk-pci device in QCOW2 format as my backing storage
> > for the guest.
> >
> > The below code snippet -
> >
> > uint64_t offset, uint64_t bytes, QEMUIOVector *qiov, int flags)
> > {
> > uint64_t reqid = blkreplay_next_id();
> > int ret = bdrv_co_preadv(bs->file, offset, bytes, qiov, flags);
> > block_request_create(reqid, bs, qemu_coroutine_self());
> > qemu_coroutine_yield();
> >
> > return ret;
> > }
> >
> > The "reqid" local variable is being used inside block_request_create
> > where we record the "reqid" to a file.
> >
> > replay_block_event(req->bh, reqid);
> >
> > 1) Is the "reqid" generated during/before a disk request is completed
> > and then recorded after completion of the disk request? Does this
> > mean, we are actually only recording the order of completion of disk
> > requests here?
>
> Yes, we control only the order of completion.
>
> >
> > I also see that these request ids that are recorded are later replayed
> > before a checkpoint.
> >
> > if (replay_state.read_event_id == -1) {
> > replay_state.read_event_id = replay_get_qword();
> > }
> >
> > 2) Is it correct to say that during replay, we try to follow the same
> > order of completions of the disk requests as it happened during
> > record? Can these checkpoints be any deterministic event, like say, a
> > disk interrupt?
>
> Right.
>
> >
> > 3) How do we separate disk requests that are actually generated by the
> > guest from the ones generated by QEMU (for eg. with operations like
> > loadvm/savevm)?
>
> QEMU works with image directly. Virtual devices act through the layer
> with blkreplay which records the events.
>
> >
> > Thank you very much.
> >
> > Best Regards,
> > Arnabjyoti Kalita
> >
>
Re: Block I/O record and replay questions
On 05.08.2021 09:06, Arnabjyoti Kalita wrote:
Hello all,
I was following the docs on QEMU replay
(https://github.com/qemu/qemu/blob/master/docs/replay.txt) and I had a
few questions about the implementation of block I/O record and replay
in QEMU.
All my questions are numbered. And for context, I am running QEMU
5.0.1 where both the host and target architecture is x86_64. I am
using the virtio-blk-pci device in QCOW2 format as my backing storage
for the guest.
The below code snippet -
uint64_t offset, uint64_t bytes, QEMUIOVector *qiov, int flags)
{
uint64_t reqid = blkreplay_next_id();
int ret = bdrv_co_preadv(bs->file, offset, bytes, qiov, flags);
block_request_create(reqid, bs, qemu_coroutine_self());
qemu_coroutine_yield();
return ret;
}
The "reqid" local variable is being used inside block_request_create
where we record the "reqid" to a file.
replay_block_event(req->bh, reqid);
1) Is the "reqid" generated during/before a disk request is completed
and then recorded after completion of the disk request? Does this
mean, we are actually only recording the order of completion of disk
requests here?
Yes, we control only the order of completion.
I also see that these request ids that are recorded are later replayed
before a checkpoint.
if (replay_state.read_event_id == -1) {
replay_state.read_event_id = replay_get_qword();
}
2) Is it correct to say that during replay, we try to follow the same
order of completions of the disk requests as it happened during
record? Can these checkpoints be any deterministic event, like say, a
disk interrupt?
Right.
3) How do we separate disk requests that are actually generated by the
guest from the ones generated by QEMU (for eg. with operations like
loadvm/savevm)?
QEMU works with image directly. Virtual devices act through the layer
with blkreplay which records the events.
Thank you very much.
Best Regards,
Arnabjyoti Kalita
Block I/O record and replay questions
Hello all,
I was following the docs on QEMU replay
(https://github.com/qemu/qemu/blob/master/docs/replay.txt) and I had a
few questions about the implementation of block I/O record and replay
in QEMU.
All my questions are numbered. And for context, I am running QEMU
5.0.1 where both the host and target architecture is x86_64. I am
using the virtio-blk-pci device in QCOW2 format as my backing storage
for the guest.
The below code snippet -
uint64_t offset, uint64_t bytes, QEMUIOVector *qiov, int flags)
{
uint64_t reqid = blkreplay_next_id();
int ret = bdrv_co_preadv(bs->file, offset, bytes, qiov, flags);
block_request_create(reqid, bs, qemu_coroutine_self());
qemu_coroutine_yield();
return ret;
}
The "reqid" local variable is being used inside block_request_create
where we record the "reqid" to a file.
replay_block_event(req->bh, reqid);
1) Is the "reqid" generated during/before a disk request is completed
and then recorded after completion of the disk request? Does this
mean, we are actually only recording the order of completion of disk
requests here?
I also see that these request ids that are recorded are later replayed
before a checkpoint.
if (replay_state.read_event_id == -1) {
replay_state.read_event_id = replay_get_qword();
}
2) Is it correct to say that during replay, we try to follow the same
order of completions of the disk requests as it happened during
record? Can these checkpoints be any deterministic event, like say, a
disk interrupt?
3) How do we separate disk requests that are actually generated by the
guest from the ones generated by QEMU (for eg. with operations like
loadvm/savevm)?
Thank you very much.
Best Regards,
Arnabjyoti Kalita
