Ah, thanks for looking into this and identifying it to guest code
Philippe. I don't know much about terminals, but yes, they are such
archaic interfaces, maybe there is no API for it :-(
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
Public bug reported:
QEMU 4.2.0 compiled from source, Ubuntu 19.10, open a fresh new gnome
terminal.
If you print 1000 = chars on the host terminal, then they do wrap around
the end of the terminal:
printf "=%.0s" {0..1000}
However, if you first run QEMU:
x86_64-softmmu/qemu-system-x86_64 -nog
Did we open a precise glibc upstream bug for this so I can go upvote it?
:-)
Workaround from #12 also worked for me.
Tested on Buildroot with this precise setup:
https://github.com/cirosantilli/linux-kernel-module-
cheat/tree/e855a262fd872171156894e9045814cb0f346dab#stack-smashing-
detected
For
On Thu, Apr 26, 2018 at 1:34 PM, Pavel Dovgalyuk wrote:
> > From: Ciro Santilli [mailto:ciro.santi...@gmail.com]
> > On Wed, Apr 25, 2018 at 1:45 PM, Pavel Dovgalyuk
> > wrote:
> > > GDB remote protocol supports reverse debugging of the targets.
> > > It
OK, finally got some time to try it out, I'm using
c42634d8e3428cfa60672c3ba89cabefc720cde9 from rr-180725.
Replay works well as far as I can tell, so I moved to the reverse debugging:
/home/ciro/bak/git/linux-kernel-module-cheat/out/x86_
64/buildroot/build/host-qemu-custom.rr/x86_64-softmmu/qemu
Things that work:
-
https://github.com/cirosantilli/linux-kernel-module-cheat/tree/741f5215e9515c0d7179671f49fe1781f94e70e3#graphic-mode-arm
which shows the Penguin with the Linux kernel, after hacking that repo up to
use the exact same QEMU executable as reported here
- the UART examples on th
Public bug reported:
QEMU v2.12.0, Ubuntu 18.04 host.
Build QEMU and the bare metal image exactly as described at:
https://raspberrypi.stackexchange.com/revisions/85135/4 with:
Then cd into example 09_framebuffer.
Now if I do:
../../qemu/aarch64-softmmu/qemu-system-aarch64 -M raspi3 -kernel
ke
On Wed, May 23, 2018 at 2:28 PM, Pavel Dovgalyuk wrote:
>> From: Ciro Santilli [mailto:ciro.santi...@gmail.com]
>> On Wed, May 23, 2018 at 7:49 AM, Pavel Dovgalyuk
>> wrote:
>> > GDB remote protocol supports reverse debugging of the targets.
>> > It includes
On Wed, May 23, 2018 at 7:49 AM, Pavel Dovgalyuk
wrote:
> GDB remote protocol supports reverse debugging of the targets.
> It includes 'reverse step' and 'reverse continue' operations.
> The first one finds the previous step of the execution,
> and the second one is intended to stop at the last br
Did you manage to reproduce and solve the savevm and loadvm problems I
mentioned at:
http://lists.nongnu.org/archive/html/qemu-devel/2018-04/msg05219.html
?
I still observe them on the current patch.
On Sat, Apr 28, 2018 at 1:36 PM, Pavel Dovgalyuk
wrote:
> GDB remote protocol supports reverse
@arna35: I have tested this yet unmerged patch:
https://lists.gnu.org/archive/html/qemu-devel/2018-04/msg04286.html and
it solves this problem, I will close this issue once it gets merged.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEM
On Sat, Apr 28, 2018 at 10:27 AM, Pavel Dovgalyuk wrote:
>
>
>> -Original Message-----
>> From: Ciro Santilli [mailto:ciro.santi...@gmail.com]
>> Sent: Saturday, April 28, 2018 11:13 AM
>> To: Pavel Dovgalyuk
>> Subject: Re: [RFC PATCH 00/17] reverse debugg
On Sat, Apr 28, 2018 at 9:12 AM, Pavel Dovgalyuk wrote:
>> From: Ciro Santilli [mailto:ciro.santi...@gmail.com]
>> On Thu, Apr 26, 2018 at 1:34 PM, Pavel Dovgalyuk wrote:
>> >> From: Ciro Santilli [mailto:ciro.santi...@gmail.com]
>> >> On Wed, Apr
Forgetting about debugging, I belive there is a deadlock in the replay
at 63d426dfa4fbfac3d50cda3f553cd975de2b85ea , but it is rare.
I have only reproduced it on ARM so far, and I haven't checked pre-patch.
The setup is
https://github.com/cirosantilli/qemu-test/tree/6a3497f0d84e7c86ef80f7322e24e
On Wed, Apr 25, 2018 at 1:45 PM, Pavel Dovgalyuk
wrote:
> GDB remote protocol supports reverse debugging of the targets.
> It includes 'reverse step' and 'reverse continue' operations.
> The first one finds the previous step of the execution,
> and the second one is intended to stop at the last br
** Description changed:
QEMU master at 915d34c5f99b0ab91517c69f54272bfdb6ca2b32 Ubuntu 17.10
host.
QEMU commands:
```
#!/usr/bin/env bash
cmd="\
time \
./x86_64-softmmu/qemu-system-x86_64 \
-append 'root=/dev/sda console=ttyS0 nokaslr printk.time=y -
lkmc_eval=\"/rand_chec
** Description changed:
- QEMU master at 08e173f29461396575c85510eb41474b993cb1fb Ubuntu 17.10
+ QEMU master at 915d34c5f99b0ab91517c69f54272bfdb6ca2b32 Ubuntu 17.10
host.
QEMU commands:
```
#!/usr/bin/env bash
cmd="\
time \
./x86_64-softmmu/qemu-system-x86_64 \
-append 'root
** Description changed:
QEMU master at 08e173f29461396575c85510eb41474b993cb1fb Ubuntu 17.10
host.
QEMU commands:
```
#!/usr/bin/env bash
cmd="\
time \
./x86_64-softmmu/qemu-system-x86_64 \
- -M pc \
-append 'root=/dev/sda console=ttyS0 nokaslr printk.time=y -
lkmc_eval=\"
** Description changed:
QEMU master at 08e173f29461396575c85510eb41474b993cb1fb Ubuntu 17.10
host.
QEMU commands:
```
#!/usr/bin/env bash
cmd="\
time \
- ./out/x86_64/buildroot/host/usr/bin/qemu-system-x86_64 \
+ ./x86_64-softmmu/qemu-system-x86_64 \
-M pc \
-append 'root=/
** Description changed:
- QEMU master at 08e173f29461396575c85510eb41474b993cb1fb
+ QEMU master at 08e173f29461396575c85510eb41474b993cb1fb Ubuntu 17.10
+ host.
QEMU commands:
-
```
#!/usr/bin/env bash
cmd="\
time \
./out/x86_64/buildroot/host/usr/bin/qemu-system-x86_64 \
-M p
Public bug reported:
QEMU master at 08e173f29461396575c85510eb41474b993cb1fb
QEMU commands:
```
#!/usr/bin/env bash
cmd="\
time \
./out/x86_64/buildroot/host/usr/bin/qemu-system-x86_64 \
-M pc \
-append 'root=/dev/sda console=ttyS0 nokaslr printk.time=y -
lkmc_eval=\"/rand_check.out;/sbin/ifup
Just to re-affirm, I have ran this patch on x86 and arm, and it worked.
On Mon, Mar 12, 2018 at 10:32 AM, Pavel Dovgalyuk wrote:
> Ping.
>
> Pavel Dovgalyuk
>
>
>> -Original Message-
>> From: Pavel Dovgalyuk [mailto:pavel.dovga...@ispras.ru]
>> Sent: Tuesday, February 27, 2018 12:52 PM
>
On Thu, Feb 22, 2018 at 7:10 AM, Pavel Dovgalyuk wrote:
>> From: Pavel Dovgalyuk [mailto:dovga...@ispras.ru]
>> > From: Ciro Santilli [mailto:ciro.santi...@gmail.com]
>> > On Wed, Feb 21, 2018 at 6:41 AM, Pavel Dovgalyuk
>> > wrote:
>> > >> Fro
On Wed, Feb 21, 2018 at 6:41 AM, Pavel Dovgalyuk wrote:
>> From: Ciro Santilli [mailto:ciro.santi...@gmail.com]
>> On Tue, Feb 20, 2018 at 9:46 AM, Pavel Dovgalyuk wrote:
>> >
>> > Updated the branch on github.
>> > You may try it.
>>
>> At
On Tue, Feb 20, 2018 at 9:46 AM, Pavel Dovgalyuk wrote:
>> From: Ciro Santilli [mailto:ciro.santi...@gmail.com]
>> On Mon, Feb 19, 2018 at 8:02 AM, Pavel Dovgalyuk wrote:
>> >> From: Pavel Dovgalyuk [mailto:dovga...@ispras.ru]
>> >> > From: Peter M
On Mon, Feb 19, 2018 at 8:02 AM, Pavel Dovgalyuk wrote:
>> From: Pavel Dovgalyuk [mailto:dovga...@ispras.ru]
>> > From: Peter Maydell [mailto:peter.mayd...@linaro.org]
>> > On 13 February 2018 at 10:26, Pavel Dovgalyuk wrote:
>> > > Then I added SCSI adapter with the option –device lsi,id=scsi0 a
2.0
and everything is fully automated at:
https://github.com/cirosantilli/linux-kernel-module-cheat/tree/5ae702c71c2b2ad326b7791ff128cac0d8b298a2
by running:
./build -q
On Wed, Feb 7, 2018 at 12:38 PM, Pavel Dovgalyuk wrote:
>> From: Ciro Santilli [mailto:ciro.santi...@gmail.com]
>> Can you provide a test branch somewhere so I can easily test it out?
>
> Here it is: https://github.com/ispras/qemu/tree/rr-180207
>
> Pavel Dovgalyuk
>
On Tue, Feb 13, 2018 at 10:52 AM, Pavel Dovgalyuk
wrote:
> > From: Peter Maydell [mailto:peter.mayd...@linaro.org]
> > On 13 February 2018 at 10:26, Pavel Dovgalyuk
> wrote:
> > > Then I added SCSI adapter with the option –device lsi,id=scsi0 and QEMU
> > > failed with the following error:
> > >
he new one instead.
Now it should be just the vanilla Linux kernel versatilepb one.
How to specify the --dtb configuration explicitly on the command line? I
have also included the dts on the zip if that helps.
>
>
> Pavel Dovgalyuk
>
>
>
> *From:* Ciro Santilli [mailto:ciro.san
//github.com/cirosantilli/linux-kernel-module-cheat/releases/download/test-replay-arm/images.zip
They were generated with:
./build -a arm
on that repo.
> Pavel Dovgalyuk
>
>
>
> *From:* Ciro Santilli [mailto:ciro.santi...@gmail.com]
> *Sent:* Saturday, February 10, 2018 3:09
Also, what command do you use to test on ARM? I'm a bit stuck to get the
drive part right, e.g.:
-drive
file=./buildroot/output.arm~/images/rootfs.ext2,if=scsi,id=img-direct,format=raw
\
-drive driver=blkreplay,if=none,image=img-direct,id=img-blkreplay \
-device scsi-hd,drive=img-blkreplay \
fail
On Wed, Feb 7, 2018 at 12:38 PM, Pavel Dovgalyuk wrote:
> > From: Ciro Santilli [mailto:ciro.santi...@gmail.com]
> > Can you provide a test branch somewhere so I can easily test it out?
>
> Here it is: https://github.com/ispras/qemu/tree/rr-180207
>
> Pavel Dovgalyuk
On Wed, Feb 7, 2018 at 12:03 PM, Pavel Dovgalyuk
wrote:
> This set of patches moves replay lock upper in the function call tree.
> Now replay lock functions similar to BQL in older version and allows
> deterministic execution of the threads in icount mode.
> It is also fixes some vmstate creation
I want to create models for external hardware devices.
If interrupts generation and memory modification were possible with
serialized asynchronous APIs like QMP / QAPI, then I would be able to:
- write the models in any language I want
- not need to patch QEMU source code, and keep all my changes
34 matches
Mail list logo
