Hi,
> Then I don't understand why it just ran fine.
> I don't expect fullscreen output to work perfectly anyway;
If you don't expect the output to actually work,
then fine, feel free to comment out that check.
I don't consider that being a sane approach though.
> just enough so I can use qemu
On Mon, Apr 15, 2019 at 10:04:52AM +0200, Kevin Wolf wrote:
>
> I think a potential actual use case could be persistent dirty bitmaps
> for incremental backup. Though maybe that would be better served by
> using the rbd image just as a raw external data file and keeping the
> qcow2 metadata on a f
On 17.04.19 06:30, Richard Henderson wrote:
> On 4/16/19 8:52 AM, David Hildenbrand wrote:
>> Let's add tcg_gen_gvec_3i(), similar to tcg_gen_gvec_2i(), however
>> without introducing "gen_helper_gvec_3i *fnoi", as it isn't needed
>> for now.
>>
>> Signed-off-by: David Hildenbrand
>> ---
>> tcg/t
On Tue, 16 Apr 2019 20:52:20 +0200
David Hildenbrand wrote:
> This is the second part of vector instruction support for s390x. It is
> based on the series soon to land upstream:
> [PATCH 0/9] tcg: Add tcg_gen_extract2_{i32,i64}
>
> Part 1: Vector Support Instructions
> Part 2: Vector Integer
Am 17.04.2019 um 09:34 hat Stefano Garzarella geschrieben:
> On Mon, Apr 15, 2019 at 10:04:52AM +0200, Kevin Wolf wrote:
> >
> > I think a potential actual use case could be persistent dirty bitmaps
> > for incremental backup. Though maybe that would be better served by
> > using the rbd image jus
On 16.4.19. 23:20, Aleksandar Markovic wrote:
From: Mateja Marjanovic
+void helper_msa_ilvr_b(CPUMIPSState *env, uint32_t wd,
+ uint32_t ws, uint32_t wt)
+{
+wr_t *pwd = &(env->active_fpu.fpr[wd].wr);
+wr_t *pws = &(env->active_fpu.fpr[ws].wr);
+wr_t *pwt = &
On Tue, Apr 16, 2019 at 11:27:06PM +0100, Peter Maydell wrote:
> On Tue, 16 Apr 2019 at 20:33, Peter Maydell wrote:
> >
> > On Tue, 16 Apr 2019 at 18:27, Peter Maydell
> > wrote:
> > > Having thought a bit more I think I'd definitely like to apply
> > > just patch 2 for 4.0. Could people try to
On Mon, Apr 15, 2019 at 12:50:43PM -0400, Bandan Das wrote:
> Forgot to cc people ...
>
> Bandan Das writes:
>
> > Commit c5ead51f90cf (usb-mtp: return incomplete transfer on a lstat
> > failure) checks if lstat succeeded when updating attributes of a
> > file. However, it also changed behavior
On 4/16/19 9:42 PM, David Hildenbrand wrote:
> On 17.04.19 06:30, Richard Henderson wrote:
>> On 4/16/19 8:52 AM, David Hildenbrand wrote:
>>> Let's add tcg_gen_gvec_3i(), similar to tcg_gen_gvec_2i(), however
>>> without introducing "gen_helper_gvec_3i *fnoi", as it isn't needed
>>> for now.
>>>
>
Hi All,
At the outset, I do understand there is no mainstream requirement for
having virtual wireless NIC, if et all there is any, mac80211_hwsim (part
of Linux) is more than sufficient.
So this is purely an academic attempt.
In order to support following topology,
[image: qemu-wifi-topology.pn
Hi all. We faced an interesting bug, which may be simply reproduced:
prepare image:
./qemu-img create -f qcow2 -o cluster_size=1M /ssd/test 2300M
./qemu-io -c 'write 100M 2000M' -c 'write 2100M 200M' -c 'write 0 100M'
/ssd/test
shrink:
./qemu-img resize --shrink /ssd/test 50M
bug:
./qemu-img in
This fixes at least one overflow in qcow2_process_discards.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
include/block/block.h | 4 ++--
block/io.c| 19 ++-
2 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/include/block/block.h b/include/block/bloc
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
tests/qemu-iotests/249 | 69 ++
tests/qemu-iotests/249.out | 30 +
tests/qemu-iotests/group | 1 +
3 files changed, 100 insertions(+)
create mode 100755 tests/qemu-iotests/249
create mode
On 17.04.19 11:14, Richard Henderson wrote:
> On 4/16/19 9:42 PM, David Hildenbrand wrote:
>> On 17.04.19 06:30, Richard Henderson wrote:
>>> On 4/16/19 8:52 AM, David Hildenbrand wrote:
Let's add tcg_gen_gvec_3i(), similar to tcg_gen_gvec_2i(), however
without introducing "gen_helper_gve
On 17.04.19 09:54, Cornelia Huck wrote:
> On Tue, 16 Apr 2019 20:52:20 +0200
> David Hildenbrand wrote:
>
>> This is the second part of vector instruction support for s390x. It is
>> based on the series soon to land upstream:
>> [PATCH 0/9] tcg: Add tcg_gen_extract2_{i32,i64}
>>
>> Part 1: Ve
David Gibson's on April 17, 2019 11:59 am:
> On Tue, Apr 16, 2019 at 02:55:52PM +1000, Nicholas Piggin wrote:
>> These implementations have a few deficiencies that are noted, but are
>> good enough for Linux to use.
>>
>> Signed-off-by: Nicholas Piggin
>> ---
>>
>> v3: Removed wrong comment abou
David Gibson's on April 17, 2019 10:47 am:
> On Mon, Apr 15, 2019 at 03:06:43PM +1000, Nicholas Piggin wrote:
>> It needs to be cleared at all vCPU dispatch points to SPEC, not just
>> when calling H_CEDE as Ben's patch had. I think complexity would be
>> significant for questionable benefit. Like
While the detection on s390x of the maximum ram pagesize works by pure luck,
we should try to do better. Especially, once "-mem-path" is replaced
by memory backends, the current approach will break.
Configure the maximum page size after configuring initital memory. Provide
a function to detect the
Right now we configure the pagesize quite early, when initializing KVM.
This is long before system memory is actually allocated via
memory_region_allocate_system_memory(), and therefore memory backends
marked as mapped.
Instead, let's configure the maximum page size after initializing
memory in s3
Rename qemu_getrampagesize() to qemu_minrampagesize(). While at it,
properly rename find_max_supported_pagesize() to
find_min_backend_pagesize().
s390x is actually interested into the maximum ram pagesize, so
introduce and use qemu_maxrampagesize().
Add a TODO, indicating that looking at any mapp
Richard, thank you for solving this so fast!
I certainly can confirm attached executables work fine for me on patched
version.
I'll also re-run full gcc regtest a bit later, but it runs for a rather
long time, not sure this result will be important next week.
Hopefully, patchset will be included
Linux places a limit of UIO_MAXIOV pages on SG_IO ioctls (and if the limit
is exceeded, a confusing ENOMEM error is returned[1]). Prevent the guest
from exceeding these limits, by capping the maximum transfer length to
that value in the block limits VPD page.
[1] Oh well, at least it was easier t
On Wed, 17 Apr 2019 21:20:00 +1000
Nicholas Piggin wrote:
> [...]
> >> @@ -1860,6 +1928,9 @@ static void hypercall_register_types(void)
> >> /* hcall-splpar */
> >> spapr_register_hypercall(H_REGISTER_VPA, h_register_vpa);
> >> spapr_register_hypercall(H_CEDE, h_cede);
> >> +spa
On 17/04/19 03:38, Wei Li wrote:
> Thanks Paolo for your response and clarification.
>
> Btw, is there any rough schedule about when are you planning to start
> working on the multi queue feature? Once you start working on the
> feature, I would like to hear more details about the design and
> be
Unfortunately the fix is too big for this point in the 4.0 release
cycle; it'll go into 4.1.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1824853
Title:
4.0.0-rc3 crashes with tcg/tcg.c:3952: tcg_
On Wed, Apr 17, 2019 at 12:54 PM Paolo Bonzini wrote:
> Linux places a limit of UIO_MAXIOV pages on SG_IO ioctls (and if the limit
> is exceeded, a confusing ENOMEM error is returned[1]). Prevent the guest
> from exceeding these limits, by capping the maximum transfer length to
> that value in th
On 4/17/19 5:09 AM, Vladimir Sementsov-Ogievskiy wrote:
> Hi all. We faced an interesting bug, which may be simply reproduced:
>
> prepare image:
> ./qemu-img create -f qcow2 -o cluster_size=1M /ssd/test 2300M
> ./qemu-io -c 'write 100M 2000M' -c 'write 2100M 200M' -c 'write 0 100M'
> /ssd/test
>
Ping
08.04.2019, 14:34, "Yury Kotov" :
> It fixes heap-use-after-free which was found by clang's ASAN.
>
> Control flow of this use-after-free:
> main_thread:
> * Got SIGTERM and completes main loop
> * Calls migration_shutdown
> - migrate_fd_cancel (so, migration_thread begins to co
Hello Philippe,
Sorry for replying you so late.
On 4.4.19. 15:42, Philippe Mathieu-Daudé wrote:
Hi Mateja,
On 4/4/19 3:14 PM, Mateja Marjanovic wrote:
From: Mateja Marjanovic
Optimize set of MSA instructions ILVEV., using
directly tcg registers and performing logic on them
instead of using h
Ping
04.04.2019, 13:01, "Yury Kotov" :
> I saw Catherine Ho's patch series and it seems ok to me, but in this RFC I
> asked
> about a way how to detect other writes which may not be covered by particular
> fixes.
> Perhaps this is excessive caution...
>
> Regards,
> Yury
>
> 04.04.2019, 12:52, "D
On Wed, Apr 17, 2019 at 02:01:29PM +0200, Greg Kurz wrote:
> On Wed, 17 Apr 2019 21:20:00 +1000
> Nicholas Piggin wrote:
> > [...]
> > >> @@ -1860,6 +1928,9 @@ static void hypercall_register_types(void)
> > >> /* hcall-splpar */
> > >> spapr_register_hypercall(H_REGISTER_VPA, h_register_
On Wed, Apr 17, 2019 at 09:20:00PM +1000, Nicholas Piggin wrote:
> David Gibson's on April 17, 2019 11:59 am:
> > On Tue, Apr 16, 2019 at 02:55:52PM +1000, Nicholas Piggin wrote:
> >> These implementations have a few deficiencies that are noted, but are
> >> good enough for Linux to use.
> >>
> >>
On Wed, Apr 17, 2019 at 07:41:23AM +0200, Markus Armbruster wrote:
> Eduardo Habkost writes:
>
> > The new function will be useful in user mode, when we already
> > have a CPU model and don't need to parse any extra options.
> >
> > Signed-off-by: Eduardo Habkost
> > ---
> > include/qom/cpu.h |
In load_elf_binary (linux-user/elfload.c b/linux-user/elfload.c:2644)
the entire interp_info struct should be inited, I would call this a CVE.
At a very minimum, init the fp_abi field so we don't use whatever
happened to be on the stack for the FPU mode should the ELF header not
specify otherwise.
On Wed, 17 Apr 2019 22:47:34 +1000
David Gibson wrote:
> On Wed, Apr 17, 2019 at 02:01:29PM +0200, Greg Kurz wrote:
> > On Wed, 17 Apr 2019 21:20:00 +1000
> > Nicholas Piggin wrote:
> > > [...]
> > > >> @@ -1860,6 +1928,9 @@ static void hypercall_register_types(void)
> > > >> /* hcall-s
Hi everyone,
as you may already know, there is an experimental feature in QEMU wiki
page called “virtio-vhost-user” [1]. Stefan Hajnoczi launched this
feature a year ago. He even wrote an RFC implementation [2]. However,
this feature is still a WIP.
At present, I am working with Dariusz Stojaczyk
Please send patches to the mailing list for inclusion. QEMU maintainers
normally don't take patches from the bug tracker. See
https://wiki.qemu.org/Contribute/SubmitAPatch
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.l
Actually, this is a better patch. Let's sanitize struct image_info
interp_info.
** Patch added: "0001-1825002-fix-mips-Unexpected-FPU-mode.patch"
https://bugs.launchpad.net/qemu/+bug/1825002/+attachment/5256566/+files/0001-1825002-fix-mips-Unexpected-FPU-mode.patch
--
You received this bug
On Tue, 16 Apr 2019 13:09:08 +0200
Christian Borntraeger wrote:
> This fails with more than 8TB, e.g. "-m 9T "
>
> [pid 231065] ioctl(10, KVM_SET_USER_MEMORY_REGION, {slot=0, flags=0,
> guest_phys_addr=0, memory_size=0, userspace_addr=0x3ffc850}) = 0
> [pid 231065] ioctl(10, KVM_SET_USER_M
On 4/17/19 5:09 AM, Vladimir Sementsov-Ogievskiy wrote:
> This fixes at least one overflow in qcow2_process_discards.
It's worth calling out how long the problem of passing >2G discard
requests has been present (my reply to the cover letter tracked down
0b919fae as tracking a 64-bit discard region
On 2019/4/16 22:17, Pavel Hrdina wrote:
On Tue, Apr 16, 2019 at 08:06:13PM +0800, Pu Wen wrote:
Add a new base CPU model called 'Dhyana' to model processors from Hygon
Dhyana(family 18h), which derived from AMD EPYC(family 17h).
The following features bits have been removed compare to AMD EPYC:
On 2019/4/17 2:03, Eduardo Habkost wrote:
On Tue, Apr 16, 2019 at 08:06:13PM +0800, Pu Wen wrote:
Add a new base CPU model called 'Dhyana' to model processors from Hygon
Dhyana(family 18h), which derived from AMD EPYC(family 17h).
The following features bits have been removed compare to AMD EPY
On 4/17/19 5:09 AM, Vladimir Sementsov-Ogievskiy wrote:
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> ---
> tests/qemu-iotests/249 | 69 ++
> tests/qemu-iotests/249.out | 30 +
> tests/qemu-iotests/group | 1 +
> 3 files changed, 100 in
182 fails if qemu has no support for hotplugging of a virtio-blk device.
Using an NBD server instead works just as well for the test, even on
qemus without hotplugging support.
Fixes: 6d0a4a0fb5c8f10c8eb68b52cfda0082b00ae963
Reported-by: Danilo C. L. de Paula
Signed-off-by: Max Reitz
---
To rein
I think this is likely fixed with QEMU 4.0 by this commit here:
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=26b1cbf8b65b3b55c3f
Could you please try again with QEMU 4.0-rc4 (or the final 4.0 release
next week)?
** Changed in: qemu
Status: New => Incomplete
--
You received this bug n
This seems to be working now:
$ qemu-system-x86_64 -drive 'file=http://download.fedoraproject.org/pub
/fedora-secondary/releases/29/Server/i386/iso/Fedora-Server-
netinst-i386-29-1.2.iso,if=virtio,snapshot=on'
... boots from the ISO image, without error message. So I assume this
has been fixed, a
From: Mateja Marjanovic
Optimize set of MSA instructions ILVOD., using
directly tcg registers and performing logic on them instead
of using helpers.
In the following table, the first column is the performance
before this patch. The second represents the performance
after converting from helpers
From: Mateja Marjanovic
Optimize ILVL. instructions, using a hybrid
approach. For byte data elements, use a helper with an
unrolled loop (having much better performance than
direct tcg translation), for halfword, word and
doubleword data elements use directly tcg registers
and logic performed on
From: Mateja Marjanovic
Optimize and refactor MSA instructions ILVEV.,
ILVOD., ILVL. and ILVR..
v7:
- Use tcg constants, instead of uint64_t constants in
ILVEV. and ILVOD. instructions.
- Refactor gen_ilvod_b and gen_ilvod_h functions. Use
the shared function gen_ilvod_bh, which has two
From: Mateja Marjanovic
Optimize ILVR. instructions, using a hybrid
approach. For byte data elements, use a helper with an
unrolled loop (having much better performance than
direct tcg translation), for halfword, word and
doubleword data elements use directly tcg registers
and logic performed on
From: Mateja Marjanovic
The implementation for ILVOD.D and ILVL.D instructions
is equivalent, so use a single handler for both of them.
Suggested-by: Aleksandar Markovic
Signed-off-by: Mateja Marjanovic
---
target/mips/translate.c | 27 ++-
1 file changed, 10 insertion
From: Mateja Marjanovic
Optimize set of MSA instructions ILVEV., using
directly tcg registers and performing logic on them
instead of using helpers.
In the following table, the first column is the performance
before this patch. The second represents the performance
after converting from helpers
>From 55e222d8139e3dd034069fb512b83fd2541ec067 Mon Sep 17 00:00:00 2001
From: Mateja Marjanovic
Date: Wed, 17 Apr 2019 14:50:55 +0200
Subject: [PATCH v7 5/6] target/mips: Merge implementation of ILVEV.D and ILVR.D
The implementation for ILVEV.D and ILVR.D instructions
is equivalent, so use a sing
On 4/17/19 10:30 AM, Max Reitz wrote:
> 182 fails if qemu has no support for hotplugging of a virtio-blk device.
> Using an NBD server instead works just as well for the test, even on
> qemus without hotplugging support.
>
> Fixes: 6d0a4a0fb5c8f10c8eb68b52cfda0082b00ae963
> Reported-by: Danilo C.
Even for block nodes with bs->drv == NULL, we can't just ignore a
bdrv_set_aio_context() call. Leaving the node in its old context can
mean that it's still in an iothread context in bdrv_close_all() during
shutdown, resulting in an attempted unlock of the AioContext lock which
we don't hold.
This
On 4/17/19 10:48 AM, Kevin Wolf wrote:
> Even for block nodes with bs->drv == NULL, we can't just ignore a
> bdrv_set_aio_context() call. Leaving the node in its old context can
> mean that it's still in an iothread context in bdrv_close_all() during
> shutdown, resulting in an attempted unlock of
On 16.04.19 12:02, Vladimir Sementsov-Ogievskiy wrote:
> 10.04.2019 23:20, Max Reitz wrote:
>> What bs->file and bs->backing mean depends on the node. For filter
>> nodes, both signify a node that will eventually receive all R/W
>> accesses. For format nodes, bs->file contains metadata and data,
On 16.04.19 09:18, Vladimir Sementsov-Ogievskiy wrote:
> 13.04.2019 19:53, Max Reitz wrote:
>> This new error option allows users of blkdebug to inject errors only on
>> certain kinds of I/O operations. Users usually want to make a very
>> specific operation fail, not just any; but right now they
> From: Mateja Marjanovic
> Subject: [PATCH] target/mips: Amend tests for MSA binary integer operations
>
> Amend tests for certain MSA binary integer instructions
> (for example DIV_S.B) by appending two missing test cases
> to complete standard battery of 80 test cases for each
> such instructio
On 16.04.19 10:02, Vladimir Sementsov-Ogievskiy wrote:
> 13.04.2019 19:53, Max Reitz wrote:
>> This test converts a simple image to another, but blkdebug injects
>> block_status and read faults at some offsets. The resulting image
>> should be the same as the input image, except that sectors that
On 16.04.19 10:13, Vladimir Sementsov-Ogievskiy wrote:
> 13.04.2019 19:53, Max Reitz wrote:
>> We do not support this combination (yet), so this should yield an error
>> message.
>>
>> Signed-off-by: Max Reitz
>
> Tested-by: Vladimir Sementsov-Ogievskiy
> [only -qcow2, as -nfs -qcow2
On 17.04.19 17:48, Kevin Wolf wrote:
> Even for block nodes with bs->drv == NULL, we can't just ignore a
> bdrv_set_aio_context() call. Leaving the node in its old context can
> mean that it's still in an iothread context in bdrv_close_all() during
> shutdown, resulting in an attempted unlock of th
On 4/10/19 2:28 PM, Max Reitz wrote:
> On 01.04.19 16:57, Eric Blake wrote:
>> Disk sizes close to INT64_MAX cause overflow, for some pretty
>> ridiculous output:
>>
>> $ ./nbdkit -U - memory size=$((2**63 - 512)) --run 'qemu-img info $nbd'
>> image: nbd+unix://?socket=/tmp/nbdkitHSAzNz/socket
On Wed, Apr 17, 2019 at 07:26:14AM +0200, Markus Armbruster wrote:
> Like Xu writes:
>
> > This patch makes the remaining dozen or so uses of the global
> > current_machine outside vl.c use qdev_get_machine() instead,
> > and then make current_machine local to vl.c instead of global.
> >
> > Sugg
Sorry, I'm done having to argue against(!) a person who's stonewalling
me by wilfully ignoring differences ("doesn't work perfectly"
interpreted as "does not work at all"), discounting
just-for-testing-purpose workarounds as if they were actual proposed
solutions ("not a sane approach"), ignori
On Wed, Apr 17, 2019 at 07:14:10AM +0200, Markus Armbruster wrote:
> Eduardo Habkost writes:
>
> > On Mon, Apr 15, 2019 at 03:59:45PM +0800, Like Xu wrote:
> >> To avoid the misuse of qdev_get_machine() if machine hasn't been created
> >> yet,
> >> this patch uses qdev_get_machine_uncheck() for
When extracting a human-readable size formatter, we changed 'uint64_t
div' pre-patch to 'unsigned long div' post-patch. Which breaks on
32-bit platforms, resulting in 'inf' instead of intended values larger
than 999GB.
Fixes: 22951aaa
CC: qemu-sta...@nongnu.org
Reported-by: Max Reitz
Signed-off-b
since v2: Fix problems pointed out by Max:
vmdk (test 59) output had not actually been tested
32-bit builds of size_to_str() have been been broken since 2.10
Eric Blake (2):
cutils: Fix size_to_str() on 32-bit platforms
qemu-img: Saner printing of large file sizes
block/qapi.c
Disk sizes close to INT64_MAX cause overflow, for some pretty
ridiculous output:
$ ./nbdkit -U - memory size=$((2**63 - 512)) --run 'qemu-img info $nbd'
image: nbd+unix://?socket=/tmp/nbdkitHSAzNz/socket
file format: raw
virtual size: -8388607T (9223372036854775296 bytes)
disk size: unav
On 17.04.19 18:58, Eric Blake wrote:
> On 4/10/19 2:28 PM, Max Reitz wrote:
>> On 01.04.19 16:57, Eric Blake wrote:
>>> Disk sizes close to INT64_MAX cause overflow, for some pretty
>>> ridiculous output:
>>>
>>> $ ./nbdkit -U - memory size=$((2**63 - 512)) --run 'qemu-img info $nbd'
>>> image:
Markus Armbruster writes:
> Before the from qerror_report() to error_setg(), hints looked like
> this:
>
> qerror_report(QERR_MACRO, ... arguments ...);
> error_printf_unless_qmp(... hint ...);
>
> error_printf_unless_qmp() made perfect sense: it printed exactly when
> qerror_report() did
Vladimir Sementsov-Ogievskiy writes:
> It would be nice to have Error object not freed away when debugging a
> coredump.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> ---
>
> v2: don't change error output format
>
> util/error.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
On 17.04.19 19:11, Eric Blake wrote:
> When extracting a human-readable size formatter, we changed 'uint64_t
> div' pre-patch to 'unsigned long div' post-patch. Which breaks on
> 32-bit platforms, resulting in 'inf' instead of intended values larger
> than 999GB.
>
> Fixes: 22951aaa
> CC: qemu-sta
On Wed, Apr 17, 2019 at 11:58:57AM -0500, Eric Blake wrote:
> On 4/10/19 2:28 PM, Max Reitz wrote:
> > On 01.04.19 16:57, Eric Blake wrote:
> >> Disk sizes close to INT64_MAX cause overflow, for some pretty
> >> ridiculous output:
> >>
> >> $ ./nbdkit -U - memory size=$((2**63 - 512)) --run 'qemu
Hello,
On behalf of the QEMU Team, I'd like to announce the availability of the
fifth release candidate for the QEMU 4.0 release. This release is meant
for testing purposes and should not be used in a production environment.
http://download.qemu-project.org/qemu-4.0.0-rc4.tar.xz
http://downl
Public bug reported:
Demonstrated against 2.11 (ubuntu bionic 1:2.11+dfsg-1ubuntu7.12) and
3.1 (as built under bionic from the 1:3.1+dfsg-2ubuntu3 source package)
although the code hasn't changed between them and github master also
appears to have this same code branch.
What I was trying to do: s
Yes, using getrandom() in qemu by default on systems that support it
will be an improvement, and is the right approach.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1811758
Title:
virtio-rng backe
Fix had been included here (in QEMU v3.1 already):
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=7294e600eb814fd2
** Changed in: qemu
Status: New => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.l
On 17.04.19 19:11, Eric Blake wrote:
> Disk sizes close to INT64_MAX cause overflow, for some pretty
> ridiculous output:
>
> $ ./nbdkit -U - memory size=$((2**63 - 512)) --run 'qemu-img info $nbd'
> image: nbd+unix://?socket=/tmp/nbdkitHSAzNz/socket
> file format: raw
> virtual size: -838
Markus Armbruster writes:
> Paolo Bonzini writes:
>
>> On 11/04/19 16:52, Markus Armbruster wrote:
>>> char_pty_open() prints a "char device redirected to PTY_NAME (label
>>> LABEL)" message to the current monitor or else to stderr. No other
>>> ChardevClass::open() prints anything on success.
char_pty_open() prints a "char device redirected to PTY_NAME (label
LABEL)" message to the current monitor or else to stderr. This is not
an error, so it shouldn't go to stderr. Print it to stdout instead.
Why is it even printed? No other ChardevClass::open() prints anything
on success. It's b
Patchew URL: https://patchew.org/QEMU/87mukov6vk@dusky.pond.sub.org/
Hi,
This series failed the asan build test. Please find the testing commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
#!/bin/bash
time make doc
Hi Joachim,
On 04/17/19 19:09, Joachim Durchholz wrote:
> Sorry, I'm done having to argue against(!) a person who's stonewalling
> me by wilfully ignoring differences ("doesn't work perfectly"
> interpreted as "does not work at all"), discounting
> just-for-testing-purpose workarounds as if they w
char_pty_open() prints a "char device redirected to PTY_NAME (label
LABEL)" message to the current monitor or else to stderr. This is not
an error, so it shouldn't go to stderr. Print it to stdout instead.
Why is it even printed? No other ChardevClass::open() prints anything
on success. It's b
Commit a95db58f210 added monitor_vfprintf() as an error_printf()
generalized from stderr to arbitrary streams, then used it wrapped in
helper out_printf() to print -device/device_add help to stdout. Use
qemu_printf() instead, and delete monitor_vfprintf() and out_printf().
Cc: Dr. David Alan Gilb
Cc: Paul Burton
Cc: Aleksandar Rikalo
Signed-off-by: Markus Armbruster
Reviewed-by: Philippe Mathieu-Daudé
---
hw/mips/boston.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/hw/mips/boston.c b/hw/mips/boston.c
index e5bab3cadc..a8b29f62f5 100644
--- a/hw/mips/boston
load_fit() reports errors with error_printf() instead of
error_report(). Worse, it even reports errors it actually recovers
from, in fit_cfg_compatible() and fit_load_fdt(). Messed up in
initial commit 51b58561c1d.
Convert the helper functions for load_fit() to Error. Make sure each
failure pat
Command line help help explicitly requested by the user should be
printed to stdout, not stderr. We do elsewhere. Adjust -machine
$TYPE,help and -accel help to match: use printf() instead of
error_printf().
Cc: Marcel Apfelbaum
Signed-off-by: Markus Armbruster
Reviewed-by: Marcel Apfelbaum
--
This series cleans up two kinds of error_printf() misuse:
* Errors and warnings should be reported with error_report() and
warn_report().
* Help output should be go to stdout, not stderr.
This is obviously for 4.1. If nobody objects, I'll take the whole
series through my tree.
Based-on: <201
kvm_s390_mem_op() can fail in two ways: when !cap_mem_op, it returns
-ENOSYS, and when kvm_vcpu_ioctl() fails, it returns -errno set by
ioctl(). Its caller s390_cpu_virt_mem_rw() recovers from both
failures.
kvm_s390_mem_op() prints "KVM_S390_MEM_OP failed" with error_printf()
in the latter failu
Command line help explicitly requested by the user should be printed
to stdout, not stderr. We do elsewhere. Adjust -chardev to match:
use qemu_printf() instead of error_printf(). Plain printf() would be
wrong because we need to print to the current monitor for "chardev-add
help".
Cc: "Marc-And
Cc: "Michael S. Tsirkin"
Cc: Marcel Apfelbaum
Signed-off-by: Markus Armbruster
Reviewed-by: Marcel Apfelbaum
---
hw/pci/pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index 6d13ef877b..1808b242dd 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.
Cc: "Michael S. Tsirkin"
Cc: Paolo Bonzini
Signed-off-by: Markus Armbruster
---
hw/timer/hpet.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/timer/hpet.c b/hw/timer/hpet.c
index d97436bc7b..41024f39fb 100644
--- a/hw/timer/hpet.c
+++ b/hw/timer/hpet.c
@@ -744,7 +744,7
Command line help explicitly requested by the user should be printed
to stdout, not stderr. We do elsewhere. Adjust -drive to match: use
qemu_printf() instead of error_printf(). Plain printf() would be
wrong because we need to print to the current monitor for "drive_add
... format=help".
Cc: Ke
error_exit() uses low-level error_printf() to report errors.
Modernize it to use error_vreport().
Cc: Kevin Wolf
Cc: Max Reitz
Cc: qemu-bl...@nongnu.org
Signed-off-by: Markus Armbruster
Reviewed-by: Eric Blake
---
qemu-img.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --
We commonly want to print to the current monitor if we have one, else
to stdout/stderr. For stderr, have error_printf(). For stdout, all
we have is monitor_vfprintf(), which is rather unwieldy. We often
print to stderr just because error_printf() is easier.
New qemu_printf() and qemu_vprintf()
printf() & friends return the number of characters written on success,
negative value on error.
monitor_printf(), monitor_vfprintf(), monitor_vprintf(),
error_printf(), error_printf_unless_qmp(), error_vprintf(), and
error_vprintf_unless_qmp() return void. Some of them carry a TODO
comment asking
Cc: Alex Williamson
Signed-off-by: Markus Armbruster
---
hw/vfio/pci.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index 504019c458..0142819ea6 100644
--- a/hw/vfio/pci.c
+++ b/hw/vfio/pci.c
@@ -947,8 +947,10 @@ static vo
qsp_report() takes an fprintf()-like callback and a FILE * to pass to
it.
Its only caller hmp_sync_profile() passes monitor_fprintf() and the
current monitor cast to FILE *. monitor_fprintf() casts it right
back, and is otherwise identical to monitor_printf(). The
type-punning is ugly.
Drop the
Callbacks ssh_co_readv(), ssh_co_writev(), ssh_co_flush() report
errors to the user with error_printf(). They shouldn't, it's their
caller's job. Replace by a suitable trace point. While there, drop
the unreachable !s->sftp case.
Perhaps we should convert this part of the block driver interface
1 - 100 of 188 matches
Mail list logo
