qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] char: don't fail when client is not connected


From: Marc-André Lureau
Subject: Re: [PATCH] char: don't fail when client is not connected
Date: Wed, 3 Feb 2021 12:38:19 +0400

Hi

On Wed, Feb 3, 2021 at 12:22 PM Pavel Dovgalyuk <pavel.dovgalyuk@ispras.ru> wrote:
On 03.02.2021 11:13, Marc-André Lureau wrote:

> Can you provide a reproducer?


That was a record/replay scenario. I've used Fedora cloudinit images,
that are used in acceptance tests:

qemu-system-x86_64 \
  -display none -vga none -machine pc -smp 1 -m 1024 \
  -monitor tcp:127.0.0.1:8081,server,nowait \
  -serial tcp:127.0.0.1:8082,server,nowait \
  -object filter-replay,id=replay,netdev=hub0port0 \
  -drive
file=Fedora-Cloud-Base-31-1.9.x86_64.qcow2,snapshot,id=disk0,if=none \
  -drive driver=blkreplay,id=disk0-rr,if=none,image=disk0 \
  -device virtio-blk-pci,drive=disk0-rr,ioeventfd=false \
  -icount shift=1,rr=record,rrfile=replay.bin \
  -drive file=cloudinit.iso,snapshot,id=disk1,if=none \
  -drive driver=blkreplay,id=disk1-rr,if=none,image=disk1 \
  -device virtio-blk-pci,drive=disk1-rr,ioeventfd=false


The failure occurred on replay stage:

qemu-system-x86_64 \
  -display none -vga none -machine pc -smp 1 -m 1024 \
  -monitor tcp:127.0.0.1:8081,server,nowait \
  -serial tcp:127.0.0.1:8082,server,nowait \
  -object filter-replay,id=replay,netdev=hub0port0 \
  -drive
file=Fedora-Cloud-Base-31-1.9.x86_64.qcow2,snapshot,id=disk0,if=none \
  -drive driver=blkreplay,id=disk0-rr,if=none,image=disk0 \
  -device virtio-blk-pci,drive=disk0-rr,ioeventfd=false \
  -icount shift=1,rr=replay,rrfile=replay.bin \
  -drive file=cloudinit.iso,snapshot,id=disk1,if=none \
  -drive driver=blkreplay,id=disk1-rr,if=none,image=disk1 \
  -device virtio-blk-pci,drive=disk1-rr,ioeventfd=false

Ah, that helps. qemu_chr_write() will return replay_char_write_event_load(), bypassing the current state. If the connected state during replay doesn't match the state during recording, it is possible to reach the bad condition. (there are probably many such corner-cases situations with replay..)

Can you update the commit message to explain the relation with replay? with that:
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>

Daniel, could you review it too?
thanks

reply via email to

[Prev in Thread] Current Thread [Next in Thread]