[Qemu-devel] tsan: many race conditions involving mmio

What's a quick fix for stuff like this? WARNING: ThreadSanitizer: data race (pid=168036) Write of size 8 at 0x7b900017a100 by thread T1 (mutexes: write M2141): #0 free /toolchain/llvm/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:715:3 (qemu-system-x86_64+0x484028) #1

Re: [Qemu-devel] [PATCH 0/3] WHPX introduce changes for Windows Insider SDK 17110

Is this useful at all for the Android Emulator? Does it break backward compatibility for older Windows versions? On Thu, Jan 17, 2019 at 12:39 PM Stefan Weil wrote: > Am 14.03.2018 um 15:52 schrieb Justin Terry (VM) via Qemu-devel: > > This change set fixes two breaking changes that were

Re: [Qemu-devel] QEMU hangs in main_loop_wait

Also, those only happen when using the browser in the guest; leave it on a single webpage, and get these long timeouts. We are using slirp. On Tue, Oct 23, 2018 at 8:02 AM Frank Yang wrote: > We don't yet have visibility into that, but is there a way to enumerate > what callbacks are running?

Re: [Qemu-devel] QEMU hangs in main_loop_wait

We don't yet have visibility into that, but is there a way to enumerate what callbacks are running? We see that sometimes, actually qemu_poll_ns takes much, much longer than the specified timeout to return: qemu_mutex_unlock_iothread(); replay_mutex_unlock(); struct timeval tv;

[Qemu-devel] QEMU hangs in main_loop_wait

Hi all, After quite some backports, such as https://android.googlesource.com/platform/external/qemu/+/a8da859b1b011e509056f03cbcb73df27afe4337 we are not seeing hangs in flatview_do_translate, but are still getting hangs in main-loop: qemu_mutex_unlock_iothread();

Re: [Qemu-devel] Freeze / spin in virtio blk...flatview do translate

s reset if the >>> main loop runs its timers again, so no main loop iterations happened since >>> that aio_dispatch_handlers call (we use a looper abstraction for it). >>> >>> On Tue, Sep 18, 2018 at 8:56 AM Paolo Bonzini >>> wrote: >>> >&g

Re: [Qemu-devel] Freeze / spin in virtio blk...flatview do translate

ened since >> that aio_dispatch_handlers call (we use a looper abstraction for it). >> >> On Tue, Sep 18, 2018 at 8:56 AM Paolo Bonzini >> wrote: >> >>> On 15/09/2018 20:41, Frank Yang via Qemu-devel wrote: >>> > We have not reproduced this hang so

Re: [Qemu-devel] Freeze / spin in virtio blk...flatview do translate

ations happened since > that aio_dispatch_handlers call (we use a looper abstraction for it). > > On Tue, Sep 18, 2018 at 8:56 AM Paolo Bonzini wrote: > >> On 15/09/2018 20:41, Frank Yang via Qemu-devel wrote: >> > We have not reproduced this hang so far

Re: [Qemu-devel] Freeze / spin in virtio blk...flatview do translate

:41, Frank Yang via Qemu-devel wrote: > > We have not reproduced this hang so far, this is from user crash reports > > that triggered our hang detector (where 15+ seconds pass without main > loop > > / VCPU threads being able to go back and ping their loopers in main l

Re: [Qemu-devel] Freeze / spin in virtio blk...flatview do translate

And this one: https://github.com/qemu/qemu/commit/a411c84b561baa94b28165c52f21c33517ee8f59 On Sat, Sep 15, 2018 at 4:42 PM Frank Yang wrote: > I notice at least two commits in upstream QEMU that might impact this: > > >

[Qemu-devel] qemu 2.12: qemu_coroutine_switch crash on Windows in SwitchToFiber (null CoroutineWin32*?)

Hi qemu-devel, We've been having crash reports in QEMU 2.12 on the anroid emulator in SwitchToFiber that make it look like the coroutine or fiber getting switched to is null. Thread 16 (id: 0x13bc) CRASHED [EXCEPTION_ACCESS_VIOLATION_READ @ 0x0010 ] Stack Quality84%Show frame trust levels

Re: [Qemu-devel] qemu 2.12: qemu_coroutine_switch crash on Windows in SwitchToFiber (null CoroutineWin32*?)

BTW from https://bugs.launchpad.net/qemu/+bug/932487 that says gcc version is to blame, I don't think that's the case; we are using gcc 4.8 as well. Perhaps it regressed. It would be

Re: [Qemu-devel] Freeze / spin in virtio blk...flatview do translate

I notice at least two commits in upstream QEMU that might impact this: https://github.com/qemu/qemu/commit/ce3a9eaff4e5f29514dba35a001894cb7a238e07#diff-8bfe2ea13d8c6dab17a555f300ac2f66

[Qemu-devel] Freeze / spin in virtio blk...flatview do translate

Hi qemu-devel, So we're using QEMU 2.12 for recent Android Emulator canaryies, and we're seeing a lot of hangs on mac in flatview_translate in qemu 2.12. What would be some pointers for diagnosing excessive I/O? Especially, metrics to see if a system is on the verge of getting into main loop

Re: [Qemu-devel] RAMBlocks and memory_region_init_ram_nomigrate

Ah got it, thanks for the replies / info! We're using a modified QEMU 2.12, and I don't see the migratable-only loops and field, so it either got missed in the rebase or was added after 2.12. Frank On Mon, Aug 13, 2018 at 9:45 AM Dr. David Alan Gilbert wrote: > * Paolo Bonzini

Re: [Qemu-devel] [PATCH v2 02/13] hvf: add code base from Google's QEMU repository

+ our product manager If I understand correctly, we will need to reconsider things if I included any additional technology in my port. However, I didn't include any additional references/source in my port compared to Veertu, that was not in the qemu code already (e.g., hax-all/kvm-all) so I think