[Top][All Lists]

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

Re: [Qemu-devel] [PATCH v3 00/11] MTTCG fix-ups for 2.9

From: Alex Bennée
Subject: Re: [Qemu-devel] [PATCH v3 00/11] MTTCG fix-ups for 2.9
Date: Tue, 14 Mar 2017 15:18:32 +0000
User-agent: mu4e 0.9.19; emacs 25.2.9

Pavel Dovgalyuk <address@hidden> writes:

>> From: Alex Bennée [mailto:address@hidden
>> Pavel Dovgalyuk <address@hidden> writes:
>> >> From: address@hidden [mailto:mttcg-
>> address@hidden
>> >>
>> >> The next thing on my list it to look at the icount problems and review
>> >> Paolo's fixes for it. However those fixes should go in a separate
>> >> series and I assume via Paolo's tree.
>> >
>> > Do you mean those problems that completely broke icount?
>> Completely broke is a bit strong. Certainly I tested icount on my
>> patches but I missed the pathological failure mode that led to the
>> interaction between the BQL lock breaking patch and running a real
>> guest. It didn't break icount so much as slow down guests so much they
>> never got round to finishing their IRQ handling.
> That might look as slowing down in regular icount mode.
> But it becomes non-deterministic in record/replay mode.
> Therefore none of the recorded scenarios may be replayed.
> I tried the simplest command lines:
> qemu-system-i386.exe -icount shift=7,rr=record,rrfile=replay.bin -net
> none

Running this against 2421f381dc (pre-merge of MTTCG) from the source
tree generates no output. My command is on Linux:

  /x86_64-softmmu/qemu-system-x86_64 -icount 
shift=7,rr=record,rrfile=replay.bin -net none

Do I need to specify the BIOS manually?

> qemu-system-i386.exe -icount shift=7,rr=replay,rrfile=replay.bin -net none
> First one was used to record execution until BIOS will print its startup info.
> The second one is for replay, but it can replay about 200000 instructions
> until the problems with icount manifest itself - the execution does
> not proceed.

What error message does it give? How do you know how many instructions
have been executed?

I ran the following test on both pre-mttcg-merge and my current HEAD
which includes Paolo's fix series:

 ./arm-softmmu/qemu-system-arm -machine type=virt \
    -display none -smp 1 -m 4096 -cpu cortex-a15 \
    -kernel ../images/aarch32-current-linux-initrd-guest.img
    -append "console=ttyAMA0" -serial mon:stdio \
    -net none \
    -icount shift=7,rr=record,rrfile=replay.bin

And then:

 ./arm-softmmu/qemu-system-arm -machine type=virt \
    -display none -smp 1 -m 4096 -cpu cortex-a15 \
    -kernel ../images/aarch32-current-linux-initrd-guest.img
    -append "console=ttyAMA0" -serial mon:stdio \
    -net none \
    -icount shift=7,rr=replay,rrfile=replay.bin

And they both ran the same. However I kept running into:

 [    3.542408] RPC: Registered tcp NFSv4.1 backchannel transport module.
qemu-system-arm: Missing character write event in the replay log

This seems to be a pre-existing

>> That certainly seems to be fixed by Paolo's patches.
>> > Are you going to fix it?
>> Yes. It is certainly not intentional to regress icount and it needs to
>> be fixed before we release 2.9.
>> If you can point me towards the record/replay test cases I'll make sure
>> I run them on the updated series.
> Pavel Dovgalyuk

Alex Bennée

reply via email to

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