Re: [Qemu-devel] [Qemu devel v5 PATCH 0/5] Add support for Smartfusion2 SoC

Hi Peter, On Mon, Jul 3, 2017 at 2:30 AM, Peter Maydell wrote: > On 2 July 2017 at 18:39, sundeep subbaraya wrote: > > I figured out that systick uses cpu clock as clock source and > > system_clock_scale > > need to be set in msf2-soc.c. There

[Qemu-devel] [Qemu devel v6 PATCH 5/5] msf2: Add Emcraft's Smartfusion2 SOM kit.

Emulated Emcraft's Smartfusion2 System On Module starter kit. Signed-off-by: Subbaraya Sundeep --- hw/arm/Makefile.objs | 1 + hw/arm/msf2-som.c| 94 2 files changed, 95 insertions(+) create mode 100644

[Qemu-devel] [Qemu devel v6 PATCH 4/5] msf2: Add Smartfusion2 SoC.

Smartfusion2 SoC has hardened Microcontroller subsystem and flash based FPGA fabric. This patch adds support for Microcontroller subsystem in the SoC. Signed-off-by: Subbaraya Sundeep --- default-configs/arm-softmmu.mak | 1 + hw/arm/Makefile.objs| 1 +

[Qemu-devel] [Qemu devel v6 PATCH 3/5] msf2: Add Smartfusion2 SPI controller

Modelled Microsemi's Smartfusion2 SPI controller. Signed-off-by: Subbaraya Sundeep --- hw/ssi/Makefile.objs | 1 + hw/ssi/mss-spi.c | 414 +++ include/hw/ssi/mss-spi.h | 62 +++ 3 files changed, 477

[Qemu-devel] [Qemu devel v6 PATCH 0/5] Add support for Smartfusion2 SoC

Hi Qemu-devel, I am trying to add Smartfusion2 SoC. SoC is from Microsemi and System on Module(SOM) board is from Emcraft systems. Smartfusion2 has hardened Microcontroller(Cortex-M3)based Sub System and FPGA fabric. At the moment only system timer, sysreg and SPI controller are modelled.

[Qemu-devel] [Qemu devel v6 PATCH 2/5] msf2: Microsemi Smartfusion2 System Register block.

Added Sytem register block of Smartfusion2. This block has PLL registers which are accessed by guest. Signed-off-by: Subbaraya Sundeep --- hw/misc/Makefile.objs | 1 + hw/misc/msf2-sysreg.c | 200 ++

[Qemu-devel] [Qemu devel v6 PATCH 1/5] msf2: Add Smartfusion2 System timer

Modelled System Timer in Microsemi's Smartfusion2 Soc. Timer has two 32bit down counters and two interrupts. Signed-off-by: Subbaraya Sundeep --- hw/timer/Makefile.objs | 1 + hw/timer/mss-timer.c | 261 +++

Re: [Qemu-devel] [PATCH] target/ppc: Only set PCR in kvm if actually in a compat mode

On Fri, 2017-06-30 at 14:03 +1000, David Gibson wrote: > On Thu, Jun 29, 2017 at 02:59:39PM +1000, Suraj Jitindar Singh wrote: > > The Processor Compatibility Register (PCR) I used to set the > > compatibility mode of the processor using the SET_ONE_REG ioctl on > > KVM_REG_PPC_ARCH_COMPAT.

[Qemu-devel] [PATCH 3/4] doc: add item for "-M enforce-config-section"

It's never documented, and now we have one more parameter for it (which means this one can be obsolete in the future). Document it properly. Although now when enforce-config-section is set, it'll override the other "-global" parameter, that is not necessarily a rule. Forbid that usage in the

[Qemu-devel] [PATCH 2/4] vl: move global property, migrate init earlier

Currently drive_init_func() may call migrate_get_current() while the migrate object is still not ready yet at that time. Move the migration object init earlier, along with the global properties, right after acceleration init. This fixes a breakage for iotest 055, which caused an assertion

