qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] RFC: ARM Semihosting, PMU, and BBV Changes


From: Peter Maydell
Subject: Re: [Qemu-devel] RFC: ARM Semihosting, PMU, and BBV Changes
Date: Tue, 11 Aug 2015 16:27:00 +0100

On 5 August 2015 at 17:51, Christopher Covington <address@hidden> wrote:
> This series is a jumble of changes that I have found useful for
> creating samples of long-running applications. I do not expect any of
> these patches to be merged upstream as-is but I'm publishing them as a
> way to ask for high-level feedback, as there may very well be much
> better ways to achieve the same goal. These changes are based on
> commit 1fd1a2cc182d4e331acd92c2cdbb52b3e78c040e.

Hi. Thanks for sending these patches. However, I'm afraid
this is not an approach likely to produce a lot of useful
feedback, because it's generally a fairly tedious task to
sort through a mess of patches which (a) address several
different issues (b) might not apply to current master
(c) might even be fixed already in master (d) have not
had the necessary cleanup effort applied to convert them
from a jumble to a coherent patchset.

The commit hash you quote is not one from mainline, by the way.

> While the patches are in chronological order, their functionality can
> roughly be put in the following categories:
>
> A) Functional fixes
> B) Guest->emulator/host communication
> C) Instrumentation/profiling capabilities
>
> A) Patches 3, 4, 5, and 13 can perhaps be categorized as functional
> fixes. They may be fixed on the current tip. As a write this, I'm
> thinking this category may be the best one to target for initial
> upstreaming.

Yes, if you have specific bugfixes, these are best handled by
producing patches which apply to master and sending them
individually (or as small patchsets, if several patches form
a coherent collection).

> B) Patches 1, 2, and 11 implement communications mechanisms. We have
> used Angel semihosting and "magic exceptions" to perform various kinds
> of guest to emulator and guest to host communication. Since these
> patches were originally developed, I've been able to reduce or remove
> our need for them, but if anyone has suggestions on better ways to not
> need to communicate in the first place or use existing mechanisms to
> communicate, that'd be appreciated. As an example, we previously used
> semihosting open(), read(), and write() calls for host filesystem
> access, but have been able to replace those by mounting a VirtIO-MMIO
> 9P filesystem. Another example is using poweroff, which ends up making
> a PSCI call, to end the run, rather than a custom executable that
> makes a semihosting exit call.

For semihosting, we should just implement all of the AArch64
semihosting API. This shouldn't be terribly difficult -- you
sent a patchset a while back which is a good place to start.
I've been meaning to pick that up and just fix up the other
semihosting calls.

> C) The instrumentation implemented in patches 6, 7, 8, 9, 10, 12, and
> 14 allow us to measure instruction counts and "block vectors", with
> the primary application of running the offline SimPoint algorithm [1]
> on the collected block vectors and dumping application level
> checkpoints using CRIU [2] in a second pass.

Instrumentation is tricky because it's a "large project":
it needs a coherent framework in place in QEMU to allow
target frontends to use it, users to runtime enable and
disable it, it needs to not hurt performance when tracing
is disabled, and so on. In principle I'm definitely in
favour of QEMU improving in this area though -- it's
quite a common user use-case request...

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]