On 27.03.2018 06:37, David Gibson wrote:
> The #if isn't necessary, because there's a suitable one inside
> ppc_cpu_is_valid(). We've already filtered for suitable cpu models in the
> functions that search and register them. So by the time we get to realize
> having an invalid one indicates a cod
On Tue, Mar 27, 2018 at 11:47:57 +0800, Richard Henderson wrote:
> Failure to do so results in the tcg optimizer sign-extending
> any constant fold from 32-bits. This turns out to be visible
> in the RISC-V testsuite using a host that emits these opcodes
> (e.g. any non-x86_64).
>
> Reported-by: M
Performance results for fp-bench run under aarch64-linux-user
on an Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz host:
- before:
div-single: 30.30 MFlops
div-double: 29.59 MFlops
- after:
div-single: 94.07 MFlops
div-double: 106.79 MFlops
- w/ both using float32/64_is_normal etc.:
div-single: 94.08
Performance results for fp-bench run under aarch64-linux-user
on an aarch64 host:
- before:
fma-single: 53.05 MFlops
fma-double: 51.89 MFlops
- after:
fma-single: 110.44 MFlops
fma-double: 101.78 MFlops
- w/ both using float32/64_is_normal etc.:
fma-single: 110.57 MFlops
fma-double: 93.93 MFlops
Performance results for fp-bench run under aarch64-linux-user
on an Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz host:
- before:
cmp-single: 34.23 MFlops
cmp-double: 32.53 MFlops
- after:
cmp-single: 43.51 MFlops
cmp-double: 41.23 MFlops
Using float32/64_is_any_nan vs. isnan yields only up to a 2% p
Performance improvement for SPEC06fp for the last few commits:
qemu-aarch64 SPEC06fp (test set) speedup over QEMU
4c2c1015905
Host: Intel(R) Core(TM) i7-6700K CPU @
4.00GHz
error bars: 95
This paves the way for upcoming work.
Cc: Bastian Koppelmann
Signed-off-by: Emilio G. Cota
---
include/fpu/softfloat.h | 20
1 file changed, 20 insertions(+)
diff --git a/include/fpu/softfloat.h b/include/fpu/softfloat.h
index 36626a5..a8512fb 100644
--- a/include/fpu/soft
These are a few muladd-related operations that the original IBM syntax
does not specify; model files for these are in muladd.fptest.
Signed-off-by: Emilio G. Cota
---
tests/fp-test/fp-test.c | 24 +
tests/fp-test/muladd.fptest | 51
Note that for float32 we do most checks on the float32 and not on
the native type; for float64 we do the opposite. This is faster
than going either way for both, as shown below.
I am keeping both macro-based definitions to ease testing of
either option.
Performance results (single and double prec
This will allow us to run correctness tests against our
FP implementation. The test can be run in two modes (called
"testers"): host and soft. With the former we check the results
and FP flags on the host machine against the model.
With the latter we check QEMU's fpu primitives against the
model. N
v1: https://lists.nongnu.org/archive/html/qemu-devel/2018-03/msg05908.html
Changes from v1:
- Rename series from "hostfloat" to "hardfloat". The series already uses
"host" as an option for fp-test, so this change should make things clearer
- Rebase on top of master (4c2c101590).
- Move code f
The appended paves the way for leveraging the host FPU for a subset
of guest FP operations. For most guest workloads (e.g. FP flags
aren't ever cleared, inexact occurs often and rounding is set to the
default [to nearest]) this will yield sizable performance speedups.
The approach followed here av
Performance results for fp-bench run under aarch64-linux-user
on an Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz host:
- before:
sqrt-single: 26.61 MFlops
sqrt-double: 17.14 MFlops
- after:
sqrt-single: 95.06 MFlops
sqrt-double: 89.05 MFlops
Note that here we have a single implementation for both f3
Performance results for fp-bench run under aarch64-linux-user
on an Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz host:
- before:
mul-single: 88.37 MFlops
mul-double: 85.55 MFlops
- after:
mul-single: 115.06 MFlops
mul-double: 124.67 MFlops
- w/ both using float32/64_is_normal etc.:
mul-single: 113.4
This will allow us to measure the performance impact of FP
emulation optimizations.
Signed-off-by: Emilio G. Cota
---
tests/fp-bench.c | 334 +
tests/.gitignore | 1 +
tests/Makefile.include | 3 +-
3 files changed, 337 insertions(+
Cc: Bastian Koppelmann
Signed-off-by: Emilio G. Cota
---
target/tricore/fpu_helper.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/target/tricore/fpu_helper.c b/target/tricore/fpu_helper.c
index df16290..31df462 100644
--- a/target/tricore/fpu_helper.c
+++ b/target
Before 8936006 ("fpu/softfloat: re-factor minmax", 2018-02-21),
we used to return +Zero for maxnummag(-Zero,+Zero); after that
commit, we return -Zero.
Fix it by making {min,max}nummag consistent with {min,max}num,
deferring to the latter when the absolute value of the operands
is the same.
With
From: Anton Nefedov
commit 947858b0 "ide: abort TRIM operation for invalid range"
is incorrect for macio; just ide_dma_error() without doing a callback
is not enough for that errorpath.
Instead, pass -EINVAL to the callback and handle it there
(see related motivation for read/write in 58ac32113)
The following changes since commit 7b93d78a04aa242d377ae213b79db6c319c71847:
Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging
(2018-03-26 15:17:25 +0100)
are available in the Git repository at:
https://github.com/jnsnow/qemu.git tags/ide-pull-request
for you to
From: Mark Cave-Ayland
Commit ef0e64a983 "ide: pass IDEState to trim AIO callback" changed the
IDE trim callback from using a BlockBackend to an IDEState but forgot to update
the dma_blk_io() call in hw/ide/macio.c accordingly.
Without this fix qemu-system-ppc segfaults when issuing an IDE trim
The only place we test this flag is in conjunction with
ppc64_use_proc_tbl(). That checks for the LPCR_UPRT bit, which we already
ensure can't be set except on a machine with a v3 MMU (i.e. POWER9).
Signed-off-by: David Gibson
---
target/ppc/cpu-qom.h| 4 +---
target/ppc/mmu-hash64.c | 2 +-
These macros were introduced to deal with the fact that the mmu_model
field has bit flags mixed in with what's otherwise an enum of various mmu
types.
We've now eliminated all those flags except for one, and that one -
POWERPC_MMU_64 - is already included/compared in the MMU_VER macros. So,
we ca
Currently env->mmu_model is a bit of an unholy mess of an enum of distinct
MMU types, with various flag bits as well. This makes which bits of the
field should be compared pretty confusing.
Make a start on cleaning that up by moving two of the flags bits -
POWERPC_MMU_1TSEG and POWERPC_MMU_AMR -
Currently some cpus set the hash64_opts field in the class structure, with
specific details of their variant of the 64-bit hash mmu. For the
remaining cpus with that mmu, ppc_hash64_realize() fills in defaults.
But there are only a couple of cpus that use those fallbacks, so just have
them to set
env->sps contains page size encoding information as an embedded structure.
Since this information is specific to 64-bit hash MMUs, split it out into
a separately allocated structure, to reduce the basic env size for other
cpus. Along the way we make a few other cleanups:
* Rename to PPCHash64
The ci_large_pages boolean in CPUPPCState is only relevant to 64-bit hash
MMU machines, indicating whether it's possible to map large (> 4kiB) pages
as cache-inhibitied (i.e. for IO, rather than memory). Fold it as another
flag into the PPCHash64Options structure.
Signed-off-by: David Gibson
---
Because of the various hooks called some variant on "init" - and the rather
greater number that used to exist, I'm always wondering when a function
called simply "*_init" or "*_initfn" will be called.
To make it easier on myself, and maybe others, rename the instance_init
hooks for ppc cpus to *_i
Initialization of the env->sps structure at the end of instance_init is
specific to the 64-bit hash MMU, so move the code into a helper function
in mmu-hash64.c.
We also create a corresponding function to be called at finalize time -
it's empty for now, but we'll need it shortly.
Signed-off-by: D
CPU definitions for cpus with the 64-bit hash MMU can include a table of
available pagesizes. If this isn't supplied ppc_cpu_instance_init() will
fill it in a fallback table based on the POWERPC_MMU_64K bit in mmu_model.
However, it turns out all the cpus which support 64K pages already include
a
As a rule we prefer to pass PowerPCCPU instead of CPUPPCState, and this
change will make some things simpler later on.
Signed-off-by: David Gibson
---
hw/ppc/fdt.c | 5 +++--
hw/ppc/pnv.c | 4 ++--
hw/ppc/spapr.c | 4 ++--
include/hw/ppc/fdt.h | 2 +-
4 files changed, 8 ins
The #if isn't necessary, because there's a suitable one inside
ppc_cpu_is_valid(). We've already filtered for suitable cpu models in the
functions that search and register them. So by the time we get to realize
having an invalid one indicates a code error, not a user error, so an
assert() is more
In most cases we prefer to pass a PowerPCCPU rather than the (embedded)
CPUPPCState.
For ppc_hash64_update_{rmls,vrma}() change to take "cpu" instead of "env".
For ppc_hash64_set_{dsi,isi}() remove the redundant "env" parameter.
In theory this makes more work for the functions, but since "cs", "c
Here's a set of cleanups for the ppc cpu code. Most are related
specifically to the 64-bit hash MMU, but there are some others as
well.
In particular it establishes a new structure PPCHash64Options which
contains details of the hash64 mmu which can vary from one cpu to
another. This attempts to
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1187334
Title:
crash on ho
Used_memslots is shared by vhost kernel and user, it is equal to
dev->mem->nregions, which is correct for vhost kernel, but not for
vhost user, the latter one uses memory regions that have file
descriptor. E.g. a VM has a vhost-user NIC and 8(vhost user memslot
upper limit) memory slots, it will be
Failure to do so results in the tcg optimizer sign-extending
any constant fold from 32-bits. This turns out to be visible
in the RISC-V testsuite using a host that emits these opcodes
(e.g. any non-x86_64).
Reported-by: Michael Clark
Signed-off-by: Richard Henderson
---
tcg/tcg-opc.h | 4 ++--
On Mon, 26 Mar 2018 15:26:39 +0800
Fam Zheng wrote:
> On Thu, 03/22 09:19, Daniel Henrique Barboza wrote:
> > Hi,
> >
> > On 03/22/2018 04:38 AM, Fam Zheng wrote:
> > > Some backends report big max_io_sectors. Making min_io_size the same
> > > value in this case will make it impossible for gue
On 03/26/2018 05:02 PM, Peter Xu wrote:
On Thu, Mar 22, 2018 at 07:38:07PM +0800, Xiao Guangrong wrote:
On 03/21/2018 04:19 PM, Peter Xu wrote:
On Fri, Mar 16, 2018 at 04:05:14PM +0800, Xiao Guangrong wrote:
Hi David,
Thanks for your review.
On 03/15/2018 06:25 PM, Dr. David Alan Gilber
On 03/27/2018 08:26 AM, Michael Clark wrote:
> IN:
> 0x00011138: 82b7 lui t0,-2147483648
> 0x0001113c: 8337 lui t1,-32768
> 0x00011140: 0262a433 mulhsu s0,t0,t1
> 0x00011144: 84b7 lu
在 2018/3/26 18:29, Kevin Wolf 写道:
Am 23.03.2018 um 04:43 hat QingFeng Hao geschrieben:
Test case 185 failed since commit 4486e89c219 --- "vl: introduce vm_shutdown()".
It's because of the newly introduced function vm_shutdown calls bdrv_drain_all,
which is called later by bdrv_close_all. bdrv_
在 2018/3/23 18:04, Stefan Hajnoczi 写道:
On Fri, Mar 23, 2018 at 3:43 AM, QingFeng Hao wrote:
Test case 185 failed since commit 4486e89c219 --- "vl: introduce vm_shutdown()".
It's because of the newly introduced function vm_shutdown calls bdrv_drain_all,
which is called later by bdrv_close_all.
On Fri, 03/23 15:32, Laurent Vivier wrote:
> Re-run Coccinelle script scripts/coccinelle/qobject.cocci
>
> Signed-off-by: Laurent Vivier
This time for the right revision of the patch:
Acked-by: Fam Zheng
On Thu, 03/22 17:12, Laurent Vivier wrote:
> Re-run Coccinelle script scripts/coccinelle/qobject.cocci
>
> Signed-off-by: Laurent Vivier
Acked-by: Fam Zheng
On Mon, Mar 26, 2018 at 08:36:16PM -0500, Eric Blake wrote:
> This is patches 2, 3, 7, and 8 (with 7 rewritten) from Peter Xu's
> series. I've pushed them to git://repo.or.cz/qemu/ericb.git qapi-next
> (on top of the other pending qapi patches at branch qapi); hopefully
> this will be part of my p
On Mon, Mar 26, 2018 at 02:42:23PM -0500, Eric Blake wrote:
> On 03/26/2018 01:38 AM, Peter Xu wrote:
> > Marc-André Lureau reported that we can have this happen:
> >
> > 1. client1 connects, send command C1
> > 2. client1 disconnects before getting response for C1
> > 3. client2 connects, who mig
On Mon, Mar 26, 2018 at 12:18:28PM +0200, Christian Borntraeger wrote:
> Thanks for the quick fixing. This series on top of master
> works fine on s390. (make check and iotests)
Appreciate the quick follow up. Thanks Christian.
--
Peter Xu
>From 1ba3070160d5baab73ba9e500ed58d0ace7121aa Mon Sep 17 00:00:00 2001
From: Steven Seeger
Date: Mon, 26 Mar 2018 20:50:53 -0400
Subject: [PATCH 2/6] leon3: add smp cpu index to asr17
Signed-off-by: Steven Seeger
---
target/sparc/helper.c| 5 +
target/sparc/helper.h| 1 +
target/sp
>From f512606776e20dc603b8ea3faaeb103667de3178 Mon Sep 17 00:00:00 2001
From: Steven Seeger
Date: Sun, 25 Mar 2018 17:58:21 -0400
Subject: [PATCH 1/6] leon3: change the handling for ASI_LEON_NOCACHE to be
aware of if the MMU is enabled or not
Signed-off-by: Steven Seeger
---
target/sparc/trans
On Mon, Mar 26, 2018 at 12:47:39PM +0200, Kevin Wolf wrote:
> Am 26.03.2018 um 08:11 hat Peter Xu geschrieben:
> > If there are more than one events, wait_until_completed() might return
> > the 2nd event even if the 1st event is JOB_COMPLETED, since the for loop
> > will continue to run even if com
From: Peter Xu
Marc-André Lureau reported that we can have this happen:
1. client1 connects, send command C1
2. client1 disconnects before getting response for C1
3. client2 connects, who might receive response of C1
However client2 should not receive remaining responses for client1.
Basically
From: Peter Xu
Add new parameter to optionally enable Out-Of-Band for a QMP server.
An example command line:
./qemu-system-x86_64 -chardev stdio,id=char0 \
-mon chardev=char0,mode=control,x-oob=on
By default, Out-Of-Band is off.
It is not allowed if either MUX or non-
From: Peter Xu
Test the new OOB capability. It's mostly the reverted OOB test
(see commit 4fd78ad7), but differs in that:
- It uses the new qtest_init_without_qmp_handshake() parameter to
create the monitor with "x-oob"
- Squashed the capability tests on greeting message
- Don't use qtest_glob
Allow callers to choose whether to allow OOB support during a test;
for now, all existing callers pass false, but the next patch will
add a new caller. Also, rewrite the monitor setup to be generic
(using the -qmp shorthand is insufficient for honoring the parameter).
Based on an idea by Peter Xu
This is patches 2, 3, 7, and 8 (with 7 rewritten) from Peter Xu's
series. I've pushed them to git://repo.or.cz/qemu/ericb.git qapi-next
(on top of the other pending qapi patches at branch qapi); hopefully
this will be part of my pull request tomorrow for -rc1.
Eric Blake (1):
tests: Add paramet
What is quite fascinating is that it appears that TCG constant folding is
causing the mulhsu test to fail, not the TCG backend, which suggests either
a RISC-V front-end bug or a TCG middle-end bug. Anyway, it's odd.
Below are the mulhsu tests. Note TEST_RR_OP 7 is the test that is failing.
I thoug
On Mon, Mar 26, 2018 at 4:14 PM, Michael Clark wrote:
>
>
> On Mon, Mar 26, 2018 at 11:07 AM, Michael Clark wrote:
>
>>
>>
>> On Sun, Mar 25, 2018 at 8:03 AM, Peter Maydell
>> wrote:
>>
>>> On 24 March 2018 at 18:13, Michael Clark wrote:
>>> > This is a series of bug fixes and code cleanups th
On Mon, Mar 26, 2018 at 11:07 AM, Michael Clark wrote:
>
>
> On Sun, Mar 25, 2018 at 8:03 AM, Peter Maydell
> wrote:
>
>> On 24 March 2018 at 18:13, Michael Clark wrote:
>> > This is a series of bug fixes and code cleanups that we would
>> > like to get in before the QEMU 2.12 release. We are r
On 03/26/2018 01:38 AM, Peter Xu wrote:
I suppose these are all good even for 2.12, so marked in subject.
Tested with "make check" for all targets on x86_64, and iotest -raw.
Patch 1 fixes one OOB error message regression reported by Marc-Andre.
Patch 2 fixes one potential OOB problem when more
On Sun, Mar 25, 2018 at 5:47 AM, Peter Maydell
wrote:
> On 25 March 2018 at 00:23, Michael Clark wrote:
> >
> >
> > On Sat, Mar 24, 2018 at 2:23 PM, Peter Maydell >
> > wrote:
> >>
> >> On 24 March 2018 at 18:13, Michael Clark wrote:
> >> > The sifive_u machine already marks its ROM readonly.
On 03/26/2018 01:33 PM, Eric Blake wrote:
On 03/26/2018 12:20 PM, Marc-André Lureau wrote:
Apparently introduced in commit a4f90923b520f1dc0a768634877eb412e5052c26.
Signed-off-by: Marc-André Lureau
---
tests/qmp-test.c | 1 +
1 file changed, 1 insertion(+)
Reviewed-by: Eric Blake
I'll q
On 03/26/2018 01:39 AM, Peter Xu wrote:
It is abstracted from qtest_init_without_qmp_handshake(). It works just
like qtest_init_without_qmp_handshake() but further it would allow the
caller to specify the QMP parameter.
Signed-off-by: Peter Xu
---
tests/libqtest.c | 14 +++---
tests/
On Mon, Mar 26, 2018 at 12:16 PM, Laurent Vivier wrote:
> No code change, only move code from main.c to
> riscv/cpu_loop.c.
>
> Signed-off-by: Laurent Vivier
>
Reviewed-by: Michael Clark
> ---
> linux-user/main.c | 101 +-
> --
> linux-user/
ository at:
git://github.com/OSLL/qemu-xtensa.git tags/20180326-xtensa
for you to fetch changes up to d0ce7e9cfc8eda113f872b608fe4a3dd7662997e:
target/xtensa: fix timers test (2018-03-26 14:17:04 -0700)
target/xtensa fixe
On 03/26/2018 01:39 AM, Peter Xu wrote:
Test the new OOB capability. It's mostly the reverted OOB test, but
Helpful to mention which commit id has the reverts you are restoring.
Looks like 4fd78ad. Are you also restoring the tests reverted in cc79760
and a4f9092?
differs in that:
- It use
On 03/26/2018 01:39 AM, Peter Xu wrote:
It is abstracted from qtest_init_without_qmp_handshake(). It works just
like qtest_init_without_qmp_handshake() but further it would allow the
caller to specify the QMP parameter.
Signed-off-by: Peter Xu
---
tests/libqtest.c | 14 +++---
tests/
On 2018-02-28 14:13, Max Reitz wrote:
> Fully preallocated truncation has a 50 % chance of working on images
> files over file-posix. It works if $SIZE % 4G < 2G, and it fails
> otherwise. To make things even more interesting, often you would not
> even notice because qemu reported success even t
On 03/26/2018 01:38 AM, Peter Xu wrote:
It simply tests the new OOB capability, and make sure the QAPISchema can
parse it correctly.
Signed-off-by: Peter Xu
---
tests/Makefile.include | 1 +
tests/qapi-schema/oob-test.err | 1 +
tests/qapi-schema/oob-test.exit
From: Vladimir Sementsov-Ogievskiy
Shared migration for dirty bitmaps is fixed by previous patches,
so we can enable the test.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Message-id: 20180320170521.32152-5-vsement...@virtuozzo.com
Signed-off-by: Max Reitz
---
tests/qemu-iotests/169 | 8 ++
From: Vladimir Sementsov-Ogievskiy
Add version of qcow2_reopen_bitmaps_rw, which do the same work but
also return a hint about was header updated or not. This will be
used in the following fix for bitmaps reloading after migration.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: John S
From: yuchenlin
VMDK has a hard limitation of extent size, which is due to the size of grain
table entry is 32 bits. It means it can only point to a grain located at
offset = 2^32. To avoid writing the user data beyond limitation and record a
useless offset
in grain table. We should return ERROR
The following changes since commit 7b93d78a04aa242d377ae213b79db6c319c71847:
Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging
(2018-03-26 15:17:25 +0100)
are available in the Git repository at:
git://github.com/XanClic/qemu.git tags/pull-block-2018-03-26
for yo
From: Vladimir Sementsov-Ogievskiy
On reopen with existing bitmaps, instead of loading bitmaps, lets
reopen them if needed. This also fixes bitmaps migration through
shared storage.
Consider the case. Persistent bitmaps are stored on bdrv_inactivate.
Then, on destination process_incoming_migratio
On 03/26/2018 04:10 AM, Marc-André Lureau wrote:
Hi
On Mon, Mar 26, 2018 at 8:38 AM, Peter Xu wrote:
Add new parameter to optionally enable Out-Of-Band for a QMP server.
An example command line:
./qemu-system-x86_64 -chardev stdio,id=char0 \
-mon chardev=char0,mode
On Sun, Mar 25, 2018 at 11:33:01AM +0800, Wanpeng Li wrote:
> 2018-03-24 4:18 GMT+08:00 Eduardo Habkost :
> > On Fri, Mar 16, 2018 at 07:36:42AM -0700, Wanpeng Li wrote:
> >> From: Wanpeng Li
> >>
> >> This patch adds support for KVM_CAP_X86_DISABLE_EXITS. Provides userspace
> >> with
> >> per-VM
On 03/26/2018 04:11 AM, Marc-André Lureau wrote:
On Mon, Mar 26, 2018 at 8:38 AM, Peter Xu wrote:
It was missed in the first version of OOB series. We should check this
to make sure we throw the right error when fault value is passed in.
Signed-off-by: Peter Xu
Not exactly required imho, b
On 03/26/2018 01:38 AM, Peter Xu wrote:
Marc-André Lureau reported that we can have this happen:
1. client1 connects, send command C1
2. client1 disconnects before getting response for C1
3. client2 connects, who might receive response of C1
However client2 should not receive remaining response
On 03/26/2018 01:38 AM, Peter Xu wrote:
When someone sents a command before QMP handshake, error was like this:
s/sents/sends/
s/error was/the error used to be/
{"execute": "query-cpus"}
{"error": {"class": "CommandNotFound", "desc":
"Expecting capabilities negotiation with
On 03/26/2018 10:08 AM, Marc-André Lureau wrote:
The following qdict_put() line does replace the value, as the
documentation says.
Signed-off-by: Marc-André Lureau
---
monitor.c | 1 -
1 file changed, 1 deletion(-)
This patch is unneeded once Peter's change lands:
https://lists.gnu.org/arc
No code change, only move code from main.c to
mips/cpu_loop.c.
Include mips/cpu_loop.c in mips64/cpu_loop.c
to avoid to duplicate code.
Signed-off-by: Laurent Vivier
---
linux-user/main.c| 725 ---
linux-user/mips/cpu_loop.c | 723 ++
No code change, only move code from main.c to
hppa/cpu_loop.c.
Signed-off-by: Laurent Vivier
---
linux-user/hppa/cpu_loop.c | 185 ++
linux-user/main.c | 194 +
2 files changed, 186 insertions(+), 193 de
No code change, only move code from main.c to
microblaze/cpu_loop.c.
Signed-off-by: Laurent Vivier
---
linux-user/main.c| 155 ---
linux-user/microblaze/cpu_loop.c | 150 +
2 files changed, 150 insertions(+),
No code change, only move code from main.c to
tilegx/cpu_loop.c.
Signed-off-by: Laurent Vivier
---
linux-user/main.c| 267 ---
linux-user/tilegx/cpu_loop.c | 260 +
2 files changed, 260 insertions(+), 267
No code change, only move code from main.c to
xtensa/cpu_loop.c.
Signed-off-by: Laurent Vivier
---
linux-user/main.c| 247 ---
linux-user/xtensa/cpu_loop.c | 238 +
2 files changed, 238 insertions(+), 247
No code change, only move code from main.c to
alpha/cpu_loop.c.
Signed-off-by: Laurent Vivier
---
linux-user/alpha/cpu_loop.c | 199 ++
linux-user/main.c | 204
2 files changed, 199 insertions(+), 204
No code change, only move code from main.c to
i386/cpu_loop.c.
Include i386/cpu_loop.c in x86_64/cpu_loop.c
to avoid to duplicate code.
Signed-off-by: Laurent Vivier
---
linux-user/i386/cpu_loop.c | 343 ++
linux-user/main.c| 348 +--
No code change, only move code from main.c to
m68k/cpu_loop.c.
Signed-off-by: Laurent Vivier
---
linux-user/m68k/cpu_loop.c | 144 +++
linux-user/main.c | 150 +
2 files changed, 145 insertions(+), 149 d
No code change, only move code from main.c to
s390x/cpu_loop.c.
Signed-off-by: Laurent Vivier
---
linux-user/main.c | 146
linux-user/s390x/cpu_loop.c | 139 +
2 files changed, 139 insertions(+), 146 d
No code change, only move code from main.c to
riscv/cpu_loop.c.
Signed-off-by: Laurent Vivier
---
linux-user/main.c | 101 +---
linux-user/riscv/cpu_loop.c | 92
2 files changed, 93 insertions(+), 100 del
Create a cpu_loop-common.h for future use by
these new files and use it in the existing
main.c
Introduce target_cpu_copy_regs():
declare the function in cpu_loop-common.h
and an empty function for each target,
to move all the cpu_loop prologues to this function.
Signed-off-by: Laurent Vivier
---
No code change, only move code from main.c to
sh4/cpu_loop.c.
Signed-off-by: Laurent Vivier
---
linux-user/main.c | 90 ---
linux-user/sh4/cpu_loop.c | 85
2 files changed, 85 insertions(+), 90 delet
No code change, only move code from main.c to
cris/cpu_loop.c.
Signed-off-by: Laurent Vivier
---
linux-user/cris/cpu_loop.c | 89 +
linux-user/main.c | 90 --
2 files changed, 89 insertions(+), 90 de
No code change, only move code from main.c to
sparc/cpu_loop.c.
Include sparc/cpu_loop.c in sparc64/cpu_loop.c
to avoid to duplicate code.
Signed-off-by: Laurent Vivier
---
linux-user/main.c | 288 +-
linux-user/sparc/cpu_loop.c | 280 ++
No code change, only move code from main.c to
nios2/cpu_loop.c.
Signed-off-by: Laurent Vivier
---
linux-user/main.c | 133
linux-user/nios2/cpu_loop.c | 126 +
2 files changed, 126 insertions(+), 133 d
No code change, only move code from main.c to
arm/cpu_loop.c and duplicate some macro
defined for both arm and aarch64.
Signed-off-by: Laurent Vivier
---
linux-user/arm/cpu_loop.c | 430 +
linux-user/main.c | 433 +--
No code change, only move code from main.c to
ppc/cpu_loop.c.
Signed-off-by: Laurent Vivier
---
linux-user/main.c | 560 +-
linux-user/ppc/cpu_loop.c | 553 +
2 files changed, 554 insertions(+), 559 d
This series moves from main.c the architecture specific parts
to the architecture directory.
This is the continuation of my series
"linux-user: move arch specific parts to arch directories"
that includes since the v2 only the signal.c parts.
For each architecture, there are two parts:
- cpu_
No code change, only move code from main.c to
aarch64/cpu_loop.c and duplicate some macro
defined for both arm and aarch64.
Signed-off-by: Laurent Vivier
---
linux-user/aarch64/cpu_loop.c | 156 ++
linux-user/main.c | 109 +-
No code change, only move code from main.c to
openrisc/cpu_loop.c.
Signed-off-by: Laurent Vivier
---
linux-user/main.c | 96 --
linux-user/openrisc/cpu_loop.c | 89 +++
2 files changed, 89 insertions(+), 96
On 03/26/2018 02:56 PM, Max Filippov wrote:
> The value of CCOUNT special register is calculated as time elapsed
> since CCOUNT == 0 multiplied by the core frequency. In icount mode time
> increment between consecutive instructions that don't involve time
> warps is constant, but unless the result
On 03/26/2018 03:41 PM, Eric Blake wrote:
> The list did not author any patches, but it does rewrite the
> 'From:' header of messages sent from any domain with restrictive
> SPF policies that would otherwise prevent the message from reaching
> all list recipients. If a maintainer is not careful to
1 - 100 of 295 matches
Mail list logo
