Add support for emulating Shakti reference platform based on C-class
running on arty-100T board.
https://gitlab.com/shaktiproject/cores/shakti-soc/-/blob/master/README.rst
Signed-off-by: Vijai Kumar K
---
MAINTAINERS | 7 +
default-configs/devices/riscv64-softm
This is the initial implementation of Shakti UART.
Signed-off-by: Vijai Kumar K
---
MAINTAINERS | 2 +
hw/char/meson.build | 1 +
hw/char/shakti_uart.c | 185 ++
hw/char/trace-events | 4 +
include/hw/char/shakti_
This series adds initial suppport for emulating shakti soc[1] running
on arty 100T.
Shakti SoC uses Shakti C class core[2] and Shakti Uart[3]
[1] https://gitlab.com/shaktiproject/cores/shakti-soc/-/blob/master/README.rst
[2] https://gitlab.com/shaktiproject/cores/c-class/-/blob/master/README.md
[
Connect one shakti uart to the shakti_c machine.
Signed-off-by: Vijai Kumar K
---
hw/riscv/shakti_c.c | 8
include/hw/riscv/shakti_c.h | 2 ++
2 files changed, 10 insertions(+)
diff --git a/hw/riscv/shakti_c.c b/hw/riscv/shakti_c.c
index 45d0eedabd..6174136ffa 100644
--- a/hw/r
C-Class is a member of the SHAKTI family of processors from IIT-M.
It is an extremely configurable and commercial-grade 5-stage in-order
core supporting the standard RV64GCSUN ISA extensions.
Signed-off-by: Vijai Kumar K
---
target/riscv/cpu.c | 1 +
target/riscv/cpu.h | 1 +
2 files changed, 2
[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/1811653
Title:
usbredir sl
[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/1811916
Title:
SDL2 interf
[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/1811711
Title:
qemu-img ca
It's still possible that the wrong value is returned from the alias
of variable even if the program can be compiled without issue. This
improves the check by executing the binary to check the result.
If alias attribute can't be working properly, the @target_page in
exec-vary.c will always return z
Hi Paolo and Richard,
On 3/21/21 9:33 AM, Richard Henderson wrote:
On 3/20/21 11:52 AM, Paolo Bonzini wrote:
+int main(void)
+{
+ return read_y();
+}
I think this should be "read_y() == 1 ? 0 : 1".
As a testcase returning 0 on success, yes.
Ok. I will include the changes in v2. Also,
Hi Thomas,
On 3/20/21 3:48 PM, Thomas Huth wrote:
On 20/03/2021 05.27, Gavin Shan wrote:
It's still possible that the wrong value is returned from the alias
of variable even if the program can be compiled without issue. This
improves the check by executing the binary to check the result.
If al
Patchew URL: https://patchew.org/QEMU/yfz5ygpwlray5...@os.inf.tu-dresden.de/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: yfz5ygpwlray5...@os.inf.tu-dresden.de
Subject: Arm: VFP regression
=== TEST SCRIPT BEGIN ===
#
Hi,
I'm seeing a regression in Arm's vfp handling, giving an undefined
instruction when reading mvfr1 in PL2/armv7 although the FPU is enabled.
The following makes it work again for me, however this just looks like a
band-aid. Thanks for taking a look.
Adam
diff --git a/target/arm/translate-vfp.
On 3/20/21 11:52 AM, Paolo Bonzini wrote:
+int main(void)
+{
+ return read_y();
+}
I think this should be "read_y() == 1 ? 0 : 1".
As a testcase returning 0 on success, yes.
I can reproduce it with -flto -O2 but not without -flto, do you agree?
Agreed. Replicated with a random recent
Signed-off-by: Michael Rolnik
---
target/avr/cpu-param.h | 8 +---
target/avr/helper.c| 2 --
2 files changed, 1 insertion(+), 9 deletions(-)
diff --git a/target/avr/cpu-param.h b/target/avr/cpu-param.h
index 7ef4e7c679..9765a9d0db 100644
--- a/target/avr/cpu-param.h
+++ b/target/avr/cpu
The previous value of TARGET_PAGE_BITS (8) is a bug. Make it 10
I tested it using the following commands
1. ninja test
2. make check-qtest-avr
3. avocado --show=app run -t arch:avr tests/acceptance/
Michael Rolnik (1):
Set TARGET_PAGE_BITS to be 10 instead of 8 bits
target/avr/cpu-param.h | 8
On Sat, Mar 20, 2021 at 08:40:13PM +, Peter Maydell wrote:
> On Sat, 20 Mar 2021 at 18:59, Michael S. Tsirkin wrote:
> >
> > On Fri, Mar 19, 2021 at 12:35:31PM +, Peter Maydell wrote:
> > > I'm looking at a bug reported against the QEMU arm virt board's pci-gpex
> > > PCI controller: https
On Sat, 20 Mar 2021 at 18:59, Michael S. Tsirkin wrote:
>
> On Fri, Mar 19, 2021 at 12:35:31PM +, Peter Maydell wrote:
> > I'm looking at a bug reported against the QEMU arm virt board's pci-gpex
> > PCI controller: https://bugs.launchpad.net/qemu/+bug/1918917
> > where an attempt to write to
On Fri, Mar 19, 2021 at 12:35:31PM +, Peter Maydell wrote:
> I'm looking at a bug reported against the QEMU arm virt board's pci-gpex
> PCI controller: https://bugs.launchpad.net/qemu/+bug/1918917
> where an attempt to write to an address within the PCI IO window
> where the guest hasn't mapped
On 20/03/21 05:27, Gavin Shan wrote:
It's still possible that the wrong value is returned from the alias
of variable even if the program can be compiled without issue. This
improves the check by executing the binary to check the result.
If alias attribute can't be working properly, the @target_p
Commit 3eacf70bb5a83e4775ad8003cbca63a40f70c8c2 neglected to fix this
for softmmu configs, which pull in migration's use of gnutls.
This fixes the following compilation failure on Arm-based Macs:
In file included from migration/multifd.c:23:
In file included from migration/tls.h:25:
In file
On 20/03/21 18:06, Paolo Bonzini wrote:
On 20/03/21 17:47, Jessica Clarke wrote:
Commit 3eacf70bb5a83e4775ad8003cbca63a40f70c8c2 neglected to fix this
for softmmu configs, which pull in migration's use of gnutls.
Signed-off-by: Jessica Clarke
---
migration/meson.build | 2 +-
1 file changed
On 20/03/21 17:47, Jessica Clarke wrote:
Commit 3eacf70bb5a83e4775ad8003cbca63a40f70c8c2 neglected to fix this
for softmmu configs, which pull in migration's use of gnutls.
Signed-off-by: Jessica Clarke
---
migration/meson.build | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --g
There's a change in mprotect() behaviour [1] in the latest macOS
on M1 and it's not yet clear if it's going to be fixed by Apple.
As a short-term fix, ignore failures setting up the guard pages.
[1] https://gist.github.com/hikalium/75ae822466ee4da13cbbe486498a191f
Buglink: https://bugs.launchpad
The rw portion of the buffer is the only one in which overruns
can be generated. Allow the rx portion to be more completely
covered by huge pages.
Signed-off-by: Richard Henderson
---
tcg/tcg.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/tcg/tcg.c b/tcg/tcg.
My 29 patch series cleaning up buffer allocation really came
a week too late for 6.0. Let me do something quite minimal
instead -- simply ignore the failure to create the guard pages.
r~
Richard Henderson (2):
tcg: Do not set guard pages on the rx portion of code_gen_buffer
tcg: Workaround
On Fri, 19 Mar 2021 at 14:42, Paolo Bonzini wrote:
>
> The following changes since commit cf6b56d4f2107259f52413f979a1d474dad0c1e1:
>
> Merge remote-tracking branch 'remotes/philmd/tags/pflash-20210318' into
> staging (2021-03-18 23:04:41 +)
>
> are available in the Git repository at:
>
>
Commit 3eacf70bb5a83e4775ad8003cbca63a40f70c8c2 neglected to fix this
for softmmu configs, which pull in migration's use of gnutls.
Signed-off-by: Jessica Clarke
---
migration/meson.build | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/migration/meson.build b/migration/meson.
On 3/20/21 7:37 AM, Alex Bennée wrote:
+if (info.heap_base == NULL || info.heap_limit == NULL) {
+printf("null heap: %p -> %p\n", info.heap_base, info.heap_limit);
+exit(1);
+} else if (info.heap_base != NULL && info.heap_limit != NULL) {
Useless inversion of first test?
On 3/20/21 7:36 AM, Alex Bennée wrote:
It may be arm-compat-semihosting but more than one architecture uses
it so lets move the tests into the multiarch area. We gate it on the
feature and split the semicall.h header between the arches.
Also clean-up a bit of the Makefile messing about to one co
On 3/20/21 7:37 AM, Alex Bennée wrote:
Arguably the target_cpu_copy_regs function for each architecture is
misnamed as a number of the architectures also take the opportunity to
fill out the TaskState structure. This could arguably be factored out
into common code but that would require a wider a
On 3/20/21 7:36 AM, Alex Bennée wrote:
Some packaged versions of Sphinx (fedora33/alpine so far) have issues
with the annotated C code that kernel-doc spits out. Without knowing
about things like QEMU_PLUGIN_EXPORT it chokes trying to understand
the code. Evidently this is a problem for the kerne
On 3/20/21 7:36 AM, Alex Bennée wrote:
This aims to provide a bit more guidance for those who take on one of
our "clean up memory allocation" bite-sized tasks.
Signed-off-by: Alex Bennée
---
docs/devel/style.rst | 46
1 file changed, 34 insertions(
For -enable-kvm I haven't been able to find a working commit. All
versions since v3.1.0 just silently hang with the program.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1920602
Title:
QEMU crash
The program works (in TCQ mode) with QEMU v5.0.0.
QEMU starts crashing with the commit:
commit 975af797f1e04e4d1b1a12f1731141d3770fdbce
Author: Joseph Myers
Date: Fri May 15 21:21:24 2020 +
target/i386: fix IEEE x87 floating-point exception raising
--
You received this bug notificat
Hi,
a quick question. I forgot to add my accel/stubs/nvmm-stub.h to
accel/stubs/meson.build but even when I disable NVMM explicitly or build it on
a NetBSD platform that does not support NVMM, it just compiled. So, is it
actually still used?
With regards,
Reinoud
signature.asc
Description: PGP
Hi,
a quick question. I forgot to add my accel/stubs/nvmm-stub.h to
accel/stubs/meson.build but even when I disable NVMM explicitly or build it on
a NetBSD platform that does not support NVMM, it just compiled. So, is it
actually still used?
With regards,
Reinoud
signature.asc
Description: PG
Patchew URL:
https://patchew.org/QEMU/20210320133706.21475-1-alex.ben...@linaro.org/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20210320133706.21475-1-alex.ben...@linaro.org
Subject: [PATCH for 6.0 v1 00/14] fixes
Query the SYS_HEAPINFO semicall and do some basic verification of the
information via libc calls.
Signed-off-by: Alex Bennée
Message-Id: <20210312102029.17017-6-alex.ben...@linaro.org>
---
.../multiarch/arm-compat-semi/semihosting.c | 44 ++-
1 file changed, 43 insertions(+), 1
From: Eric Blake
Mingw recognizes that "0x" has value 0 without setting errno, but
fails to advance endptr to the trailing garbage 'x'. This in turn
showed up in our recent testsuite additions for qemu_strtosz (commit
1657ba44b4 utils: Enhance testsuite for do_strtosz()); adjust our
remaining te
>From the semihosting point of view what we want to know is the current
mode of the processor. Unify this into a single helper and allow us to
use the same GET/SET_ARG helpers for the rest of the code. Having the
helper will also be useful later.
Note: we aren't currently testing riscv32 due to mi
From: Thomas Huth
The test for 128-bit atomics is causing trouble with FreeBSD 12.2 and
--enable-werror:
cc -Werror -fPIE -DPIE -std=gnu99 -Wall -m64 -mcx16 -D_GNU_SOURCE
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes
-Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototy
From: Eric Blake
Our tests were not validating the return value in all cases, nor was
it guaranteeing our documented claim that 'res' is unchanged on error.
For that matter, it wasn't as thorough as the existing tests for
qemu_strtoi() and friends for proving that endptr and res are sanely
set.
This aims to provide a bit more guidance for those who take on one of
our "clean up memory allocation" bite-sized tasks.
Signed-off-by: Alex Bennée
---
docs/devel/style.rst | 46
1 file changed, 34 insertions(+), 12 deletions(-)
diff --git a/docs/dev
Arguably the target_cpu_copy_regs function for each architecture is
misnamed as a number of the architectures also take the opportunity to
fill out the TaskState structure. This could arguably be factored out
into common code but that would require a wider audit of the
architectures. For now just r
From: Thomas Huth
FreeBSD version 12.1 is out of service now, and the task in the
Cirrus-CI is failing. Update to 12.2 to get it working again.
Unfortunately, there is a bug in libtasn1 that triggers with the
new version of Clang that is used there (see this thread for details:
https://lists.gnu.
As per the spec:
the PARAMETER REGISTER contains the address of a pointer to a
four-field data block.
So we need to follow arg0 and place the results of SYS_HEAPINFO there.
Fixes: 3c37cfe0b1 ("semihosting: Change internal common-semi interfaces to use
CPUState *")
Signed-off-by: Alex Bennée
From: Thomas Huth
Our gitlab-ci got quite slow in the past weeks, due to the immense amount
of jobs that we have, so we should try to reduce the number of jobs.
There is no real good reason for having separate jobs just to test the
trace backends, we can do this just fine in other jobs, too.
Sig
It may be arm-compat-semihosting but more than one architecture uses
it so lets move the tests into the multiarch area. We gate it on the
feature and split the semicall.h header between the arches.
Also clean-up a bit of the Makefile messing about to one common set of
runners.
Signed-off-by: Alex
We have kerneldoc tags for the headers so we might as well extract
them into our developer documentation whilst we are at it.
Signed-off-by: Alex Bennée
Reviewed-by: Aaron Lindsay
Message-Id: <20210312172821.31647-4-alex.ben...@linaro.org>
---
docs/devel/tcg-plugins.rst | 5 +
1 file change
I confused myself wandering if this had been merged by looking at the
help output. It seems fuse_opt doesn't automagically add to help
output so lets do it now.
Signed-off-by: Alex Bennée
Reviewed-by: Connor Kuehl
Updates: f6698f2b03 ("tools/virtiofsd: add support for --socket-group")
Message-Id
Some packaged versions of Sphinx (fedora33/alpine so far) have issues
with the annotated C code that kernel-doc spits out. Without knowing
about things like QEMU_PLUGIN_EXPORT it chokes trying to understand
the code. Evidently this is a problem for the kernel as well as the
long stream of regex sub
Hi,
Here is my current collection of fixes for rc1. We have a couple of
documentation tweaks including the final bit of enabling work for the
plugin API to be included via kernel-doc. We have some semihosting
fixes which have been on the list before which just need the final bit
of review. Finally
** Description changed:
- A trivial program compiler with QuickBASIC 4.5 with integer overflow
+ A trivial program compiled with QuickBASIC 4.5 with integer overflow
will crash QEMU when ran under MS-DOS 5.0 or FreeDOS 1.2:
- C:\KILLER>type killer.bas
Public bug reported:
A trivial program compiled with QuickBASIC 4.5 with integer overflow
will crash QEMU when ran under MS-DOS 5.0 or FreeDOS 1.2:
C:\KILLER>type killer.bas
A% = VAL("9"):PRINT A%
C:\KILLER>killer.exe
**
ERROR:../qemu-5.2.0/accel/tcg/tcg-cpus.c:541:tcg_handle_interrupt: as
On Fri, 19 Mar 2021 19:09:17 +0530 Alistair Francis
wrote
> On Sun, Mar 14, 2021 at 5:10 AM Vijai Kumar K wrote:
> >
> > C-Class is a member of the SHAKTI family of processors from Indian
> > Institute of Technology - Madras(IIT-M).
> > It is an extremely configurable and
On Fri, 19 Mar 2021 19:14:31 +0530 Alistair Francis
wrote
> On Sun, Mar 14, 2021 at 5:14 AM Vijai Kumar K wrote:
> >
> > This is the initial implementation of Shakti UART.
> >
> > TX tested and works fine. RX is untested.
> >
> > Signed-off-by: Vijai Kumar K
> > --
Drop the unused fdt pointer in riscv_setup_rom_reset_vec API.
Signed-off-by: Vijai Kumar K
---
hw/riscv/boot.c | 2 +-
hw/riscv/spike.c| 2 +-
hw/riscv/virt.c | 2 +-
include/hw/riscv/boot.h | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/hw/riscv/b
On Fri, 19 Mar 2021 19:17:58 +0530 Alistair Francis
wrote
> On Sun, Mar 14, 2021 at 5:11 AM Vijai Kumar K wrote:
> >
> > Connect one shakti uart to the shakti_c machine.
> >
> > Signed-off-by: Vijai Kumar K
> > ---
> > hw/riscv/shakti_c.c | 7 +++
> >
Currently, dirty bitmaps are for internal use only and there is
no support for accessing their content from third party-apps.
This patch implements new command block-dirty-bitmap-dump, which
returns content of the dirty bitmap encoded in base64. This is
very useful especially in combination with a
Current implementation of dirty bitmaps for raw format is very
limited, because those bitmaps cannot be persistent. Basically it
makes sense, because the raw format doesn't have space where could
be dirty bitmap stored when QEMU is offline. This patch solves it
by storing content of every dirty bit
Currently, QEMU doesn't support persistent dirty bitmaps for raw format
and also dirty bitmaps are for internal use only, and cannot be accessed
using third-party applications. These facts are very limiting
in case someone would like to develop their own backup tool becaouse
without access to the d
62 matches
Mail list logo
