Public bug reported:
For me, this takes close to 3 minutes at 100% CPU:
echo "outl 0x518 0x9596" | ./i386-softmmu/qemu-system-i386 -M q35 -m 32
-nographic -accel qtest -monitor none -serial none -qtest stdio
#0 phys_page_find (d=0x60635d80, addr=136728041144404) at /exec.c:338
#1 addre
On 200518 1231, Philippe Mathieu-Daudé wrote:
> Trying libFuzzer on the vmport device, we get:
>
> AddressSanitizer:DEADLYSIGNAL
> =
> ==29476==ERROR: AddressSanitizer: SEGV on unknown address 0x8840
> (pc 0x56448bec4d7
kvm_physical_sync_dirty_bitmap() on the whole section is inaccurate, because
the section can be a superset of the memslot that we're working on. The result
is that if the section covers multiple kvm memslots, we could be doing the
synchronization for multiple times for each kvmslot in the section.
KVM dirty ring is a new interface to pass over dirty bits from kernel to the
userspace. Instead of using a bitmap for each memory region, the dirty ring
contains an array of dirtied GPAs to fetch (in the form of offset in slots).
For each vcpu there will be one dirty ring that binds to it.
kvm_di
Provide a helper kvm_slot_get_dirty_log() to make the function
kvm_physical_sync_dirty_bitmap() clearer. We can even cache the as_id
into KVMSlot when it is created, so that we don't even need to pass it
down every time.
Since at it, remove return value of kvm_physical_sync_dirty_bitmap()
because
Add a parameter for dirty gfn count for dirty rings. If zero, dirty ring is
disabled. Otherwise dirty ring will be enabled with the per-vcpu gfn count as
specified. If dirty ring cannot be enabled due to unsupported kernel or
illegal parameter, it'll fallback to dirty logging.
By default, dirty
Cache it too because we'll reference it more frequently in the future.
Reviewed-by: Dr. David Alan Gilbert
Signed-off-by: Peter Xu
---
accel/kvm/kvm-all.c | 1 +
include/sysemu/kvm_int.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index f
Previously we have two places that will create the per KVMSlot dirty
bitmap:
1. When a newly created KVMSlot has dirty logging enabled,
2. When the first log_sync() happens for a memory slot.
The 2nd case is lazy-init, while the 1st case is not (which is a fix
of what the 2nd case missed).
T
kvm_physical_sync_dirty_bitmap() calculates the ramblock offset in an
awkward way from the MemoryRegionSection that passed in from the
caller. The truth is for each KVMSlot the ramblock offset never
change for the lifecycle. Cache the ramblock offset for each KVMSlot
into the structure when the K
kvm_vm_ioctl() handles the errno trick already for ioctl() on
returning -1 for errors. Fix this.
Reviewed-by: Dr. David Alan Gilbert
Signed-off-by: Peter Xu
---
accel/kvm/kvm-all.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.
Some of the memory listener may want to do log synchronization without
being able to specify a range of memory to sync but always globally.
Such a memory listener should provide this new method instead of the
log_sync() method.
Obviously we can also achieve similar thing when we put the global
syn
Signed-off-by: Peter Xu
---
linux-headers/asm-x86/kvm.h | 1 +
linux-headers/linux/kvm.h | 53 +
2 files changed, 54 insertions(+)
diff --git a/linux-headers/asm-x86/kvm.h b/linux-headers/asm-x86/kvm.h
index 3f3f780c8c..99b15ce39e 100644
--- a/linux-headers
Per-kml slots_lock will bring some trouble if we want to take all slots_lock of
all the KMLs, especially when we're in a context that we could have taken some
of the KML slots_lock, then we even need to figure out what we've taken and
what we need to take.
Make this simple by merging all KML slots
I kept the dirty sync in kvm_set_phys_mem() for kvmslot removals, left a
comment on the known issue about strict dirty sync so we can fix it someday in
the future together with dirty log and dirty ring.
v3:
- added "KVM: Use a big lock to replace per-kml slots_lock"
this is preparing for the las
On Sat, May 02, 2020 at 05:04:23PM -0400, Peter Xu wrote:
> Paolo,
>
> Do you have any opinion on this series? Or more generally comments on what's
> your preference to fix the known dirty sync issue with memslot removal would
> be
> welcomed too. For my own opinion, I prefer the approach with
On Sat, May 23, 2020 at 13:20:15 -0400, Emilio G. Cota wrote:
> On Fri, May 22, 2020 at 12:07:46 -0400, Robert Foley wrote:
> > These annotations will allow us to give tsan
> > additional hints. For example, we can inform
> > tsan about reads/writes to ignore to silence certain
> > classes of warn
On Fri, May 22, 2020 at 12:07:36 -0400, Robert Foley wrote:
> This patch series continues the work done by Emilio Cota and others to add
> Thread Sanitizer (TSan) support to QEMU.
>
> The starting point for this work was Emilio's branch here:
> https://github.com/cota/qemu/commits/tsan
> specifica
On Fri, May 22, 2020 at 12:07:51 -0400, Robert Foley wrote:
> For example:
> WARNING: ThreadSanitizer: data race (pid=23406)
> Atomic read of size 4 at 0x7b13e3c8 by thread T7:
> #0 __tsan_atomic32_load (qemu-system-aarch64+0x39a36c)
> #1 qht_do_lookup util/qht.c:495:17 (qemu-system-
On Tue, Mar 17, 2020 at 03:59:08PM -0400, Peter Xu wrote:
> Sometimes it would be good to be able to read the pin number along
> with the IRQ number allocated. Since we'll dump the IRQ number, no
> reason to not dump the pin information. For example, the vfio-pci
> device will overwrite the pin w
On Tue, Apr 21, 2020 at 12:21:00PM -0400, Peter Xu wrote:
> This is a continuous work of previous discussion on memory transactions [1].
> It should be helpful to fail QEMU far earlier if there's misuse of BQL against
> the QEMU memory model.
>
> One example is run_on_cpu() during memory commit.
On Fri, May 22, 2020 at 12:07:55 -0400, Robert Foley wrote:
> This includes details on how to build and test with TSan
> both inside a docker and outside.
>
> Signed-off-by: Robert Foley
Reviewed-by: Emilio G. Cota
E.
On Fri, May 22, 2020 at 12:07:53 -0400, Robert Foley wrote:
> This allows us to see the name of the thread in tsan
> warning reports such as this:
>
> Thread T7 'CPU 1/TCG' (tid=24317, running) created by main thread at:
>
> Signed-off-by: Robert Foley
Reviewed-by: Emilio G. Cota
The code in CONV_NATURAL_FLOAT() and CLIP_NATURAL_FLOAT()
seems to use the constant 2^31-0.5 to convert float to integer
and back. But the float type lacks the required precision and
the constant used for the conversion is 2^31. This is equiva-
lent to a [-1.f, 1.f] <-> [INT32_MIN, INT32_MAX + 1] m
This is another attempt to silence the clang 10 warning in
audio/mixeng.c.
The problem was first reported here:
https://lists.nongnu.org/archive/html/qemu-devel/2020-03/msg02270.html
This is Philippe's RFC patch and a discussion:
https://lists.nongnu.org/archive/html/qemu-devel/2020-05/msg00264.h
Apparently this fixed bug is the official CVE-2020-10702:
https://security-tracker.debian.org/tracker/CVE-2020-10702
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2020-10702
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QE
On Fri, May 22, 2020 at 12:07:50 -0400, Robert Foley wrote:
> For example:
> Atomic write of size 8 at 0x7b4800113c28 by main thread (mutexes: write
> M30):
> #0 __tsan_atomic64_exchange (qemu-system-aarch64+0x386f85)
> #1 aio_bh_poll util/async.c:146:5 (qemu-system-aarch64+0xcd1f61)
>
On Fri, May 22, 2020 at 12:07:49 -0400, Robert Foley wrote:
> For example:
> WARNING: ThreadSanitizer: data race (pid=35425)
> Write of size 4 at 0x7bbc00ac by main thread (mutexes: write M875):
> #0 cpu_reset_interrupt hw/core/cpu.c:107:28 (qemu-system-aarch64+0x843790)
> #1 arm_cpu_
Public bug reported:
I've come across a very specific situation, but I'm sure it could be
replicated in other cases.
In QEMU 5.0.0 when I use user emulation with a cURL binary for aarch64
and connect to a server using TLS 1.2 and ECDHE-ECDSA-CHACHA20-POLY1305
cypher a segmentation fault occurs.
Invalid I/O writes can craft an offset out of the vram_buffer
range.
Instead of passing an unsafe pointer to artist_rop8(), pass the
vram_buffer and the offset. We can now check if the offset is
in range before accessing it.
We avoid:
Program terminated with signal SIGSEGV, Segmentation fault.
Fix various out-of-range buffer access in the artist device
emulation. Bugs found using libFuzzer (docs/devel/fuzzing.txt).
Philippe Mathieu-Daudé (3):
hw/display/artist: Check offset in draw_line to avoid buffer over-run
hw/display/artist: Refactor artist_rop8() to avoid buffer over-run
hw/
Invalid I/O writes can craft an offset out of the vram_buffer
range.
We avoid:
Program terminated with signal SIGSEGV, Segmentation fault.
284 *dst &= ~plane_mask;
(gdb) bt
#0 0x55d5dccdc5c0 in artist_rop8 (s=0x55d5defee510, dst=0x7f8e84ed8216
, val=0 '\000') at
hw/disp
Invalid I/O writes can craft an offset out of the vram_buffer
range.
We avoid:
Program terminated with signal SIGSEGV, Segmentation fault.
519 artist_rop8(s, buf, dst + column, buf->data[src +
column]);
(gdb) bt
#0 0x55fa83b05e0a in block_move (s=0x55fa8647e510, sour
On 5/23/20 8:03 PM, Philippe Mathieu-Daudé wrote:
> Public bug reported:
>
> As of commit d19f1ab0, LLVM libFuzzer found:
>
> =
> ==6814==ERROR: AddressSanitizer: heap-buffer-overflow on address
> 0x7fd89f97bd5a at pc 0x55dc44594db5
Public bug reported:
As of commit d19f1ab0, LLVM libFuzzer found:
=
==6814==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7fd89f97bd5a
at pc 0x55dc44594db5 bp 0x7ffd6f461b40 sp 0x7ffd6f461b38
READ of size 1 at 0x7fd89f9
On Fri, May 22, 2020 at 12:07:48 -0400, Robert Foley wrote:
> Initially put several files into blacklist that were
> causing the most problems, namely bitops.c and bitmap.c.
>
> Signed-off-by: Robert Foley
> ---
> configure | 3 ++-
> tests/tsan/blacklist.tsan | 5 +
> 2 file
ping?
On 5/11/20 9:03 AM, Philippe Mathieu-Daudé wrote:
> On 4/14/20 12:00 PM, KONRAD Frederic wrote:
>> Le 4/13/20 à 11:07 PM, Philippe Mathieu-Daudé a écrit :
>>> [Cc'ing Peter]
>>>
>>> On 4/13/20 12:12 PM, KONRAD Frederic wrote:
Le 4/11/20 à 7:30 PM, Philippe Mathieu-Daudé a écrit :
>
On Fri, May 22, 2020 at 12:07:47 -0400, Robert Foley wrote:
> Fixed several tsan warnings. e.g.
>
> WARNING: ThreadSanitizer: data race (pid=35425)
> Read of size 1 at 0x557cd83aee28 by thread T7:
> #0 curr_cflags include/exec/exec-all.h:460:13
> (qemu-system-aarch64+0x4b7f27)
> #1 cpu_
On Fri, May 22, 2020 at 12:07:46 -0400, Robert Foley wrote:
> These annotations will allow us to give tsan
> additional hints. For example, we can inform
> tsan about reads/writes to ignore to silence certain
> classes of warnings.
> We can also annotate threads so that the proper thread
> naming
On Fri, May 22, 2020 at 23:36:18 +0100, Peter Maydell wrote:
> So is this:
> (a) a TSan false positive, because we've analysed the use
> of this struct field and know it's not a race because
> [details], but which we're choosing to silence in this way
> (b) an actual race for which the
Hi Robert,
On 5/22/20 6:07 PM, Robert Foley wrote:
> From: Lingfeng Yang
>
> We tried running QEMU under tsan in 2016, but tsan's lack of support for
> longjmp-based fibers was a blocker:
> https://groups.google.com/forum/#!topic/thread-sanitizer/se0YuzfWazw
>
> Fortunately, thread sanitizer
Patchew URL:
https://patchew.org/QEMU/20200523132442.22538-1-cheng...@emindsoft.com.cn/
Hi,
This series failed the docker-mingw@fedora build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEG
From: Chen Gang
Another DRM_IOCTL_* commands will be done later.
Signed-off-by: Chen Gang
---
configure | 18 +++
linux-user/ioctls.h| 3 ++
linux-user/syscall.c | 61 ++
linux-user/syscall_defs.h | 15 ++
lin
Aleksandar Markovic <1880...@bugs.launchpad.net> writes:
> The problem may be in int_guest_commpage() - it returns false.
>
>>From gdb debugging session:
>
> (gdb) p addr
> $1 = (void *) 0xb7ffd000
> (gdb) p want
> $2 = (void *) 0x
> (gdb) n
> 398 if (addr != want) {
> (gdb) p qemu_h
Public bug reported:
There seems to be a translation bug in the qemu-hppa (qemu v5.0.0) emulation:
A stripped down testcase (taken from Linux kernel build) is attached.
In there is "a.sh", a shell script which calls gcc-9 (fails with both
debian gcc-9.3.0-11 or gcc-9.3.0-12). and "a.iii", the pre
** Changed in: qemu
Status: New => Confirmed
** Changed in: qemu
Assignee: (unassigned) => Alex Bennée (ajbennee)
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1880225
Title:
Emulation
The problem may be in int_guest_commpage() - it returns false.
>From gdb debugging session:
(gdb) p addr
$1 = (void *) 0xb7ffd000
(gdb) p want
$2 = (void *) 0x
(gdb) n
398 if (addr != want) {
(gdb) p qemu_host_page_size
$3 = 4096
(gdb) l
393
394 if (addr == MAP_FAILED
Aleksandar Markovic <1880...@bugs.launchpad.net> writes:
> I just want to stress once again that the test was performed on a 32-bit
> Intel host.
Ahh - OK that makes sense. I'll see if I can replicate.
--
Alex Bennée
Hi this is my first contribution hope it s useful . Regards.
>From ca7fcd85e0453f7173ce73732905463bc259ee32 Mon Sep 17 00:00:00 2001
From: David Carlier
Date: Sat, 23 May 2020 08:17:51 +0100
Subject: [PATCH] util/oslib: returns real thread identifier on FreeBSD and
NetBSD
Signed-off-by: David Ca
48 matches
Mail list logo
