On Wed, Dec 2, 2020 at 2:57 PM Alexander Graf wrote:
>
> On 02.12.20 23:46, Frank Yang wrote:
>
>
>
> On Wed, Dec 2, 2020 at 2:28 PM Alexander Graf wrote:
>
>>
>> On 02.12.20 23:19, Frank Yang wrote:
>>
>>
>> From downstream:
>> https:/
On Wed, Dec 2, 2020 at 2:28 PM Alexander Graf wrote:
>
> On 02.12.20 23:19, Frank Yang wrote:
>
>
> From downstream:
> https://android-review.googlesource.com/c/platform/external/qemu/+/1515002
>
> Based on v3 of Alexander Graf's patches
>
> https://patche
bit busted,
still working on that)
On Wed, Dec 2, 2020 at 2:19 PM Frank Yang wrote:
>
> From downstream:
> https://android-review.googlesource.com/c/platform/external/qemu/+/1515002
>
> Based on v3 of Alexander Graf's patches
>
> https://patchew.org/QEMU/20201202190408.2
>From downstream:
https://android-review.googlesource.com/c/platform/external/qemu/+/1515002
Based on v3 of Alexander Graf's patches
https://patchew.org/QEMU/20201202190408.2041-1-ag...@csgraf.de
We need to adjust CNTVOFF_EL2 so that time doesnt warp. Even though we
can set separate CNTVOFF_EL2
On Mon, Nov 30, 2020 at 2:10 PM Peter Maydell
wrote:
> On Mon, 30 Nov 2020 at 20:56, Frank Yang wrote:
> > We'd actually like to contribute upstream too :) We do want to maintain
> > our own downstream though; Android Emulator codebase needs to work
> > solidly on m
https://elixir.bootlin.com/linux/v5.10-rc6/source/virt/kvm/kvm_main.c#L2766
which does seem to specify a poll interval.
It would be cool if we could have a lightweight way to enter sleep and
restart the vcpus precisely when CVAL passes, though.
Frank
On Fri, Nov 27, 2020 at 3:30 PM Frank Yang wrote:
>
Hi all,
+Peter Collingbourne
I'm a developer on the Android Emulator, which is in a fork of QEMU.
Peter and I have been working on an HVF Apple Silicon backend with an eye
toward Android guests.
We have gotten things to basically switch to Android userspace already
(logcat/shell and graphics a
So I'm not really sure why people are having issues sharing buffers that
live on the GPU. Doesn't that show up as some integer ID on the host, and
some $GuestFramework (dmabuf, gralloc) ID on the guest, and it all works
out due to maintaining the correspondence in your particular stack of
virtual d
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 phys_secti
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 introdu
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
17, 2018 at 10:03 AM Paolo Bonzini wrote:
> On 17/10/2018 17:44, Frank Yang wrote:
> >
> > we are not seeing hangs in flatview_do_translate, but are still getting
> > hangs in main-loop:
> >
> > qemu_mutex_unlock_iothread();
> > replay_mutex_unlock(
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();
replay_mutex_unlock();
(Not reproducible locally)
On Thu, Sep 20, 2018 at 7:16 AM Frank Yang wrote:
> I have added more logging code and it seems that there is a hang that
> happens with 4096 MB RAM on Mac in virtio_blk_handle_vq:
>
> #define VIRTIO_BLK_UNUSUAL_ITER_COUNT 1024
>
> bool vi
irtio queue is corrupted
if (mrb.num_reqs) {
virtio_blk_submit_multireq(s->blk, &mrb);
}
blk_io_unplug(s->blk);
aio_context_release(blk_get_aio_context(s->blk));
return progress;
}
On Tue, Sep 18, 2018 at 11:57 AM Frank Yang wrote:
> We also only get
We also only get those reports from users with 4G RAM configured, so it
could also have to do with overflow.
On Tue, Sep 18, 2018 at 11:57 AM Frank Yang wrote:
> That seems to be the case, since our 15 second detector is reset if the
> main loop runs its timers again, so no main loop iter
: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
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:
>
>
> https://github.com/qemu
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
0x0
Perhaps it regressed. It would be helpful to know what kind of TLS fixees
for windows took place for QEMU and when.
On Tue, Sep 18, 2018 at 8:09 AM Frank Yang wrote:
> Hi qemu-devel,
>
> We've been having crash reports in QEMU 2.12 on the anroid emulator in
> SwitchToFiber that
-a9288ea1a561573c7d3036de7d7048e8
On Sat, Sep 15, 2018 at 11:41 AM Frank Yang wrote:
> 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 e
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 spi
onzini (pbonz...@redhat.com) wrote:
> > On 13/08/2018 18:16, Frank Yang wrote:
> > > Hi Paolo,
> > >
> > > I see that migration/ram.c saves RAMBlocks associated with memory
> > > regions initialized with nomigrate. Is this intended?
> >
> > Probably the
think we can just change
the QEMU upstream port to use gplv2+.
Izik, are you ok with this assessment?
On Thu, Aug 31, 2017 at 2:41 PM, Sergio Andrés Gómez del Real <
sergio.g.delr...@gmail.com> wrote:
> Hello,
> Mr. Frank Yang was the guy at Google that introduced the HVF port to
&
于 2013-9-25 1:59, Michael R. Hines 写道:
On 09/04/2013 04:10 AM, Frank Yang wrote:
On 2013-9-3 13:03, Lei Li wrote:
Hi Frank,
I failed to apply this patch. Please make sure to use
git-send-email, otherwise
it's a little hard to review. :)
On 08/30/2013 08:39 PM, Frank Yang wrote:
> On 2013-9-3 13:03, Lei Li wrote:
>> Hi Frank,
>>
>> I failed to apply this patch. Please make sure to use git-send-email,
>> otherwise
>> it's a little hard to review. :)
>>
>> On 08/30/2013 08:39 PM, Frank Yang wrote:
>>> When se
On 2013-9-3 13:38, Lei Li wrote:
> On 09/03/2013 12:20 PM, Frank Yang wrote:
>> Yes, it depends on low-level implementation. During my earlier test,
>
> What do you mean by the 'it depends on low-level implementation'? Do you test
> it with IB or Ethernet?
I&#x
On 2013-9-3 22:13, Michael R. Hines wrote:
>
> No top-posting, please.
>
> On 09/03/2013 12:20 AM, Frank Yang wrote:
>> Yes, it depends on low-level implementation. During my earlier test,
>> using one CQ to send and receive may cause packet loss with heavy load:
>>
On 2013-9-3 13:03, Lei Li wrote:
> Hi Frank,
>
> I failed to apply this patch. Please make sure to use git-send-email,
> otherwise
> it's a little hard to review. :)
>
> On 08/30/2013 08:39 PM, Frank Yang wrote:
>> When several VMs migrate with RDMA at the s
x27;m not against two CQs for sending and receiving. In fact I'm for it
> because I use two CQs for postcopy RDMA support.
>
> thanks,
>
> On Fri, Aug 30, 2013 at 08:39:31PM +0800, Frank Yang wrote:
> > When several VMs migrate with RDMA at the same time, the increased
> pr
respectively.
>From 0c4829495cdc89eea2e94b103ac42c3f6a4b32c2 Mon Sep 17 00:00:00 2001
From: Frank Yang
Date: Fri, 30 Aug 2013 17:53:34 +0800
Subject: [PATCH] rdma: fix multiple VMs parallel migration
Signed-off-by: Frank Yang
---
migration-rdma.c |
31 matches
Mail list logo
