From: Pavel Dovgalyuk
This patch updates the description of the command lines for using
record/replay with attached block devices.
Signed-off-by: Pavel Dovgalyuk
---
docs/replay.txt | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/docs/replay.txt
From: Pavel Dovgalyuk
This patch fixes shutdown of the replay process, which is terminated with
the assert when shutdown event is read from the log.
replay_finish_event reads new data_kind and therefore the value of data_kind
should be preserved to be valid at qemu_system_shutdown_request call.
Ivan Ren wrote:
> When we 'migrate_cancel' a multifd migration, live_migration thread may
> go into endless loop in multifd_send_pages functions.
>
> Reproduce steps:
>
> (qemu) migrate_set_capability multifd on
> (qemu) migrate -d url
> (qemu) [wait a while]
> (qemu) migrate_cancel
>
> Then may
From: pbonz...@redhat.com
This is a fix which was missed by patch
74c0b816adfc6aa1b01b4426fdf385e32e35cbac, which added current_step
parameter to the replay_advance_current_step function.
Signed-off-by: Pavel Dovgalyuk
---
replay/replay-internal.c |2 +-
1 file changed, 1 insertion(+), 1
From: Pavel Dovgalyuk
This patch enables making snapshots with blkreplay used in
block devices.
This function is required to make bdrv_snapshot_goto without
calling .bdrv_open which is not implemented.
Signed-off-by: Pavel Dovgalyuk
Acked-by: Kevin Wolf
---
block/blkreplay.c |8
From: Pavel Dovgalyuk
This patch disables setting '-snapshot' option on by default
in record/replay mode. This is needed for creating vmstates in record
and replay modes.
Signed-off-by: Pavel Dovgalyuk
Acked-by: Kevin Wolf
---
vl.c | 10 --
1 file changed, 8 insertions(+), 2
The set of patches include the latest fixes for record/replay icount function:
- fix for icount for the case when translation blocks are chained
- block operation fixes for rr mode
- development documentation update
- some refactoring
These patches make record/replay functional on the latest
On Tue, Jul 23, 2019 at 12:58:10PM -0400, John Snow wrote:
>
>
> On 7/23/19 5:47 AM, Fabian Grünbichler wrote:
> > On Mon, Jul 22, 2019 at 01:21:02PM -0400, John Snow wrote:
> >>
> >>
> >> On 7/22/19 8:17 AM, Fabian Grünbichler wrote:
> >>> On Tue, Jul 09, 2019 at 07:25:32PM -0400, John Snow
The KVM_CAP_PPC_IRQ_LEVEL is part of the kernel now since 2.6.37.
Drop the redundant logic which is not excercised on new the kernels anymore.
Signed-off-by: Shivaprasad G Bhat
---
v4: https://lists.gnu.org/archive/html/qemu-devel/2019-07/msg04456.html
Changes from v4:
- it was discussed to
The patch "iotests: Set read-zeroes on in null block driver for Valgrind"
needs the change in 051.out when compared against on the s390 system.
Reported-by: Christian Borntraeger
Signed-off-by: Andrey Shinkevich
---
tests/qemu-iotests/051.out | 10 +-
1 file changed, 5 insertions(+), 5
On 24/07/2019 11:05, Kevin Wolf wrote:
> Am 24.07.2019 um 09:57 hat Andrey Shinkevich geschrieben:
>>
>>
>> On 24/07/2019 10:38, Kevin Wolf wrote:
>>> Am 24.07.2019 um 09:30 hat Andrey Shinkevich geschrieben:
On 24/07/2019 10:18, Christian Borntraeger wrote:
>
> On
Am 24.07.2019 um 09:57 hat Andrey Shinkevich geschrieben:
>
>
> On 24/07/2019 10:38, Kevin Wolf wrote:
> > Am 24.07.2019 um 09:30 hat Andrey Shinkevich geschrieben:
> >>
> >>
> >> On 24/07/2019 10:18, Christian Borntraeger wrote:
> >>>
> >>> On 19.07.19 15:43, Kevin Wolf wrote:
> From:
On 24/07/2019 10:38, Kevin Wolf wrote:
> Am 24.07.2019 um 09:30 hat Andrey Shinkevich geschrieben:
>>
>>
>> On 24/07/2019 10:18, Christian Borntraeger wrote:
>>>
>>> On 19.07.19 15:43, Kevin Wolf wrote:
From: Andrey Shinkevich
The Valgrind tool reports about the uninitialised
Am 24.07.2019 um 09:30 hat Andrey Shinkevich geschrieben:
>
>
> On 24/07/2019 10:18, Christian Borntraeger wrote:
> >
> > On 19.07.19 15:43, Kevin Wolf wrote:
> >> From: Andrey Shinkevich
> >>
> >> The Valgrind tool reports about the uninitialised buffer 'buf'
> >> instantiated on the stack of
On Tue, Jul 23, 2019 at 05:37:18PM +, Montes, Julio wrote:
> Stefano, Brilliant job!
>
> I can confirm that with these patches the memory footprint is smaller
> and the boot time is the same for kata
>
> Here the results using kata metrics
>
> https://pasteboard.co/Ipl06Q0.png
>
On 24/07/2019 10:33, Christian Borntraeger wrote:
>
>
> On 24.07.19 09:30, Andrey Shinkevich wrote:
>>
>>
>> On 24/07/2019 10:18, Christian Borntraeger wrote:
>>>
>>> On 19.07.19 15:43, Kevin Wolf wrote:
From: Andrey Shinkevich
The Valgrind tool reports about the uninitialised
On 24.07.19 09:30, Andrey Shinkevich wrote:
>
>
> On 24/07/2019 10:18, Christian Borntraeger wrote:
>>
>> On 19.07.19 15:43, Kevin Wolf wrote:
>>> From: Andrey Shinkevich
>>>
>>> The Valgrind tool reports about the uninitialised buffer 'buf'
>>> instantiated on the stack of the function
On 24/07/2019 10:18, Christian Borntraeger wrote:
>
> On 19.07.19 15:43, Kevin Wolf wrote:
>> From: Andrey Shinkevich
>>
>> The Valgrind tool reports about the uninitialised buffer 'buf'
>> instantiated on the stack of the function guess_disk_lchs().
>> Pass 'read-zeroes=on' to the null block
>
> Persistent backend setup requires some knowledge about nvdimm and ndctl
> tool. Some users report they may struggle to gather these knowledge and
> have difficulty to setup it properly.
>
> Here we provide two examples for persistent backend and gives the link
> to ndctl. By doing so, user
On 19.07.19 15:43, Kevin Wolf wrote:
> From: Andrey Shinkevich
>
> The Valgrind tool reports about the uninitialised buffer 'buf'
> instantiated on the stack of the function guess_disk_lchs().
> Pass 'read-zeroes=on' to the null block driver to make it deterministic.
> The output of the tests
On Tue, Jul 23, 2019 at 11:26:18AM -0600, Alex Williamson wrote:
> > On 3/29/19 11:49 AM, Alex Williamson wrote:
> > > [Cc +Brijesh]
> > >
> > > Hi Brijesh, will the change below require the IVRS to be updated to
> > > include aliases for all BDF ranges behind a conventional bridge? I
> > >
On 24/07/2019 05:23, David Gibson wrote:
> On Tue, Jul 23, 2019 at 11:01:38AM +0200, Cédric Le Goater wrote:
>> Devices such as the BT or serial devices require a valid
>> "interrupt-parent" phandle in the device tree and it is currently
>> empty (0x0). It was not a problem until now but since
Persistent backend setup requires some knowledge about nvdimm and ndctl
tool. Some users report they may struggle to gather these knowledge and
have difficulty to setup it properly.
Here we provide two examples for persistent backend and gives the link
to ndctl. By doing so, user could try it
ping for review
problem still exist in qemu-4.1.0-rc2
Threads: 24 total, 0 running, 24 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si,
0.0 st
KiB Mem : 39434172+total, 36798950+free, 2948836 used, 23403388 buff/cache
KiB Swap:
On Tue, Jul 23, 2019 at 05:32:12PM +0200, Paolo Bonzini wrote:
> On 23/07/19 14:17, Zhong, Yang wrote:
> > When I set config-wce=true or false, the below value never change
> > root@unicorn ~ # cat /sys/block/vda/cache_type
> > write back
> > root@unicorn ~ # cat /sys/block/vda/device/features
>
Similar to the mips + malta test, it boots a Linux kernel on a virt
board and verify the serial is working. Also, it relies on the serial
device set by the machine itself.
If riscv64 is a target being built, "make check-acceptance" will
automatically include this test by the use of the
> QEMU will crash with:
> Segmentation fault (core dumped)
> when negative slot number is used, ex:
> qemu-system-x86_64 -m 1G,maxmem=20G,slots=256 \
> -object memory-backend-ram,id=mem1,size=1G \
> -device pc-dimm,id=dimm1,memdev=mem1,slot=-2
>
> fix it by checking that slot
Igor Mammedov 于2019年7月24日周三 上午12:09写道：
> QEMU will crash with:
> Segmentation fault (core dumped)
> when negative slot number is used, ex:
> qemu-system-x86_64 -m 1G,maxmem=20G,slots=256 \
> -object memory-backend-ram,id=mem1,size=1G \
> -device
201 - 228 of 228 matches
Mail list logo
