erard/qemu-dm.git
tags/pull-xen-20190114
for you to fetch changes up to c6025bd197d0dbcc5067553fd12538d8b29383c2:
xen-block: avoid repeated memory allocation (2019-01-14 13:45:40 +)
Xen queue
* Xen PV backend 'qdevificati
From: Paul Durrant
I have made many significant contributions to the Xen code in QEMU,
particularly the recent patches introducing a new PV device framework.
I intend to make further significant contributions, porting other PV back-
ends to the new framework with the intent of eventually removing
在 2019/1/14 下午8:53, Markus Armbruster 写道:
Fei Li writes:
在 2019/1/9 上午12:18, fei 写道:
在 2019年1月8日，01:50，Markus Armbruster 写道：
Fei Li writes:
For iothread_complete: utilize the existed errp to propagate the
error and do the corresponding cleanup to replace the temporary
&error_abort.
Fo
From: Paul Durrant
This patch adds new XenDevice-s: 'xen-disk' and 'xen-cdrom', both derived
from a common 'xen-block' parent type. These will eventually replace the
'xen_disk' (note the underscore rather than hyphen) legacy PV backend but
it is illustrative to build up the implementation increme
From: Paul Durrant
The legacy PV backend infrastructure provides functions to bind, unbind
and send notifications to event channnels. Similar functionality will be
required by XenDevice implementations so this patch adds the necessary
support.
Signed-off-by: Paul Durrant
Reviewed-by: Anthony Pe
v2:
* Added qemu-iotests test case [Kevin, Alberto]
* Use atomic operations instead of AioContext lock [Paolo]
This patch series fixes a segfault upon device_del when virtio-scsi is used
with iothreads.
Stefan Hajnoczi (2):
throttle-groups: fix restart coroutine iothread race
iotests: add 2
在 2019/1/14 下午8:36, Markus Armbruster 写道:
Fei Li writes:
Just to make sure about how to do the cleanup. I notice that in
device_set_realized(),
the current code does not call "dc->unrealize(dev, NULL);" when dc->realize()
fails.
Sorry that I am still uncertain.. I guess the code below I pa
On Fri, Jan 11, 2019 at 03:14:08PM +0100, Alberto Garcia wrote:
> On Fri 11 Jan 2019 02:24:16 PM CET, Kevin Wolf wrote:
> >> >> The following QMP command leads to a crash when iothreads are used:
> >> >>
> >> >> { 'execute': 'device_del', 'arguments': {'id': 'data'} }
> >> >
> >> > How did you re
Hot-unplug a scsi-hd using an iothread. The previous patch fixes a
segfault in this scenario.
This patch adds a regression test.
Suggested-by: Alberto Garcia
Suggested-by: Kevin Wolf
Signed-off-by: Stefan Hajnoczi
---
v2:
* Added qemu-iotests test case [Kevin, Alberto]
---
tests/qemu-iotest
Cc'ing qemu-trivial
On 1/14/19 2:10 PM, Fei Li wrote:
> From: Fei Li
>
> Let's supplement the msi_uninit() when failing to realize
> the pci edu device.
>
> Reported-by: Markus Armbruster
> Signed-off-by: Fei Li
> Reviewed-by: Marcel Apfelbaum
> Reviewed-by: Philippe Mathieu-Daudé
> Reviewe
On 30/11/2018 5:47 PM, Anton Nefedov wrote:
> qmp query-blockstats provides stats info for write/read/flush ops.
>
> Patches 1-7 implement the similar for discard (unmap) command for scsi
> and ide disks.
> Discard stat "unmap_ops / unmap_bytes" is supposed to account the ops that
> have completed
On 14.01.19 14:10, Max Reitz wrote:
> On 29.12.18 13:20, Vladimir Sementsov-Ogievskiy wrote:
>> Simplify backup_incremental_init_copy_bitmap using the function
>> bdrv_dirty_bitmap_next_dirty_area.
>>
>> Note: move to job->len instead of bitmap size: it should not matter but
>> less code.
>>
>> Sig
Header files requiring PixelFormat already include "ui/qemu-pixman.h".
To clean "qemu/typedefs.h", move the declaration to "ui/qemu-pixman.h"
(removing the forward declaration).
Suggested-by: Paolo Bonzini
Signed-off-by: Philippe Mathieu-Daudé
---
include/qemu/typedefs.h | 1 -
include/ui/co
On 29.12.18 13:20, Vladimir Sementsov-Ogievskiy wrote:
> Simplify backup_incremental_init_copy_bitmap using the function
> bdrv_dirty_bitmap_next_dirty_area.
>
> Note: move to job->len instead of bitmap size: it should not matter but
> less code.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
>
There are only three include files requiring these typedefs, let them
include "hw/nvram/fw_cfg.h" directly to simplify "qemu/typedefs.h".
To clean "qemu/typedefs.h", move the declarations to "hw/nvram/fw_cfg.h".
Reorder two function declarations to avoid forward typedef declarations.
Signed-off-b
From: Fei Li
Let's supplement the msi_uninit() when failing to realize
the pci edu device.
Reported-by: Markus Armbruster
Signed-off-by: Fei Li
Reviewed-by: Marcel Apfelbaum
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Peter Xu
---
hw/misc/edu.c | 1 +
1 file changed, 1 insertion(+)
d
Header files requiring MouseTransformInfo already include "ui/console.h".
To clean "qemu/typedefs.h", move the declaration to "ui/console.h"
(removing the forward declaration).
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/devices.h| 1 +
include/qemu/typedefs.h | 1 -
include/ui/con
Hi,
Since this file became a hot topic [*], I took previous cleanups
from last year and continue to clean it.
v2:
- reorder fw_cfg (Laszlo), remove forward declarations
- move PixelFormat to "ui/qemu-pixman.h" (Paolo)
- reword comment (Thomas)
Regards,
Phil.
[*] "HACKING: Clarify the paragraph
Philippe Mathieu-Daudé writes:
> On 1/13/19 10:41 AM, Leonid Bloch wrote:
>> On 1/11/19 9:14 PM, Markus Armbruster wrote:
>>> We define 54 macros for the powers of two >= 1024. We use six, in six
>>> macro definitions. Four of them could just as well use the common MiB
>>> macro, so do that. T
On 1/14/19 9:59 AM, Thomas Huth wrote:
> On 2019-01-11 15:08, Philippe Mathieu-Daudé wrote:
>> MouseTransformInfo is only used in "ui/console.h", there is no
>> need to expose it via "qemu/typedefs.h".
>
> You also touch devices.h here ... that should be mentioned, too?
It depends whichever of th
11.01.2019, 21:25, "Dr. David Alan Gilbert" :
> * Yury Kotov (yury-ko...@yandex-team.ru) wrote:
>> 10.01.2019, 23:14, "Dr. David Alan Gilbert" :
>> > * Yury Kotov (yury-ko...@yandex-team.ru) wrote:
>> >> RAM migration has a RAMBlock validation stage (flag
>> RAM_SAVE_FLAG_MEM_SIZE).
>> >> In
On 2019-01-14 13:52, Peter Maydell wrote:
> On Mon, 14 Jan 2019 at 10:02, Thomas Huth wrote:
>>
>> Hi Peter,
>>
>> the following changes since commit 27df21ca3886fff4dd3d70e515517667963a52f1:
>>
>> Merge remote-tracking branch
>> 'remotes/kraxel/tags/misc-20190111-pull-request' into staging (2
Fei Li writes:
> 在 2019/1/9 上午12:18, fei 写道:
>>
>>> 在 2019年1月8日，01:50，Markus Armbruster 写道：
>>>
>>> Fei Li writes:
>>>
For iothread_complete: utilize the existed errp to propagate the
error and do the corresponding cleanup to replace the temporary
&error_abort.
For qemu
We want to build our s390-ccw bios with -march=z900 so that it also
works with the oldest s390x CPU that we support with TCG. However,
Clang on s390x does not support -march=z900 anymore, so we can not
use this compiler to build the s390-ccw bios. Thus add a proper test
to the configure script to s
On Mon, 14 Jan 2019 at 10:02, Thomas Huth wrote:
>
> Hi Peter,
>
> the following changes since commit 27df21ca3886fff4dd3d70e515517667963a52f1:
>
> Merge remote-tracking branch
> 'remotes/kraxel/tags/misc-20190111-pull-request' into staging (2019-01-11
> 16:45:59 +)
>
> are available in t
在 2019/1/14 下午6:40, Philippe Mathieu-Daudé 写道:
On 1/14/19 8:18 AM, Peter Xu wrote:
On Mon, Jan 14, 2019 at 08:02:23AM +0100, Markus Armbruster wrote:
Peter Xu writes:
On Sun, Jan 13, 2019 at 10:36:41PM +0800, Fei Li wrote:
From: Fei Li
Let's supplement the msi_uninit() when failing to r
On 2019-01-14 13:37, Peter Maydell wrote:
> On Mon, 14 Jan 2019 at 12:24, Thomas Huth wrote:
>>
>> We want to build our s390-ccw bios with -march=z900 so that it also
>> works with the oldest s390x CPU that we support with TCG. However,
>> Clang on s390x does not support -march=z900 anymore, so we
On 1/14/19 1:35 PM, Gerd Hoffmann wrote:
> On Mon, Jan 14, 2019 at 11:24:14AM +0100, Philippe Mathieu-Daudé wrote:
>> On 1/11/19 6:32 PM, Paolo Bonzini wrote:
>>> On 11/01/19 15:08, Philippe Mathieu-Daudé wrote:
PixelFormat is used by "ui/console.h" and by "ui/qemu-pixman.h".
>>>
>>> ui/consol
On Fri, 11 Jan 2019 at 18:06, Palmer Dabbelt wrote:
>
> The following changes since commit 147923b1a901a0370f83a0f4c58ec1baffef22f0:
>
> Merge remote-tracking branch
> 'remotes/kraxel/tags/usb-20190108-pull-request' into staging (2019-01-08
> 16:07:32 +)
>
> are available in the Git reposi
On Fri, Jan 11, 2019 at 09:33:40AM -0600, Eric Blake wrote:
> On 1/11/19 3:31 AM, Gerd Hoffmann wrote:
> > ---
> > hw/vfio/display.c | 16
> > 1 file changed, 16 insertions(+)
> >
> > diff --git a/hw/vfio/display.c b/hw/vfio/display.c
> > index a3a710b3ee..96b5474243 100644
> > -
On Mon, 14 Jan 2019 at 12:24, Thomas Huth wrote:
>
> We want to build our s390-ccw bios with -march=z900 so that it also
> works with the oldest s390x CPU that we support with TCG. However,
> Clang on s390x does not support -march=z900 anymore, so we can not
> use this compiler to build the s390-c
On Mon, Jan 14, 2019 at 11:24:14AM +0100, Philippe Mathieu-Daudé wrote:
> On 1/11/19 6:32 PM, Paolo Bonzini wrote:
> > On 11/01/19 15:08, Philippe Mathieu-Daudé wrote:
> >> PixelFormat is used by "ui/console.h" and by "ui/qemu-pixman.h".
> >
> > ui/console.h already includes ui/qemu-pixman.h, just
Fei Li writes:
> Just to make sure about how to do the cleanup. I notice that in
> device_set_realized(),
> the current code does not call "dc->unrealize(dev, NULL);" when dc->realize()
> fails.
>
> if (dc->realize) {
> dc->realize(dev, &local_err);
> }
>
> i
On 1/14/19 1:14 PM, Max Reitz wrote:
> On 13.12.18 17:27, Laurent Vivier wrote:
>> Convert all the remaining uses of DPRINTF() in the directory block.
>>
>> Compiled for all target but only tested with "make check"
>>
>> v2: replace "sd_" prefix by "sheepdog_"
>> remove the dot at the end of th
We want to build our s390-ccw bios with -march=z900 so that it also
works with the oldest s390x CPU that we support with TCG. However,
Clang on s390x does not support -march=z900 anymore, so we can not
use this compiler to build the s390-ccw bios. Thus add a proper test
to the configure script to s
On Fri, 11 Jan 2019 22:02:50 +0100
Greg Kurz wrote:
> From: Michael Roth
>
> Certain devices types, like memory/CPU, are now being handled using a
> hotplug interface provided by a top-level MachineClass. Hotpluggable
> host bridges are another such device where it makes sense to use a
> machin
12.01.2019 20:57, Eric Blake wrote:
> I got tired of debugging whether a server was advertising the
> correct things during negotiation by inspecting the trace
> logs of qemu-io as client - not to mention that without SOME
> sort of client tracing particular commands, we can't easily
> regression t
On 1/14/19 1:12 PM, Thomas Huth wrote:
> Clang v7.0.1 does not like the __int128 variable type for inline
> assembly on s390x:
>
> In file included from fpu/softfloat.c:97:
> include/fpu/softfloat-macros.h:647:9: error: inline asm error:
> This value type register class is not natively supported!
On 13.12.18 17:27, Laurent Vivier wrote:
> Convert all the remaining uses of DPRINTF() in the directory block.
>
> Compiled for all target but only tested with "make check"
>
> v2: replace "sd_" prefix by "sheepdog_"
> remove the dot at the end of the text strings
> use %zu with size_t
>
Clang v7.0.1 does not like the __int128 variable type for inline
assembly on s390x:
In file included from fpu/softfloat.c:97:
include/fpu/softfloat-macros.h:647:9: error: inline asm error:
This value type register class is not natively supported!
asm("dlgr %0, %1" : "+r"(n) : "r"(d));
On Fri, Jan 11, 2019 at 06:16:45PM +, Peter Maydell wrote:
> On Fri, 11 Jan 2019 at 18:13, Anthony PERARD
> wrote:
> >
> > On Fri, Jan 11, 2019 at 06:09:41PM +, Anthony PERARD wrote:
> > > Patch "xen: add event channel interface for XenDevice-s" makes use of
> > > the type xenevtchn_port_
Patch proposed at
https://lists.gnu.org/archive/html/qemu-devel/2019-01/msg02774.html
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1795100
Title:
VNC unix-domain socket unlink()ed prematurely
St
On Fri, Jan 04, 2019 at 03:40:34PM +, Stefan Hajnoczi wrote:
> On Thu, Jan 03, 2019 at 03:14:55PM +0100, Christophe Fergeau wrote:
> > Hey,
> >
> > On Thu, Jan 03, 2019 at 10:54:25AM +, Stefan Hajnoczi wrote:
> > > On Fri, Dec 14, 2018 at 11:56:42AM +0100, Christophe Fergeau wrote:
> > > >
Include the cluster number in the hash we use to look
up TBs. This is important because a TB that is valid
for one cluster at a given physical address and set
of CPU flags is not necessarily valid for another:
the two clusters may have different views of physical
memory, or may have different CPU f
For TCG we want to distinguish which cluster a CPU is in, and
we need to do it quickly. Cache the cluster index in the CPUState
struct, by having the cluster object set cpu->cluster_index for
each CPU child when it is realized.
This means that board/SoC code must add all CPUs to the cluster
before
Changes v1->v2:
just fixing a bug in patch 3 that meant we were
accidentally never reusing TBs. Patch 3 is the only
one that needs review.
Original cover letter included below for context.
thanks
-- PMM
Currently, TCG implicitly assumes that all CPUs are alike,
because we have a single cache of
Now we're keeping the cluster index in the CPUState, we don't
need to jump through hoops in gdb_get_cpu_pid() to find the
associated cluster object.
Signed-off-by: Peter Maydell
Reviewed-by: Luc Michel
---
gdbstub.c | 48 +---
1 file changed, 5 insert
Currently the cluster implementation doesn't have any constraints
on the ordering of realizing the TYPE_CPU_CLUSTER and populating it
with child objects. We want to impose a constraint that realize
must happen only after all the child objects are added, so move
the realize of rpu_cluster. (The apu_
On Mon, 14 Jan 2019 at 01:08, Aleksandar Markovic
wrote:
> I do understand the definition of cluster_index in the sense
> of this series. However, it looks to me that the term
> "cluster" is generally overused in areas where we work.
> This may lead to some confusion for future developers, and
> l
Am 14.01.2019 um 11:51 hat Dr. David Alan Gilbert geschrieben:
> * Michael Tokarev (m...@tls.msk.ru) wrote:
> > $ qemu-system-x86_64 -monitor stdio -hda foo.img
> > QEMU 3.1.0 monitor - type 'help' for more information
> > (qemu) stop
> > (qemu) migrate "exec:cat >/dev/null"
> > (qemu) migrate "exe
On 13.12.18 17:27, Laurent Vivier wrote:
> Signed-off-by: Laurent Vivier
> Reviewed-by: Philippe Mathieu-Daudé
> ---
>
> Notes:
> v2: replace "sd_" prefix by "sheepdog_"
> remove the dot at the end of the text strings
>
> block/sheepdog.c | 47 +---
> From: Kevin Wolf [mailto:kw...@redhat.com]
> Am 14.01.2019 um 12:10 hat Pavel Dovgalyuk geschrieben:
> > > From: Kevin Wolf [mailto:kw...@redhat.com]
> > > Am 09.01.2019 um 13:13 hat Pavel Dovgalyuk geschrieben:
> > > > Replay is capable of recording normal BH events, but sometimes
> > > > there
On Sat, 12 Jan 2019 17:02:24 +0200
Marcel Apfelbaum wrote:
> Do not initialize structs with {0} since some
> CLANG versions do not support it.
>
> Use memset instead.
Can't you use {} instead? (See, for example, commit ebf2a499a5c).
>
> Signed-off-by: Marcel Apfelbaum
> ---
> contrib/rdmacm
On Sat, 12 Jan 2019 17:02:22 +0200
Marcel Apfelbaum wrote:
> Fix Commit a5d2f6f877 (contrib/rdmacm-mux: Add implementation
>of RDMA User MAD multiplexer).
>
> The above commit introduces a new contrib target, adding a global dependency
> to libumad library in case pvrdma
On Fri, 11 Jan 2019 at 14:38, Gerd Hoffmann wrote:
>
> The following changes since commit a311f891abf3833c1e4c5a62a6e5b0f1b81f22c3:
>
> Merge remote-tracking branch
> 'remotes/vivier2/tags/linux-user-for-4.0-pull-request' into staging
> (2019-01-10 17:49:54 +)
>
> are available in the git
The qio_channel_socket_close method for was mistakenly unlinking the
UNIX server socket, even if the channel was a client connection. This
was not noticed with chardevs, since they never call close, but with the
VNC server, this caused the VNC server socket to be deleted after the
first client quit
On 1/14/19 12:15 PM, Max Reitz wrote:
> On 13.12.18 17:27, Laurent Vivier wrote:
>> Signed-off-by: Laurent Vivier
>> Reviewed-by: Richard W.M. Jones
>> Reviewed-by: Philippe Mathieu-Daudé
>> ---
>>
>> Notes:
>> v2: use %zu with size_t
>> change an uint64_t to int64_t to match % PRIi6
Am 14.01.2019 um 12:10 hat Pavel Dovgalyuk geschrieben:
> > From: Kevin Wolf [mailto:kw...@redhat.com]
> > Am 09.01.2019 um 13:13 hat Pavel Dovgalyuk geschrieben:
> > > Replay is capable of recording normal BH events, but sometimes
> > > there are single use callbacks scheduled with aio_bh_schedule
The idea is that ALLOCATE requests may overlap with other requests.
Reuse the existing block layer infrastructure for serialising requests.
Use the following approach:
- mark ALLOCATE also SERIALISING, so subsequent requests to the area wait
- ALLOCATE request itself must never wait if another
Signed-off-by: Anton Nefedov
Reviewed-by: Alberto Garcia
Reviewed-by: Vladimir Sementsov-Ogievskiy
---
block/quorum.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/block/quorum.c b/block/quorum.c
index 16b3c8067c..d21a6a3b8e 100644
--- a/block/quorum.c
new in v12:
- patch 9: pre-write overlap check added
v11: http://lists.nongnu.org/archive/html/qemu-devel/2018-12/msg04342.html
- patch 4, 9: fixed commentary format
- patch 4: removed one hunk with a dead check
- patch 5: added commentary to BDRV_REQ_ALLOCATE definition
- new a
Current write_zeroes implementation is good enough to satisfy this flag too
Signed-off-by: Anton Nefedov
Reviewed-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Alberto Garcia
---
block/file-posix.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/block/file-posix.c b/
Hi Li,
On 1/11/19 3:08 AM, Li Qiang wrote:
> When it is zero, it causes segv. Backtrack:
> Thread 5 "qemu-system-x86" received signal SIGSEGV, Segmentation fault.
Can you add the relevant part of the command line you used here?
> [Switching to Thread 0x7fffc6c17700 (LWP 51808)]
> 0x55acb
Hi,
On 1/12/19 3:30 AM, Heyi Guo wrote:
> Hi folks,
>
> I have some questions about vfio_msix_vector_do_use() in hw/vfio/pci.c,
> could you help to explain?
>
> We can see that when guest tries to enable one specific MSIX vector by
> unmasking MSIX Vector Control, the access will be trapped and
these flags currently affect nothing without CONFIG_FALLOCATE*, so it's
not a bug, but fixing it makes possible to adjust supported zero flag
BDRV_REQ_ALLOCATE regardless of configuration.
Signed-off-by: Anton Nefedov
Reviewed-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Alberto Garcia
---
bl
COW (even empty/zero) areas require encryption too
Signed-off-by: Anton Nefedov
Reviewed-by: Eric Blake
Reviewed-by: Max Reitz
Reviewed-by: Alberto Garcia
---
tests/qemu-iotests/134 | 9 +
tests/qemu-iotests/134.out | 10 ++
2 files changed, 19 insertions(+)
diff --git a
On Thu, Jan 10, 2019 at 11:09:09PM -0800, si-wei liu wrote:
> On 01/10/2019 07:20 PM, Michael S. Tsirkin wrote:
> > On Thu, Jan 10, 2019 at 06:09:23PM -0800, si-wei liu wrote:
> > >
> > > On 01/09/2019 07:56 AM, Michael S. Tsirkin wrote:
> > > > On Mon, Jan 07, 2019 at 05:29:41PM -0500, Venu Busir
The flag is supposed to indicate that the region of the disk image has
to be sufficiently allocated so it reads as zeroes.
The call with the flag set must return -ENOTSUP if allocation cannot
be done efficiently.
This has to be made sure of by both
- the drivers that support the flag
- and the
Support the flag if the underlying BDS supports it
Signed-off-by: Anton Nefedov
Reviewed-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Alberto Garcia
---
block/blkdebug.c | 2 +-
block/blkverify.c| 2 +-
block/copy-on-read.c | 4 ++--
block/mirror.c | 2 +-
block/raw-format.c |
If COW areas of the newly allocated clusters are zeroes on the backing image,
efficient bdrv_write_zeroes(flags=BDRV_REQ_ALLOCATE) can be used on the whole
cluster instead of writing explicit zero buffers later in perform_cow().
iotest 060:
write to the discarded cluster does not trigger COW anymo
Signed-off-by: Anton Nefedov
Reviewed-by: Alberto Garcia
Reviewed-by: Vladimir Sementsov-Ogievskiy
---
block/blkverify.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/block/blkverify.c b/block/blkverify.c
index 89bf4386e3..bb52596cbb 100644
--- a/block/blkverify
Signed-off-by: Anton Nefedov
Reviewed-by: Alberto Garcia
Reviewed-by: Vladimir Sementsov-Ogievskiy
---
block/mirror.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/block/mirror.c b/block/mirror.c
index f0b211a9c8..7b5a5f13a2 100644
--- a/block/mirror.c
+++ b/block/
Am 12.01.2019 um 18:08 hat Michael Tokarev geschrieben:
> commit eeae6a596b0efc092f5101c67683053e245e6250
> Author: Kevin Wolf
> Date: Tue Oct 9 16:57:12 2018 +0200
>
> block: Update flags in bdrv_set_read_only()
>
> To fully change the read-only state of a node, we
On 1/11/19 3:08 AM, Li Qiang wrote:
> There is no need to make another reference.
>
> Signed-off-by: Li Qiang
> Reviewed-by: Max Reitz
Reviewed-by: Philippe Mathieu-Daudé
> ---
> hw/block/nvme.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/hw/block/nvme.c
On 13.12.18 17:27, Laurent Vivier wrote:
> Signed-off-by: Laurent Vivier
> Reviewed-by: Richard W.M. Jones
> Reviewed-by: Philippe Mathieu-Daudé
> ---
>
> Notes:
> v2: use %zu with size_t
> change an uint64_t to int64_t to match % PRIi64
>
> block/ssh.c| 46 +++
> From: Kevin Wolf [mailto:kw...@redhat.com]
> Am 09.01.2019 um 13:13 hat Pavel Dovgalyuk geschrieben:
> > 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 replayin
Hi Eric,
On 1/11/19 9:13 PM, Eric Blake wrote:
> When qemu dies from a signal, the python code gets a negative
> value for exitcode; but signal numbers are positive. Copy the
> pattern used in qemu-iotests/iotests.py for reporting a positive
> value.
>
> CC: qemu-triv...@nongnu.org
> Signed-off-
On Fri, 11 Jan 2019 at 18:25, Eduardo Habkost wrote:
>
> The following changes since commit e53f7796fbe71a5c7c24ffebf04b4aa9a759da36:
>
> Merge remote-tracking branch
> 'remotes/ehabkost/tags/machine-next-pull-request' into staging (2019-01-11
> 13:35:48 +)
>
> are available in the Git rep
On Mon, 14 Jan 2019 at 18:22, Stefan Hajnoczi wrote:
>
> On Sat, Jan 12, 2019 at 12:50:12PM +0800, Yongji Xie wrote:
> > On Fri, 11 Jan 2019 at 23:53, Stefan Hajnoczi wrote:
> > >
> > > On Thu, Jan 10, 2019 at 06:59:27PM +0800, Yongji Xie wrote:
> > > > On Thu, 10 Jan 2019 at 18:25, Stefan Hajnoc
Vitaly Kuznetsov writes:
> Eduardo Habkost writes:
>
>> On Wed, Dec 19, 2018 at 06:25:06PM +0100, Vitaly Kuznetsov wrote:
>>> Eduardo Habkost writes:
>>>
>>> > On Mon, Dec 03, 2018 at 03:17:06PM +0100, Vitaly Kuznetsov wrote:
>>> >> Eduardo Habkost writes:
>>> > [...]
>>> >> > But note that w
On 1/11/19 3:08 AM, Li Qiang wrote:
> Signed-off-by: Li Qiang
> Reviewed-by: Max Reitz
Reviewed-by: Philippe Mathieu-Daudé
> ---
> hw/block/nvme.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hw/block/nvme.c b/hw/block/nvme.c
> index 7c8c63e8f5..f206391e8e 100644
* Michael Tokarev (m...@tls.msk.ru) wrote:
> $ qemu-system-x86_64 -monitor stdio -hda foo.img
> QEMU 3.1.0 monitor - type 'help' for more information
> (qemu) stop
> (qemu) migrate "exec:cat >/dev/null"
> (qemu) migrate "exec:cat >/dev/null"
> qemu-system-x86_64: /build/qemu/qemu-3.1/block.c:4647:
On 1/9/19 9:19 PM, Yuval Shaia wrote:
> This member is used only in init_device_caps function, make it local.
>
> Signed-off-by: Yuval Shaia
Reviewed-by: Philippe Mathieu-Daudé
> ---
> hw/rdma/rdma_backend.c | 26 ++
> hw/rdma/rdma_backend_defs.h | 1 -
> 2 files
It only affects VNC, not chardevs because the chardevs fail to call
qio_channel_close() and just rely on finalize() cleaning up the open
socket. To fix this we just need to made the code conditional on it
being a listener socket
if (qio_channel_has_feature(ioc, QIO_CHANNEL_FEATURE_LISTEN)) {
Relying on sleep to always return having slept isn't safe as a signal
may have occurred. If signals are constantly incoming the program will
never reach it's termination condition. This is believed to be the
mechanism causing time outs for qht-test in Travis.
The glib g_usleep() deals with all of
On 11/01/2019 22:31, Richard Henderson wrote:
On 1/11/19 2:17 AM, Laurent Vivier wrote:
On 19/12/2018 05:21, Richard Henderson wrote:
Signed-off-by: Richard Henderson
---
linux-user/syscall-defs.h | 14
linux-user/syscall-file.inc.c | 124 ++
linux
On 1/9/19 9:21 PM, Yuval Shaia wrote:
> The functions handles errors internaly, callers have nothing to do with
> the return value.
>
> Signed-off-by: Yuval Shaia
Reviewed-by: Philippe Mathieu-Daudé
> ---
> hw/rdma/vmw/pvrdma_qp_ops.c | 14 ++
> hw/rdma/vmw/pvrdma_qp_ops.h | 4 ++
On Mon, Jan 14, 2019, 6:34 PM Thomas Huth On 2017-12-25 03:54, Mao Zhongyi wrote:
> > Packet size some time different or when network is busy.
> > Based on same payload size, but TCP protocol can not
> > guarantee send the same one packet in the same way,
> [...]
> > Signed-off-by: Mao Zhongyi
>
On 26.11.18 04:57, zhenwei pi wrote:
> Function raw_co_truncate does not check effective size for BLK device file,
> and QEMU may notify guest without any size changing.
>
> Two cases can be reproduced easily by qmp command:
> CASE 1:
> 1, create a logical volume(12M) by LVM, and guest uses this v
Hi Alistair,
On 1/12/19 2:17 AM, Alistair Francis wrote:
> Cast the kernel start address to the target bit length.
>
> This ensures that we calculate the initrd offset to a valid address for
> the architecture.
Can you add an example of the failure symptoms?
>
> Signed-off-by: Alistair Francis
On 2017-12-25 03:54, Mao Zhongyi wrote:
> Packet size some time different or when network is busy.
> Based on same payload size, but TCP protocol can not
> guarantee send the same one packet in the same way,
[...]
> Signed-off-by: Mao Zhongyi
> Signed-off-by: Li Zhijian
> Signed-off-by: Zhang Che
On Mon, Jan 14, 2019 at 03:35:17PM +0800, Changpeng Liu wrote:
> Linux commit 1f23816b8 "virtio_blk: add discard and write zeroes support"
> added the support in the Guest kernel, while here enable the feature bits
> support with vhost-user-blk driver. Also enable the test example utility
> with D
On 1/12/19 2:32 AM, BALATON Zoltan wrote:
> The file no longer uses error_report after review so the header is not
> needed either.
>
> Signed-off-by: BALATON Zoltan
Reviewed-by: Philippe Mathieu-Daudé
> ---
> Forgot to delete this when rewriting after review. This
> can be squashed into 7713f
PCI on s390x is really weird and how it was modeled in QEMU might not have
been the right choice. Anyhow, right now it is the case that:
- Hotplugging a PCI device will silently create a zPCI device
(if none is provided)
- Hotunplugging a zPCI device will unplug the PCI device (if any)
- Hotunplu
On 1/14/19 8:18 AM, Peter Xu wrote:
> On Mon, Jan 14, 2019 at 08:02:23AM +0100, Markus Armbruster wrote:
>> Peter Xu writes:
>>
>>> On Sun, Jan 13, 2019 at 10:36:41PM +0800, Fei Li wrote:
From: Fei Li
Let's supplement the msi_uninit() when failing to realize
the pci edu device
When resetting the guest we should unplug and remove all devices that
are still pending. Otherwise the fresh guest will see devices that will
suddenly vanish.
Can be triggered e.g. via
(hmp) device_add virtio-mouse-pci,id=test
(hmp) stop
(hmp) device_del test
(hmp) system_reset
(hmp) c
The device
... otherwise two successive calls to qdev_unplug() (e.g. by an impatient
user) will effectively overwrite pbdev->release_timer, resulting in a
memory leak. We are already processing the unplug.
If there is already a release_timer, the unplug will be performed after
the timeout.
Can be easily tri
On 1/13/19 10:41 AM, Leonid Bloch wrote:
> On 1/11/19 9:14 PM, Markus Armbruster wrote:
>> We define 54 macros for the powers of two >= 1024. We use six, in six
>> macro definitions. Four of them could just as well use the common MiB
>> macro, so do that. The remaining two can't, because they ge
A bunch of fixes and reworks for s390x/pci hotplug infrastructure.
Patch 1,2: Reworks already posted (pre_plug handler)
Patch 3,4: Fixes for memory leaks
Patch 5: Rework unplug handler (introduce unplug_request handler) which
also fixes some unplug scenarios
Patch 6: Handle leftover unplu
We should always get rid of it. I don't see a reason to keep the timer
alive if the devices are going away. This looks like a memory leak.
(hmp) device_add virtio-mouse-pci,id=test
(hmp) device_del test
-> guest notified, timer pending.
-> guest does not react for some reason (e.g. crash)
-> s390_
401 - 500 of 577 matches
Mail list logo
