If the fd socket peer closed shortly, ppoll may receive a POLLHUP
event before the expected POLLIN event, and qemu will do nothing
but goes into an infinite loop of the POLLHUP event.
So, abort the migration if we receive a POLLHUP event.
Signed-off-by: Wang Xin
diff --git a/migration/fd.c b/mi
On 04/20/2018 02:09 PM, Peter Maydell wrote:
> On 13 April 2018 at 08:52, Cédric Le Goater wrote:
>> On the POWER9 processor, the XIVE interrupt controller can control
>> interrupt sources using MMIO to trigger events, to EOI or to turn off
>> the sources. Priority management and interrupt acknowl
At 2018-04-02 14:15:48, "Chen Hanxiao" wrote:
>From: Chen Hanxiao
>
>If we set mountpoints to qmp_guest_fsfreeze_freeze_list,
>we may got nothing to freeze as all mountpoints are
>not valid.
>So call ga_unset_frozen in this senario.
>
>Also, if we return 0 frozen fs, there is no need to call
>gu
On 04/20/2018 02:48 PM, Peter Maydell wrote:
> Currently we use memory_region_init_ram_nomigrate() to create
> the "aspeed.boot_rom" memory region, and we don't manually
> register it with vmstate_register_ram(). This currently
> means that its contents are migrated but as a ram block
> whose name
On 04/20/2018 02:48 PM, Peter Maydell wrote:
> Currently we use vmstate_register_ram_global() for the SRAM;
> this is not a good idea for devices, because it means that
> you can only ever create one instance of the device, as
> the second instance would get a RAM block name clash.
> Instead, use m
On 21 April 2018 at 09:52, Cédric Le Goater wrote:
> On 04/20/2018 02:09 PM, Peter Maydell wrote:
>> Notes:
>> * any device that registers a ramblock globally is a bit dodgy, because
>> it means you can't have more than one of it (the ramblock names would
>> clash). We should fix those devices fo
On 21 April 2018 at 10:07, Cédric Le Goater wrote:
> On 04/20/2018 02:48 PM, Peter Maydell wrote:
>> Currently we use memory_region_init_ram_nomigrate() to create
>> the "aspeed.boot_rom" memory region, and we don't manually
>> register it with vmstate_register_ram(). This currently
>> means that
On Fri, Apr 20, 2018 at 05:34:38PM +0200, Paolo Bonzini wrote:
> On 20/04/2018 04:18, David Gibson wrote:
> > Paolo et al, as with my earlier patches adding some extensions to the
> > helpers for determining backing page sizes, if there are no objections
> > can I get an ack to merge this via my pp
On 04/21/2018 11:34 AM, Peter Maydell wrote:
> On 21 April 2018 at 10:07, Cédric Le Goater wrote:
>> On 04/20/2018 02:48 PM, Peter Maydell wrote:
>>> Currently we use memory_region_init_ram_nomigrate() to create
>>> the "aspeed.boot_rom" memory region, and we don't manually
>>> register it with vm
On Sat, Apr 21, 2018 at 11:29 AM, Eva Chen wrote:
> Thanks for your reply.
>
> Actually, I don't know there is existing work on emulating heterogeneous
> system under QEMU. The only work I know is that QEMU has implemented
> multicore in one QEMU process. But what I want to do is to simulate two
>
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20180420145249.32435-1-peter.mayd...@linaro.org
Subject: [Qemu-devel] [PATCH 00/13] Drop compile time limit on number of serial
ports
=== TEST SCRIPT BEGIN ===
#!/bin/bash
(qemu) unknown keycodes `empty+aliases(qwerty)’, please report to
qemu-devel@nongnu.org
reported.
signature.asc
Description: Message signed with OpenPGP using GPGMail
This series adds a copy-on-read block filter driver which works by
simply setting the BDRV_REQ_COPY_ON_READ flag on write requests (and
otherwise just passing everything through).
Cover letter of v1:
http://lists.nongnu.org/archive/html/qemu-block/2018-04/msg00285.html
v2:
- Renamed the driver "
Currently we never actually check whether the WRITE_UNCHANGED
permission has been taken for unchanging writes. But the one check that
is commented out checks both WRITE and WRITE_UNCHANGED; and considering
that WRITE_UNCHANGED is already documented as being weaker than WRITE,
we should probably ex
This adds a simple copy-on-read filter driver. It relies on the already
existing COR functionality in the central block layer code, which may be
moved here once we no longer need it there.
Signed-off-by: Max Reitz
---
block/Makefile.objs | 2 +-
qapi/block-core.json | 5 +-
block/copy-on-r
COR across nodes (that is, you have some filter node between the
actually COR target and the node that performs the COR) cannot reliably
work together with the permission system when there is no explicit COR
node that can request the WRITE_UNCHANGED permission for its child.
This is because COR (cu
Signed-off-by: Max Reitz
Reviewed-by: Stefan Hajnoczi
Reviewed-by: Alberto Garcia
---
block/io.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/block/io.c b/block/io.c
index 134b2a498f..fada4efbf3 100644
--- a/block/io.c
+++ b/block/io.c
@@ -1115,13 +1115,15 @@ static
Update the rest of the filter drivers to support
BDRV_REQ_WRITE_UNCHANGED. They already forward write request flags to
their children, so we just have to announce support for it.
This patch does not cover the replication driver because that currently
does not support flags at all, and because it
This flag signifies that a write request will not change the visible
disk content. With this flag set, it is sufficient to have the
BLK_PERM_WRITE_UNCHANGED permission instead of BLK_PERM_WRITE.
Signed-off-by: Max Reitz
Reviewed-by: Stefan Hajnoczi
Reviewed-by: Alberto Garcia
---
include/bloc
We just need to forward it to quorum's children (except in case of a
rewrite because of corruption), but for that we first have to support
flags in child requests at all.
Signed-off-by: Max Reitz
Reviewed-by: Stefan Hajnoczi
Reviewed-by: Alberto Garcia
---
block/quorum.c | 19 +
Signed-off-by: Max Reitz
Reviewed-by: Stefan Hajnoczi
Reviewed-by: Alberto Garcia
---
tests/qemu-iotests/197 | 1 +
1 file changed, 1 insertion(+)
diff --git a/tests/qemu-iotests/197 b/tests/qemu-iotests/197
index 5e869fe2b7..3ae4975eec 100755
--- a/tests/qemu-iotests/197
+++ b/tests/qemu-iote
iotest 197 tests copy-on-read using the (now old) copy-on-read flag.
Copy it to 215 and modify it to use the COR filter driver instead.
Signed-off-by: Max Reitz
---
tests/qemu-iotests/215 | 120 +
tests/qemu-iotests/215.out | 26 ++
tests/
On 04/20/2018 05:53 PM, Max Reitz wrote:
> Some block drivers (iscsi and file-posix when dealing with device files)
> do not actually support truncation, even though they provide a
> .bdrv_truncate() method and will happily return success when providing a
> new size that does not exceed the current
On 2018-04-21 17:35, Eric Blake wrote:
> On 04/20/2018 05:53 PM, Max Reitz wrote:
>> Some block drivers (iscsi and file-posix when dealing with device files)
>> do not actually support truncation, even though they provide a
>> .bdrv_truncate() method and will happily return success when providing a
Some block drivers (iscsi and file-posix when dealing with device files)
do not actually support truncation, even though they provide a
.bdrv_truncate() method and will happily return success when providing a
new size that does not exceed the current size. This is because these
drivers expect the
Looking at the qcow2 code that is riddled with error_report() calls,
this is really how it should have been from the start.
Signed-off-by: Max Reitz
---
include/block/block.h | 3 +-
include/block/block_int.h | 3 +-
block.c| 8 --
block/qcow2.c | 72
It really is up to the caller to decide what this list of options means.
Signed-off-by: Max Reitz
---
qemu-img.c | 1 +
util/qemu-option.c | 1 -
2 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/qemu-img.c b/qemu-img.c
index 375fe852e0..6dd8e95bb2 100644
--- a/qemu-img.c
+++
The only users of print_block_option_help() are qemu-img create and
qemu-img convert for the output image, so this function is always used
for image creation (it used to be used for amendment also, but that is
no longer the case).
So if image creation is not supported by either the format or the
p
Instead of checking whether a driver has a non-NULL create_opts we
should check whether it supports image amendment in the first place. If
it does, it must have create_opts.
On the other hand, if it does not have create_opts (so it does not
support amendment either), the error message "does not s
Currently, "qemu-img amend -f $format -o help" prints many things which
it claims to be supported, but most of the time it's wrong. Usually
that starts with the format already: No format but qcow2 supports option
amendment, so we should never claim that a format supports any options
when it actual
This adds test cases to 082 for qemu-img create/convert/amend "-o help"
on formats that do not support creation or amendment, respectively.
Signed-off-by: Max Reitz
---
tests/qemu-iotests/082 | 9 +
tests/qemu-iotests/082.out | 9 +
2 files changed, 18 insertions(+)
diff --g
This test case has been broken since 398e6ad014df261d (roughly half a
year). qemu-img amend requires its output image to be R/W, so it opens
it as such; the node is then turned into an read-only node automatically
which is now accompanied by a warning, however. This warning has not
been part of t
The more generic print_block_option_help() function is not really
suitable for qemu-img amend, for a couple of reasons:
(1) We do not need to append the protocol-level options, as amendment
happens only on one node and does not descend downwards to its
children.
(2) print_block_option_help(
On Tue, Apr 17, 2018 at 8:46 PM, Markus Armbruster
wrote:
> Zhang Chen writes:
>
> > Libvirt or other high level software can use this command query colo
> status.
> > You can test this command like that:
> > {'execute':'query-colo-status'}
> >
> > Signed-off-by: Zhang Chen
> > ---
> > migrati
On Sun, Apr 15, 2018 at 08:43:04PM -0300, Philippe Mathieu-Daudé wrote:
> It eases code review, unit is explicit.
>
> Patch generated using:
>
> $ git grep -E '(1024|2048|4096|8192|(<<|>>).?(10|20|30))' hw/ include/hw/
>
> and modified manually.
>
> Signed-off-by: Philippe Mathieu-Daudé
> --
Public bug reported:
I use a qemu-user chroot + binfmt to build software targetting a
raspberry pi. After upgrading from qemu-2.10.1 to 2.11.1 (Gentoo host),
I noticed that on my uclibc-ng chroot qemu-arm will segfault when
running python and importing the portage module.
I have bisected qemu do
On Thu, Apr 19, 2018 at 09:48:17PM +1000, David Gibson wrote:
> On Thu, Apr 19, 2018 at 10:14:52AM +0530, Balamuruhan S wrote:
> > On Wed, Apr 18, 2018 at 09:36:33AM +0100, Dr. David Alan Gilbert wrote:
> > > * Balamuruhan S (bal...@linux.vnet.ibm.com) wrote:
> > > > On Wed, Apr 18, 2018 at 10:57:2
On Fri, Apr 20, 2018 at 11:28:04AM +0100, Dr. David Alan Gilbert wrote:
> * David Gibson (da...@gibson.dropbear.id.au) wrote:
> > On Thu, Apr 19, 2018 at 12:24:04PM +0100, Dr. David Alan Gilbert wrote:
> > > * Balamuruhan S (bal...@linux.vnet.ibm.com) wrote:
> > > > On Wed, Apr 18, 2018 at 09:36:33
Could you try with current head-of-git (the 2.12 rc4)? We adjusted our
logic for setting up the initial reserved space since 2.11 -- it may
well not fix this bug, but maybe we'll be lucky...
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to Q
Unfortunately, no dice
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1765970
Title:
qemu-arm (user mode) segfaults in uclibc-ng chroot after upgrade to
2.11.x
Status in QEMU:
New
Bug descript
This fixes the following ASan warning:
$ mips64el-softmmu/qemu-system-mips64el -M boston -kernel vmlinux.gz.itb
-nographic
hw/core/loader-fit.c:108:17: runtime error: load of misaligned address
0x7f95cd7e4264 for type 'fdt64_t', which requires 8 byte alignment
0x7f95cd7e4264: note: pointer
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20180419124331.3915-1-...@kaod.org
Subject: [Qemu-devel] [PATCH v3 00/35] ppc: support for the XIVE interrupt
controller (POWER9)
=== TEST SCRIPT BEGIN ===
#!/bin/bash
BASE
On 04/20/2018 11:52 AM, Peter Maydell wrote:
> Following commit 12051d82f004024, UART devices should handle
> being passed a NULL pointer chardev, so we don't need to
> create "null" backends in board code. Remove the code that
> does this and updates serial_hds[].
>
> Signed-off-by: Peter Maydell
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20180420181951.7252-1-ehabk...@redhat.com
Subject: [Qemu-devel] [RFC 00/24] Avocado-based functional tests
=== TEST SCRIPT BEGIN ===
#!/bin/bash
BASE=base
n=1
total=$(git lo
This fixes the following ASan warning:
$ qemu-system-xtensa -M kc705 -m 128M -semihosting -nographic -monitor null
-kernel Image.elf
include/hw/elf_ops.h:179:5: runtime error: null pointer passed as argument 1,
which is declared to never be null
Reported-by: AddressSanitizer
Signed-off-by:
On Fri, Apr 20, 2018 at 02:34:54PM +0200, David Hildenbrand wrote:
> On the qmp level, we already have the concept of memory devices:
> "query-memory-devices"
> Right now, we only support NVDIMM and PCDIMM.
>
> We want to map other devices later into the address space of the guest.
> Such devi
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1187529
Title:
Devices on
Hello,
This is good re-factoring and needed for 'virtio-pmem' as well to
reserve memory region in system address space.
I have tested this code with virtio-pmem and its working fine. Thank you
for the work.
I just have a small suggestion : when functions like(get_addr(),
get_plugged_size etc)
>
> On the qmp level, we already have the concept of memory devices:
> "query-memory-devices"
> Right now, we only support NVDIMM and PCDIMM.
>
> We want to map other devices later into the address space of the guest.
> Such device could e.g. be virtio devices. These devices will have a
> gu
49 matches
Mail list logo