[Qemu-devel] [PATCH 1/4] migration: fix handling for --only-migratable

MigrateState object is not ready at that time, so we'll get an assertion. Use qemu_global_option() instead. Reported-by: Eduardo Habkost Suggested-by: Eduardo Habkost Fixes: 3df663e ("migration: move only_migratable to MigrationState") Signed-off-by:

[Qemu-devel] [PATCH 4/4] doc: update TYPE_MIGRATION documents

[Peter collected Eduardo's patch comment and formatted into patch] Suggested-by: Eduardo Habkost Signed-off-by: Peter Xu --- migration/migration.c | 15 +-- 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/migration/migration.c

[Qemu-devel] [PATCH 0/4] migration: fix iotest 055, only-migratable break

Two breakage introduced during the migration objectify series: one for --only-migratable, another one for iotest 055. First two patches fixes the breakages. Latter two are documentation updates suggested by Eduardo. Please review. Thanks. Peter Xu (4): migration: fix handling for

Re: [Qemu-devel] [PATCH v6 04/10] migration: let MigrationState be a qdev

On Fri, Jun 30, 2017 at 03:57:23PM +0200, Max Reitz wrote: > On 2017-06-30 15:05, Eric Blake wrote: > > On 06/30/2017 07:33 AM, Max Reitz wrote: > > > >>> The assertion is caused by migrate_add_blocker() called before > >>> initialization of migration object. I'll fix it. > >> > >> Thanks!

Re: [Qemu-devel] [PULL 04/14] migration: let MigrationState be a qdev

On Fri, Jun 30, 2017 at 04:27:46PM -0500, Eric Blake wrote: > On 06/30/2017 04:18 PM, Philippe Mathieu-Daudé wrote: > > Hi Peter, Juan, > > > > On 06/28/2017 08:30 AM, Juan Quintela wrote: > >> From: Peter Xu > >> > >> Let the old man "MigrationState" join the object family.

[Qemu-devel] [Bug 1701974] [NEW] pwrite does not work right under qemu-sh4

Public bug reported: The pwrite system call has no effect when writing to a non-zero file position, in a program running under qemu-sh4 (version 2.9.0). How to reproduce: - Compile the program: sh4-linux-gnu-gcc-5 -O -Wall -static -o test-pwrite test-pwrite.c - Set environment variable for

[Qemu-devel] [Bug 1701973] Re: pread does not work right under qemu-sh4

In case it matters: My host platform is Linux/x86_64. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1701973 Title: pread does not work right under qemu-sh4 Status in QEMU: New Bug description:

[Qemu-devel] [Bug 1701974] Re: pwrite does not work right under qemu-sh4

In case it matters: My host platform is Linux/x86_64. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1701974 Title: pwrite does not work right under qemu-sh4 Status in QEMU: New Bug

[Qemu-devel] [Bug 1701974] Re: pwrite does not work right under qemu-sh4

** Attachment added: "Statically linked compiled test program" https://bugs.launchpad.net/qemu/+bug/1701974/+attachment/4908132/+files/test-pwrite -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU.

[Qemu-devel] [Bug 1701973] Re: pread does not work right under qemu-sh4

** Attachment added: "Statically linked compiled test program" https://bugs.launchpad.net/qemu/+bug/1701973/+attachment/4908130/+files/test-pread -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU.

[Qemu-devel] [Bug 1701973] [NEW] pread does not work right under qemu-sh4

Public bug reported: The pread system call returns a wrong value in some case, in a program running under qemu-sh4 (version 2.9.0). How to reproduce: - Compile the program: sh4-linux-gnu-gcc-5 -O -Wall -static -o test-pread test-pread.c - Set environment variable for using qemu-sh4 (actually

[Qemu-devel] [Bug 1701971] Re: multithreading not working right under qemu user mode for sh4

Another gnulib test (test-lock) fails with an assertion inside glibc: test-lock: pthread_mutex_lock.c:81: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed. qemu: uncaught target signal 6 (Aborted) - core dumped Based on this, I would speculate that the problem is in the qemu

[Qemu-devel] [Bug 1701971] [NEW] multithreading not working right under qemu user mode for sh4

Public bug reported: In a multithreaded program running under qemu-sh4 (version 2.9.0), thread termination and/or pthread_join is not working right. The attached program works natively on all kinds of platforms, and under qemu user mode emulation for at least alpha, armelhf, aarch64,

[Qemu-devel] [Bug 1701971] Re: multithreading not working right under qemu user mode for sh4

** Attachment added: "Compiled test program" https://bugs.launchpad.net/qemu/+bug/1701971/+attachment/4908118/+files/test-tls -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1701971 Title:

Re: [Qemu-devel] [PATCH v2 0/5] target/sh4: misc FPU fixes and optimizations

Aurelien Jarno wrote: > This patchset should fix the bug#1701821 reported by Bruno Haible, > which makes the gnulib testsuite to fail for single precision libm > tests or for tests relying on unordered comparisons. It does fix it: All floating-point related tests of gnulib now pass with qemu-sh4.

Re: [Qemu-devel] [Qemu devel v5 PATCH 0/5] Add support for Smartfusion2 SoC

On 2 July 2017 at 18:39, sundeep subbaraya wrote: > I figured out that systick uses cpu clock as clock source and > system_clock_scale > need to be set in msf2-soc.c. There is a bug in u-boot where it uses cpu > clock as > systick input but configures systick in external

[Qemu-devel] [PATCH v2 1/5] target/sh4: do not check for PR bit for fabs instruction

The SH4 manual is not fully clear about that, but real hardware do not check for the PR bit, which allows to select between single or double precision, for the fabs instruction. This is probably what is meant by "Same operation is performed regardless of precision." Remove the check, and at the

[Qemu-devel] [PATCH v2 2/5] target/sh4: fix FPU unorderered compare

In case of unordered compare, the fcmp instructions should either trigger and invalid exception (if enabled) or set T=0. The existing code left it unchanged. LP: https://bugs.launchpad.net/qemu/+bug/1701821 Reported-by: Bruno Haible Signed-off-by: Aurelien Jarno

[Qemu-devel] [PATCH v2 5/5] target/sh4: return result of fcmp using TCG

Since that the T bit of the SR register is mapped using a TGC global, it's better to return the value through TCG than writing it directly. It allows to declare the helpers with the flag TCG_CALL_NO_WG. Signed-off-by: Aurelien Jarno --- target/sh4/helper.h| 8

[Qemu-devel] [PATCH v2 0/5] target/sh4: misc FPU fixes and optimizations

This patchset should fix the bug#1701821 reported by Bruno Haible, which makes the gnulib testsuite to fail for single precision libm tests or for tests relying on unordered comparisons. It also fixes an inversion of cause and flag bits in the FPSCR register, which is unrelated with the reported

[Qemu-devel] [PATCH v2 3/5] target/sh4: fix FPSCR cause vs flag inversion

The floating-point status/control register contains cause and flag bits. The cause bits are set to 0 before executing the instruction, while the flag bits hold the status of the exception generated after the field was last cleared. Signed-off-by: Aurelien Jarno ---

[Qemu-devel] [PATCH v2 4/5] target/sh4: do not use a helper to implement fneg

There is no need to use a helper to flip one bit, just use a TCG xor instruction instead. Signed-off-by: Aurelien Jarno --- target/sh4/helper.h| 1 - target/sh4/op_helper.c | 5 - target/sh4/translate.c | 5 ++--- 3 files changed, 2 insertions(+), 9 deletions(-)

Re: [Qemu-devel] [Qemu devel v5 PATCH 0/5] Add support for Smartfusion2 SoC

Hi Philippe, On Mon, Jun 26, 2017 at 9:41 PM, sundeep subbaraya wrote: > Hi Philippe, > > On Fri, Jun 9, 2017 at 12:51 PM, sundeep subbaraya > wrote: > >> Hi Philippe, >> >> On Wed, May 31, 2017 at 11:06 AM, Philippe Mathieu-Daudé

Re: [Qemu-devel] [PATCH 0/2] target/sh4: fix fabs and optimize fneg

Hi Aurelien, > This patchset should fix the bug #1701821 reported by Bruno Haible, > which makes the gnulib testsuite to fail for single precision libm > tests. > > Aurelien Jarno (2): > target/sh4: do not check for PR bit for fabs instruction > target/sh4: do not use a helper to implement

[Qemu-devel] [PATCH 0/2] target/sh4: fix fabs and optimize fneg

This patchset should fix the bug #1701821 reported by Bruno Haible, which makes the gnulib testsuite to fail for single precision libm tests. Aurelien Jarno (2): target/sh4: do not check for PR bit for fabs instruction target/sh4: do not use a helper to implement fneg target/sh4/helper.h

[Qemu-devel] [PATCH 1/2] target/sh4: do not check for PR bit for fabs instruction

The SH4 manual is not fully clear about that, but real hardware do not check for the PR bit, which allows to select between single or double precision, for the fabs instruction. This is probably what is meant by "Same operation is performed regardless of precision." Remove the check, and at the

[Qemu-devel] [PATCH 2/2] target/sh4: do not use a helper to implement fneg

There is no need to use a helper to flip one bit, just use a TCG xor instruction instead. Signed-off-by: Aurelien Jarno --- target/sh4/helper.h| 1 - target/sh4/op_helper.c | 5 - target/sh4/translate.c | 5 ++--- 3 files changed, 2 insertions(+), 9 deletions(-)

[Qemu-devel] [PATCH v5 2/2] iotests: Add test for colon handling

Reviewed-by: Eric Blake Signed-off-by: Max Reitz --- tests/qemu-iotests/126 | 105 + tests/qemu-iotests/126.out | 23 ++ tests/qemu-iotests/group | 1 + 3 files changed, 129 insertions(+) create

[Qemu-devel] [PATCH v5 0/2] iotests: Add test for colon handling

v3 of v3 of "iotests: Add test for colon handling"; thus, basically, v5. This adds an iotest for the original series "block: Fix backing paths for filenames with colons" and fixes common.config so it works if you have specified the qemu binaries through relative paths. As a bonus, it makes

[Qemu-devel] [PATCH v5 1/2] iotests: Use absolute paths for executables

A user may specify a relative path for accessing qemu, qemu-img, etc. through environment variables ($QEMU_PROG and friends) or a symlink. If a test decides to change its working directory, relative paths will cease to work, however. Work around this by making all of the paths to programs that

Re: [Qemu-devel] [PATCH v2] tests: Avoid non-portable 'echo -ARG'

On 2017-06-30 21:58, Eric Blake wrote: > POSIX says that backslashes in the arguments to 'echo', as well as > any use of 'echo -n' and 'echo -e', are non-portable; it recommends > people should favor 'printf' instead. This is definitely true where > we do not control which shell is running (such

Re: [Qemu-devel] [PATCH v22 19/30] qcow2: add persistent dirty bitmaps support

On 2017-06-30 19:47, Eric Blake wrote: > On 06/29/2017 09:23 PM, Max Reitz wrote: >> On 2017-06-30 04:18, Eric Blake wrote: >>> On 06/28/2017 07:05 AM, Vladimir Sementsov-Ogievskiy wrote: Store persistent dirty bitmaps in qcow2 image. Signed-off-by: Vladimir Sementsov-Ogievskiy

Re: [Qemu-devel] [PATCH v4 1/2] iotests: Use absolute paths for executables

On 2017-06-30 21:41, Eric Blake wrote: > On 06/29/2017 09:46 PM, Max Reitz wrote: > +++ b/tests/qemu-iotests/common.config @@ -103,6 +103,12 @@ if [ -z "$QEMU_VXHS_PROG" ]; then export QEMU_VXHS_PROG="`set_prog_path qnio_server`" fi +export

Re: [Qemu-devel] [PATCH v2 8/8] target/s390x: Fix risbg handling

On 2017-07-01 13:26, Richard Henderson wrote: > The rotation is to the left, but extract shifts to the right. > The computation of the extract parameters needs adjusting. > > For the entry condition, simplify > > 64 - rot + len <= 64 > -rot + len <= 0 > len <= rot > >

Re: [Qemu-devel] [PATCH v2 2/8] target/s390x: Implement CONVERT UNICODE insns

On 2017-07-01 13:25, Richard Henderson wrote: > Signed-off-by: Richard Henderson > --- > target/s390x/helper.h | 6 + > target/s390x/mem_helper.c | 310 > + > target/s390x/translate.c | 44 +++ >

[Qemu-devel] [PATCH 0/2] ThrottleGroup configuration fixes

Since in the future ThrottleGroup configuration will be done even if it has no members, we need to separate the two. Manos Pitsidianakis (2): block: add clock_type field to ThrottleGroup block: remove timer canceling in throttle_config() block/throttle-groups.c | 27

[Qemu-devel] [PATCH 1/2] block: add clock_type field to ThrottleGroup

Clock type in throttling is currently inferred by the ThrottleTimer's clock type even though it is a per-ThrottleGroup property; it doesn't make sense to have different clock types in the same group. Moving this to a field in ThrottleGroup can simplify some of the throttle functions.

[Qemu-devel] [PATCH 2/2] block: remove timer canceling in throttle_config()

throttle_config() cancels the timers of the calling BlockBackend. This doesn't make sense because other BlockBackends in the group remain untouched. There's no need to cancel the timers in the one specific BlockBackend so let's not do that. Throttled requests will run as scheduled and future

Re: [Qemu-devel] [PATCH v4 4/4] sockets: Handle race condition between binds to the same port

On Mon, 2017-06-26 at 13:49 +0100, Daniel P. Berrange wrote: > On Mon, Jun 26, 2017 at 02:32:48PM +0200, Knut Omang wrote: > > > > On Mon, 2017-06-26 at 11:22 +0100, Daniel P. Berrange wrote: > > > > > > On Fri, Jun 23, 2017 at 12:31:08PM +0200, Knut Omang wrote: > > > > > > > > If an offset of

Re: [Qemu-devel] [PATCH v4 4/4] sockets: Handle race condition between binds to the same port

On Mon, 2017-06-26 at 11:34 +0100, Daniel P. Berrange wrote: > On Fri, Jun 23, 2017 at 12:31:08PM +0200, Knut Omang wrote: > > > > If an offset of ports is specified to the inet_listen_saddr function(), > > and two or more processes tries to bind from these ports at the same time, > >

Re: [Qemu-devel] [PATCH] target-ppc: SPR_BOOKE_ESR not set on FP exceptions

On Wed, Jun 21, 2017 at 05:03:08PM -0700, Aaron Larson wrote: > Properly set the book E exception syndrome register when a floating > point exception occurs. > > Currently on a book E processor, the POWERPC_EXCP_FP exception handler > fails to set "env->spr[SPR_BOOKE_ESR] = ESR_FP;" as required

Re: [Qemu-devel] [PATCH v4 2/4] sockets: factor out create_fast_reuse_socket

On Mon, 2017-06-26 at 11:28 +0100, Daniel P. Berrange wrote: > On Fri, Jun 23, 2017 at 12:31:06PM +0200, Knut Omang wrote: > > > > First refactoring step to prepare for fixing the problem > > exposed with the test-listen test in the previous commit > > > > Signed-off-by: Knut Omang