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
> >
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:
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 dire
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 Open
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
> > > think
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 0
>
> 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 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 d
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 guess
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 b
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
> https://past
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 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 buff
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: Andre
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 19.07.19
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
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
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 wrot
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 4
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 d
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 deletio
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 g
From: Pavel Dovgalyuk
In record/replay mode bdrv queue is controlled by replay mechanism.
It does not allow saving or loading the snapshots
when bdrv queue is not empty. Stopping the VM is not blocked by nonempty
queue, but flushing the queue is still impossible there,
because it may cause deadlo
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 b/docs/replay
From: Pavel Dovgalyuk
This patch adds an accessor function for the name of the record/replay
log file. Adding an accessor instead of making variable global,
prevents accidental modification of this variable by other modules.
Signed-off-by: Pavel Dovgalyuk
---
include/sysemu/replay.h |2 ++
From: Pavel Dovgalyuk
This patch renames replay_get_current_step() and related variables
to make these names consistent with existing 'icount' command line
option and future record/replay hmp/qmp commands.
Signed-off-by: Pavel Dovgalyuk
---
include/sysemu/replay.h |2 +-
replay/replay-eve
From: Pavel Dovgalyuk
This patch introduces docs/devel/replay.txt which describes the rules
that should be followed to make virtual devices usable in record/replay mode.
Signed-off-by: Pavel Dovgalyuk
--
v9: fixed external virtual clock description (reported by Artem Pisarenko)
---
docs/deve
From: Pavel Dovgalyuk
After recent updates block devices cannot be closed on qemu exit.
This happens due to the block request polling when replay is not finished.
Therefore now we stop execution recording before closing the block devices.
Signed-off-by: Pavel Dovgalyuk
---
replay/replay.c |
From: Pavel Dovgalyuk
Replay is capable of recording normal BH events, but sometimes
there are single use callbacks scheduled with aio_bh_schedule_oneshot
function. This patch enables recording and replaying such callbacks.
Block layer uses these events for calling the completion function.
Replay
From: Pavel Dovgalyuk
Most of IO instructions can be executed only at the end of the block in
icount mode. Therefore translator can set cpu_can_io flag when translating
the last instruction.
But when the blocks are chained, then this flag is not reset and may
remain set at the beginning of the ne
From: Pavel Dovgalyuk
icount-based record/replay uses qemu_clock_deadline_ns_all to measure
the period until vCPU may be interrupted.
This function takes in account the virtual timers, because they belong
to the virtual devices that may generate interrupt request or affect
the virtual machine sta
From: Pavel Dovgalyuk
This patch removes refactoring artifacts from the replay/replay-time.c
Signed-off-by: Pavel Dovgalyuk
---
replay/replay-time.c | 36
1 file changed, 16 insertions(+), 20 deletions(-)
diff --git a/replay/replay-time.c b/replay/replay
On 24.07.19 10:25, Andrey Shinkevich wrote:
> 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
Tested-by: Christian Borntraeger
FWIW, the Fixes tag should b
Ivan Ren wrote:
> When we 'migrate_cancel' a multifd migration, live_migration thread may
> hung forever at some points, because of multifd_send_thread has already
> exit for socket error:
> 1. multifd_send_pages may hung at qemu_sem_wait(&multifd_send_state->
>channels_ready)
> 2. multifd_sen
On 23/07/19 21:06, Stefan Hajnoczi wrote:
> The tests/test-bdrv-drain /bdrv-drain/iothread/drain test case does the
> following:
>
> 1. The preadv coroutine calls aio_bh_schedule_oneshot() and then yields.
> 2. The one-shot BH executes in another AioContext. All it does is call
>aio_co_wakeup
On Wed, Jul 24, 2019 at 03:28:22AM -0400, Pankaj Gupta wrote:
>
>>
>> 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
On 24/07/19 08:55, Yang Zhong wrote:
>
> The SPDK code i am using is latest version, So, i feel we should
> enable WCE feature in SPDK side by default. thanks for your help!
Note that enabling the CONFIG_WCE feature has some consequences.
According to the spec:
- if the VIRTIO_BLK_F_CONFIG_WCE f
Ivan Ren wrote:
> When migrate_cancel a multifd migration, if run sequence like this:
>
> [source] [destination]
>
> multifd_send_sync_main[finish]
> multifd_recv_thread wait &p->sem_sync
> shutdown to_dst_file
>
On Wed, Jul 24, 2019 at 03:28:28AM -0500, Shivaprasad G Bhat wrote:
> 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
I don't think we want to support such ancie
On Wed, Jul 24, 2019 at 09:11:54AM +0200, Cédric Le Goater wrote:
> 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
Ivan Ren wrote:
> When we 'migrate_cancel' a multifd migration, live_migration thread may
> hung forever at some points, because of multifd_send_thread has already
> exit for socket error:
> 1. multifd_send_pages may hung at qemu_sem_wait(&multifd_send_state->
>channels_ready)
> 2. multifd_sen
>>> But.. can you connect the dots for me in how this being missing
>>> results in a BADMAGIC error??
>>
>> Some binary called by petitboot segfaults when trying to kexec an image on
>> a system with a bogus DT (generated by QEMU). I don't know exactly which one
>> as I only see the error message
On 23/07/2019 08:37, David Gibson wrote:
> On Tue, Jul 23, 2019 at 08:00:27AM +0200, Cédric Le Goater wrote:
>> On 23/07/2019 03:38, David Gibson wrote:
>>> On Mon, Jul 22, 2019 at 08:23:47PM +0200, Cédric Le Goater wrote:
Make the current "powernv" machine an abstract type and derive from it
Hi Yi, David,
On 7/24/19 6:57 AM, Liu, Yi L wrote:
>> From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf
>> Of David Gibson
>> Sent: Tuesday, July 23, 2019 11:58 AM
>> To: Liu, Yi L
>> Subject: Re: [RFC v1 05/18] vfio/pci: add pasid alloc/free implementation
>>
>> On Mon
In case somebody is interested, two of the "auto" iotests are failing
on NetBSD due to non-matching output:
TESTiotest-qcow2: 069 [fail]
--- /var/tmp/qemu-test.1BMupF/tests/qemu-iotests/069.out2019-07-24
09:19:22.0 +
+++ /var/tmp/qemu-test.1BMupF/tests/qemu-iotests/069.o
On Wed, Jul 24, 2019 at 03:14:39PM +0800, Peter Xu wrote:
> 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 a
Instead of draining additional nodes in each job code, let's do it in
common block_job_drain, draining just all job's children.
BlockJobDriver.drain becomes unused, so, drop it at all.
It's also a first step to finally get rid of blockjob->blk.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
v3
21.06.2019 16:15, Vladimir Sementsov-Ogievskiy wrote:
> 19.06.2019 18:49, Max Reitz wrote:
>> On 19.06.19 11:18, Vladimir Sementsov-Ogievskiy wrote:
>>> 13.06.2019 1:09, Max Reitz wrote:
This changes iotest 204's output, because blkdebug on top of a COW node
used to make qemu-img map disr
21.06.2019 16:26, Vladimir Sementsov-Ogievskiy wrote:
> 19.06.2019 18:59, Max Reitz wrote:
>> On 19.06.19 11:31, Vladimir Sementsov-Ogievskiy wrote:
>>> 13.06.2019 1:09, Max Reitz wrote:
We have to perform an active commit whenever the top node has a parent
that has taken the WRITE permis
21.06.2019 16:39, Vladimir Sementsov-Ogievskiy wrote:
> 13.06.2019 1:09, Max Reitz wrote:
>> With bdrv_filtered_rw_bs(), we can easily handle this default filter
>> behavior in bdrv_co_block_status().
>>
>> blkdebug wants to have an additional assertion, so it keeps its own
>> implementation, excep
- Just simplify patch 2 from Ivan
- Add patch 3 to cover everything.
Please review.
My plan is send the three of them for the update
Ivan Ren (3):
migration: fix migrate_cancel leads live_migration thread endless loop
migration: fix migrate_cancel leads live_migration thread hung forever
m
From: Ivan Ren
When migrate_cancel a multifd migration, if run sequence like this:
[source] [destination]
multifd_send_sync_main[finish]
multifd_recv_thread wait &p->sem_sync
shutdown to_dst_file
From: Ivan Ren
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 get live_migration 1
From: Ivan Ren
When we 'migrate_cancel' a multifd migration, live_migration thread may
hung forever at some points, because of multifd_send_thread has already
exit for socket error:
1. multifd_send_pages may hung at qemu_sem_wait(&multifd_send_state->
channels_ready)
2. multifd_send_sync_main
We add a bool to indicate that.
Signed-off-by: Juan Quintela
---
migration/ram.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/migration/ram.c b/migration/ram.c
index 87bb7da8e2..eb6716710e 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -677,6 +677,8 @@ typedef struct {
On Wed, Jul 24, 2019 at 05:39:22AM -0400, Michael S. Tsirkin wrote:
> On Wed, Jul 24, 2019 at 03:14:39PM +0800, Peter Xu wrote:
> > 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 Br
> >
> >>
> >> 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
>
> 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
Add 4.2 machine types for arm/i440fx/q35/s390x/spapr.
For i440fx and q35, unversioned cpu models are still translated
to -v1, as 0788a56bd1ae ("i386: Make unversioned CPU models be
aliases") states this should only transition to the latest cpu
model version in 4.3 (or later).
Signed-off-by: Corne
Cc'ing the qtest maintainers and Xiao since I have no clue about this test.
On 7/23/19 7:20 PM, no-re...@patchew.org wrote:
> Patchew URL:
> https://patchew.org/QEMU/20190723141528.18023-1-phi...@redhat.com/
> ---
> PASS 4 pxe-test /x86_64/pxe/ipv4/q35/virtio-net-pci
> MALLOC_PERTURB_=${MALLOC_PE
On 7/23/19 9:09 PM, Stefan Hajnoczi wrote:
> On Tue, Jul 23, 2019 at 8:06 PM Stefan Hajnoczi wrote:
>> So if co causes ctx to be freed then we're in trouble. Fix this problem
>> by holding a reference to ctx.
>
> For QEMU 4.2. I'm not aware of a way to trigger this bug in QEMU
> proper. This f
* Juan Quintela (quint...@redhat.com) wrote:
> From: Ivan Ren
>
> 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) [w
* Juan Quintela (quint...@redhat.com) wrote:
> From: Ivan Ren
>
> When we 'migrate_cancel' a multifd migration, live_migration thread may
> hung forever at some points, because of multifd_send_thread has already
> exit for socket error:
> 1. multifd_send_pages may hung at qemu_sem_wait(&multifd_s
Make the current "powernv" machine an abstract type and derive from it
new machines with specific CPU models: power8 and power9.
The "powernv" machine is now an alias on the "powernv9" machine.
Signed-off-by: Cédric Le Goater
---
Changes since v1:
- removed power8e and power8nvl machines
-
* Juan Quintela (quint...@redhat.com) wrote:
> We add a bool to indicate that.
>
> Signed-off-by: Juan Quintela
OK, similar to send.
Reviewed-by: Dr. David Alan Gilbert
> ---
> migration/ram.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/migration/ram.c b/migration/ram
* Juan Quintela (quint...@redhat.com) wrote:
> From: Ivan Ren
>
> When migrate_cancel a multifd migration, if run sequence like this:
>
> [source] [destination]
>
> multifd_send_sync_main[finish]
> multifd_recv_thread wait
15.07.2019 22:48, John Snow wrote:
>
>
> On 7/8/19 6:04 PM, John Snow wrote:
>> Hi, this is a proposal based off of Vladimir's patchset:
>> [Qemu-devel] [PATCH 0/4] qapi: block-dirty-bitmap-remove transaction action
>>
>> ===
>> V3:
>> ===
>>
>> 001/3:[] [--] 'blockdev: reduce aio_context loc
On 23/07/19 12:01, Paolo Bonzini wrote:
> The number of buses is determined by the firmware, not by QEMU, so
> fw_cfg would not be the right interface. In fact (as I have just
> learnt) lastbus is an x86-specific option that overrides the last bus
> returned by SeaBIOS's handle_1ab101.
>
> So the
* Pavel Dovgalyuk (dovga...@ispras.ru) wrote:
> Hello!
>
> > From: Dr. David Alan Gilbert (git) [mailto:dgilb...@redhat.com]
> > The reset notifiers kept a 'last' counter to notice jumps;
> > now that we've remove the notifier we don't need to keep 'last'.
> > replay used to save/restore 'last' (p
On 24/07/2019 12.46, Philippe Mathieu-Daudé wrote:
> Cc'ing the qtest maintainers and Xiao since I have no clue about this test.
>
> On 7/23/19 7:20 PM, no-re...@patchew.org wrote:
>> Patchew URL:
>> https://patchew.org/QEMU/20190723141528.18023-1-phi...@redhat.com/
>> ---
>> PASS 4 pxe-test /x86
In order to reduce the memory footprint when PVH kernel and initrd
are used, we map them into memory instead of reading them.
In this way we can share them between multiple instances of QEMU.
v3:
- Added patch 1 to handle memory-mapped ELFs in rom_add_elf_program() [Paolo]
- Patch 2:
~ passed th
This patch allows handling an ELF memory-mapped, taking care
the reference count of the GMappedFile* passed through
rom_add_elf_program().
In this case, the 'data' pointer is not heap-allocated, so
we cannot free it.
Suggested-by: Paolo Bonzini
Signed-off-by: Stefano Garzarella
---
hw/core/load
In order to reduce the memory footprint we map into memory
the ELF to load using g_mapped_file_new_from_fd() instead of
reading each sections. In this way we can share the ELF pages
between multiple instances of QEMU.
Suggested-by: Dr. David Alan Gilbert
Suggested-by: Paolo Bonzini
Signed-off-by
In order to reduce the memory footprint we map into memory
the initrd using g_mapped_file_new() instead of reading it.
In this way we can share the initrd pages between multiple
instances of QEMU.
Suggested-by: Paolo Bonzini
Signed-off-by: Stefano Garzarella
---
v3:
- renamed 'GMappedFile *gmf
> If we just post it there, we get out of the wait (that bit is ok), but
> then we go back to the beggining of the bucle, we (probably) got one
> error on the qui_channel_read_all_eof(), and we go back to
> multifd_recv_terminate_threads(), or wait there.
>
> I think that it is better to *also* set
* Yan Zhao (yan.y.z...@intel.com) wrote:
> On Fri, Jul 19, 2019 at 02:32:33AM +0800, Kirti Wankhede wrote:
> >
> > On 7/12/2019 6:02 AM, Yan Zhao wrote:
> > > On Fri, Jul 12, 2019 at 03:08:31AM +0800, Kirti Wankhede wrote:
> > >>
> > >>
> > >> On 7/11/2019 9:53 PM, Dr. David Alan Gilbert wrote:
>
On Tue, Jul 23, 2019 at 08:06:23PM +0100, Stefan Hajnoczi wrote:
> The tests/test-bdrv-drain /bdrv-drain/iothread/drain test case does the
> following:
>
> 1. The preadv coroutine calls aio_bh_schedule_oneshot() and then yields.
> 2. The one-shot BH executes in another AioContext. All it does is
On 24/07/19 13:25, Thomas Huth wrote:
> Was the test running on a machine with heavy load? In that case, the
> test thread just might have been suspended for too long...
> We might need to set the "wiggle" parameter there to a higher value
> (like 5 seconds maybe)?
> Or maybe we should fence the ch
Richard Henderson writes:
> This is less complex than the LPAE case, but still we now avoid the
> flush in case it is only the PROCID field that is changing.
>
> Signed-off-by: Richard Henderson
Reviewed-by: Alex Bennée
> ---
> target/arm/helper.c | 34 --
>
Richard Henderson writes:
> The VMID is the ASID for the 2nd stage page lookup.
>
> Signed-off-by: Richard Henderson
Reviewed-by: Alex Bennée
> ---
> target/arm/helper.c | 26 --
> 1 file changed, 16 insertions(+), 10 deletions(-)
>
> diff --git a/target/arm/helper.
On 24/07/19 13:25, Stefano Garzarella wrote:
> @@ -582,7 +596,7 @@ static int glue(load_elf, SZ)(const char *name, int fd,
> *highaddr = (uint64_t)(elf_sword)high;
> return total_size;
Isn't the success case missing a g_mapped_file_unref? It has to be done
unconditionally since now
From: "Dr. David Alan Gilbert"
The reset notifiers are unreliable and recalculating the offsets
after boot causes problems with migration in cases where explicit
base times are set on the destination.
Signed-off-by: Dr. David Alan Gilbert
---
hw/timer/mc146818rtc.c | 19 ---
1
From: "Dr. David Alan Gilbert"
Timers have a mechanism for detecting host clock jumps; this relied
on noticing if the time had gone backwards or if it had gone forward
more than 60s since we last read it. This had assumed that we regularly
read the time, which isn't true any more - we might not
From: "Dr. David Alan Gilbert"
Now we're not using the 'last' field in the timer, remove it from
replay.
Bump the version number of the replay structure since we've
removed the field.
Signed-off-by: Dr. David Alan Gilbert
---
replay/replay-snapshot.c | 7 ++-
1 file changed, 2 insertions(
From: "Dr. David Alan Gilbert"
Remove the reset notifer from the core qemu-timer code.
The only user was mc146818 and we've just remove it's use.
Signed-off-by: Dr. David Alan Gilbert
---
include/qemu/timer.h | 22 --
util/qemu-timer.c| 21 +
2 files
From: "Dr. David Alan Gilbert"
The reset notifiers kept a 'last' counter to notice jumps;
now that we've remove the notifier we don't need to keep 'last'.
Signed-off-by: Dr. David Alan Gilbert
---
include/qemu/timer.h | 13 -
util/qemu-timer.c| 22 +-
2 file
On 7/22/2019 7:50 PM, Paolo Bonzini wrote:
On 22/07/19 04:59, Jing Liu wrote:
On 7/19/2019 4:10 PM, Paolo Bonzini wrote:
On 19/07/19 09:20, Jing Liu wrote:
Then CPUID[7,0].EAX is set automatically to 0 or 1 depending on whether
BF16 is enabled or not.
Could I ask why don't we directly c
* Wei Yang (richardw.y...@linux.intel.com) wrote:
> On Tue, Jul 23, 2019 at 05:47:03PM +0100, Dr. David Alan Gilbert wrote:
> >* Wei Yang (richardw.y...@linux.intel.com) wrote:
> >> After cleanup, it would be clear to audience there are two cases
> >> ram_load:
> >>
> >> * precopy
> >> * postc
On 24/07/19 14:05, Jing Liu wrote:
>
> Thanks very much. So would you like me to update the patch with v2 now?
Yes, please.
Paolo
Reviewed-by: Pavel Dovgalyuk
Pavel Dovgalyuk
> -Original Message-
> From: Dr. David Alan Gilbert (git) [mailto:dgilb...@redhat.com]
> Sent: Wednesday, July 24, 2019 2:58 PM
> To: qemu-devel@nongnu.org; pbonz...@redhat.com; pavel.dovga...@ispras.ru
> Subject: [for 4.2 PATCH v2 3/4] repla
On Wed, Jul 24, 2019 at 01:50:58PM +0200, Paolo Bonzini wrote:
> On 24/07/19 13:25, Stefano Garzarella wrote:
> > @@ -582,7 +596,7 @@ static int glue(load_elf, SZ)(const char *name, int fd,
> > *highaddr = (uint64_t)(elf_sword)high;
> > return total_size;
>
> Isn't the success case m
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.
Exit with error on older kernels.
Signed-off-by: Shivaprasad G Bhat
---
v5: https://lists.gnu.org/archive/html/qemu-devel/2019-07/msg05301.html
Changes
Hi Drew,
On 6/26/19 3:26 PM, Andrew Jones wrote:
> On Wed, Jun 26, 2019 at 09:43:09AM +0200, Auger Eric wrote:
>> Hi Drew,
>>
>> On 6/21/19 6:34 PM, Andrew Jones wrote:
>>> Add support for the query-cpu-model-expansion QMP command to Arm. We
>>> do this selectively, only exposing CPU properties wh
Hi Drew,
On 6/25/19 3:34 PM, Andrew Jones wrote:
> On Tue, Jun 25, 2019 at 11:35:12AM +0200, Auger Eric wrote:
>> Hi Drew,
>>
>> On 6/21/19 6:34 PM, Andrew Jones wrote:
>>> If -cpu ,aarch64=off is used then KVM must also be used, and it
>>> and the host must support running the vcpu in 32-bit mode
On 7/24/19 7:12 AM, Vladimir Sementsov-Ogievskiy wrote:
> 15.07.2019 22:48, John Snow wrote:
>>
>>
>> On 7/8/19 6:04 PM, John Snow wrote:
>>> Hi, this is a proposal based off of Vladimir's patchset:
>>> [Qemu-devel] [PATCH 0/4] qapi: block-dirty-bitmap-remove transaction action
>>>
>>> ===
>>> V
On Wed, Jul 24, 2019 at 10:57:30AM +0200, Paolo Bonzini wrote:
> On 24/07/19 08:55, Yang Zhong wrote:
> >
> > The SPDK code i am using is latest version, So, i feel we should
> > enable WCE feature in SPDK side by default. thanks for your help!
>
> Note that enabling the CONFIG_WCE feature has so
Hi,
On 6/26/19 3:26 PM, Andrew Jones wrote:
> On Wed, Jun 26, 2019 at 09:43:09AM +0200, Auger Eric wrote:
>> Hi Drew,
>>
>> On 6/21/19 6:34 PM, Andrew Jones wrote:
>>> Add support for the query-cpu-model-expansion QMP command to Arm. We
>>> do this selectively, only exposing CPU properties which re
I have problem in xen with qemu xhci with usbredir backend.
Windows bluetooth (BCM20703) driver does not work without proposed patch.
Interrupt EP does not work as expected and described in USB spec.
usb_20.pdf/5.7.3 Interrupt Transfer Packet Size Constraint:
An endpoint must always transmit
1 - 100 of 230 matches
Mail list logo
