Apply new gdbstub interfaces we added previously to support both little
and big endian guest debugging for RISC-V. And enable the
TARGET_SWICHABLE_ENDIANNESS option.
Signed-off-by: Changbin Du
---
configs/targets/riscv32-softmmu.mak | 1 +
configs/targets/riscv64-softmmu.mak | 1 +
target/risc
This is an RFC series for fast migration of confidential guests using an
in-guest migration helper that lives in OVMF. QEMU VM live migration
needs to read source VM's RAM and write it in the target VM; this
mechanism doesn't work when the guest memory is encrypted or QEMU is
prevented from readin
Some architectures (e.g. ARM versions 3 and above, RISC-V, PowerPC, Alpha,
MIPS, IA-64...) allow switchable endianness. Now our emulation code can
handle both endianness well, but the gdbstub can only handle one of them.
For example, it is problematic to debug a ARM big endian guest on x86 host.
T
The new page is linked from the main index, otherwise sphinx complains
that "document isn't included in any toctree"; I assume there would be a
better place for it in the documentation tree.
Signed-off-by: Dov Murik
---
docs/confidential-guest-live-migration.rst | 145 +
docs
Apply new gdbstub interfaces we added previously to support both little
and big endian guest debugging for ARM. And enable the
TARGET_SWICHABLE_ENDIANNESS option.
Signed-off-by: Changbin Du
---
configs/targets/aarch64-softmmu.mak | 1 +
configs/targets/arm-softmmu.mak | 1 +
target/arm/gdbst
Cc'ing Marc-André
On 8/23/21 12:11 PM, Stefan Reiter wrote:
> From: Stefan Reiter
>
> The following sequence can produce a race condition that results in
> responses meant for different clients being sent to the wrong one:
>
> (QMP, no OOB)
> 1) client A connects
> 2) client A sends 'qmp_capabi
On Thu, 2021-08-19 at 14:27 +0100, Peter Maydell wrote:
> On Thu, 12 Aug 2021 at 17:53, Shashi Mallela <
> shashi.mall...@linaro.org> wrote:
> > Included creation of ITS as part of SBSA platform GIC
> > initialization.
> >
> > Signed-off-by: Shashi Mallela
> > ---
> > hw/arm/sbsa-ref.c | 79
> >
On Mon, 9 Aug 2021 15:45:30 +0200
Cédric Le Goater wrote:
> The XIVE2 interrupt controller of the POWER10 processor as the same
> logic as on POWER9 but its SW interface has been largely reworked. The
> interrupt controller has a new register interface, different BARs,
> extra VSDs. These will be
On 8/23/21 4:20 PM, Changbin Du wrote:
> To resolve the issue to debug switchable targets, this serias introduces
> basic infrastructure for gdbstub and enable support for ARM and RISC-V
> targets.
>
> For example, now there is no problem to debug an big-enadian aarch64 target
> on x86 host.
>
>
According to the ISA, CR should be set based on the source value, and
not on the packed decimal result.
The way this was implemented would cause GT, LT and EQ to be set
incorrectly when the source value was too large and the 31 least
significant digits of the packed decimal result ended up being al
On Mon, 23 Aug 2021 at 15:20, Changbin Du wrote:
>
> To resolve the issue to debug switchable targets, this serias introduces
> basic infrastructure for gdbstub and enable support for ARM and RISC-V
> targets.
As I understand it, fixing this problem requires support
from gdb, not merely changes t
On Mon, 23 Aug 2021 at 16:21, Philippe Mathieu-Daudé wrote:
>
> On 8/23/21 4:20 PM, Changbin Du wrote:
> > To resolve the issue to debug switchable targets, this serias introduces
> > basic infrastructure for gdbstub and enable support for ARM and RISC-V
> > targets.
> >
> > For example, now there
On 8/23/21 5:30 PM, Peter Maydell wrote:
> On Mon, 23 Aug 2021 at 16:21, Philippe Mathieu-Daudé
> wrote:
>>
>> On 8/23/21 4:20 PM, Changbin Du wrote:
>>> To resolve the issue to debug switchable targets, this serias introduces
>>> basic infrastructure for gdbstub and enable support for ARM and RI
On Thu, Aug 19, 2021 at 09:37:58PM +0200, Andrew Jones wrote:
> Future CPU types may specify which vector lengths are supported.
> We can apply nearly the same logic to validate those lengths
> as we do for KVM's supported vector lengths. We merge the code
> where we can, but unfortunately can't co
On Thu, Aug 19, 2021 at 09:37:54PM +0200, Andrew Jones wrote:
> While reviewing the new A64FX CPU type it became clear that CPU
> types should be able to specify which SVE vector lengths are
> supported. This series adds a new bitmap member to ARMCPU and
> modifies arm_cpu_sve_finalize() to validat
On Mon, Aug 23, 2021 at 9:35 AM Markus Armbruster wrote:
>
> Eduardo Habkost writes:
>
> > On Wed, Aug 11, 2021 at 9:44 AM Thomas Huth wrote:
> >>
> >> On 11/08/2021 15.40, Eduardo Habkost wrote:
> >> > On Wed, Aug 11, 2021 at 2:10 AM Thomas Huth wrote:
> >> >>
> >> >> On 10/08/2021 20.56, Edua
Allow CPUs that support SVE to specify which SVE vector lengths they
support by setting them in this bitmap. Currently only the 'max' and
'host' CPU types supports SVE and 'host' requires KVM which obtains
its supported bitmap from the host. So, we only need to initialize the
bitmap for 'max' with
v2:
- Completed testing
- Removed extra space in an error message
- Added Phil's r-b's
While reviewing the new A64FX CPU type it became clear that CPU
types should be able to specify which SVE vector lengths are
supported. This series adds a new bitmap member to ARMCPU and
modifies arm_cpu_sve_
Now that we have an ARMCPU member sve_vq_supported we no longer
need the local kvm_supported bitmap for KVM's supported vector
lengths.
Signed-off-by: Andrew Jones
Reviewed-by: Philippe Mathieu-Daudé
---
target/arm/cpu64.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(
bitmap_clear() only clears the given range. While the given
range should be sufficient in this case we might as well be
100% sure all bits are zeroed by using bitmap_zero().
Signed-off-by: Andrew Jones
Reviewed-by: Philippe Mathieu-Daudé
---
target/arm/kvm64.c | 2 +-
1 file changed, 1 insertio
Future CPU types may specify which vector lengths are supported.
We can apply nearly the same logic to validate those lengths
as we do for KVM's supported vector lengths. We merge the code
where we can, but unfortunately can't completely merge it because
KVM requires all vector lengths, power-of-tw
On 8/23/21 8:26 AM, Dr. David Alan Gilbert wrote:
* James Bottomley (j...@linux.ibm.com) wrote:
(is there an attest of the destination happening here?)
There will be in the final version. The attestations of the source and
target, being the hash of the OVMF (with the registers in the -ES
case
Gitlab: https://gitlab.com/niteesh.gs/qemu/-/commits/aqmp-tui-prototype-v5
Based-on: <20210803182941.504537-1-js...@redhat.com> [v3,00/25] python:
introduce Asynchronous QMP package
CI: https://gitlab.com/niteesh.gs/qemu/-/pipelines/357960983
Updates since v4:
1) Changed reference to parent name
Added dependencies for the upcoming AQMP TUI under the optional
'tui' group.
The same dependencies have also been added under the devel group
since no work around has been found for optional groups to imply
other optional groups.
Signed-off-by: G S Niteesh Babu
---
python/Pipfile.lock | 12
Add an entry point for aqmp-tui. This will allow it to be run from
the command line using "aqmp-tui localhost:1234"
More options available in the TUI can be found using "aqmp-tui -h"
Signed-off-by: G S Niteesh Babu
---
python/setup.cfg | 1 +
1 file changed, 1 insertion(+)
diff --git a/python/s
Added AQMP TUI.
Implements the follwing basic features:
1) Command transmission/reception.
2) Shows events asynchronously.
3) Shows server status in the bottom status bar.
4) Automatic retries on disconnects and error conditions.
Also added type annotations and necessary pylint/mypy configuration
Added pygments as optional dependency for AQMP TUI.
This is required for the upcoming syntax highlighting feature
in AQMP TUI.
The dependency has also been added in the devel optional group.
Added mypy 'ignore_missing_imports' for pygments since it does
not have any type stubs.
Signed-off-by: G S
Add syntax highlighting for the incoming and outgoing QMP messages.
This is achieved using the pygments module which was added in a
previous commit.
The current implementation is a really simple one which doesn't
allow for any configuration. In future this has to be improved
to allow for easier th
10.08.2021 18:17, Hanna Reitz wrote:
On 04.08.21 11:37, Vladimir Sementsov-Ogievskiy wrote:
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
block/copy-before-write.h | 1 -
block/backup.c | 2 +-
block/copy-before-write.c | 7 +++
3 files changed, 4 insertions(+), 6 deletion
The following instructions are part of Zba:
- add.uw (RV64 only)
- sh[123]add (RV32 and RV64)
- sh[123]add.uw (RV64-only)
- slli.uw (RV64-only)
Signed-off-by: Philipp Tomsich
---
Changes in v3:
- The changes to the Zba instructions (i.e. the REQUIRE_ZBA macro
and its use for qualifying the
For RV64, the shamt field in slli.uw is 6 bits wide. While the encoding
space currently reserves a wider shamt-field (for use is a future RV128
ISA), setting the additional bit to 1 will not map to slli.uw for RV64
and needs to be treated as an illegal instruction.
Note that this encoding being re
The Zb[abcs] extensions have complete public review and are nearing
ratifications. These individual extensions are one part of what was
previously though of as the "BitManip" (B) extension, leaving the
final details of future Zb* extensions open as they will undergo
further public discourse.
Thi
The following instructions are part of Zbs:
- b{set,clr,ext,inv}
- b{set,clr,ext,inv}i
Signed-off-by: Philipp Tomsich
---
Changes in v3:
- The changes to the Zbs instructions (i.e. the REQUIRE_ZBS macro) and
its use for qualifying the Zba instructions) are moved into a
separate commit.
t
The following instructions are part of Zbc:
- clmul
- clmulh
- clmulr
Note that these instructions were already defined in the pre-0.93 and
the 0.93 draft-B proposals, but had not been omitted in the earlier
addition of draft-B to QEmu.
Signed-off-by: Philipp Tomsich
---
Changes in v3:
- Thi
With the changes to Zb[abcs], there's some encodings that are
different in RV64 and RV32 (e.g., for rev8 and zext.h). For these,
we'll need a helper macro allowing us to select on RV32, as well.
Signed-off-by: Philipp Tomsich
---
Changes in v3:
- Moved the REQUIRE_32BIT macro into a separate com
Zbs 1.0.0 (just as the 0.93 draft-B before) does no provide for W-form
instructions for Zbs (single-bit instructions). Remove them.
Note that these instructions had already been removed for the 0.93
version of the draft-B extenstion and have not been present in the
binutils patches circulating in
The Zb[abcs] ratification package does not include the proposed
shift-one instructions. There currently is no clear plan to whether
these (or variants of them) will be ratified as Zbo (or a different
extension) or what the timeframe for such a decision could be.
Signed-off-by: Philipp Tomsich
---
The 1.0.0 version of Zbb does not contain pack/packu/packh. However, a
zext.h instruction is provided (built on pack/packh from pre-0.93
draft-B) is available.
This commit adds zext.h and removes the pack* instructions.
Note that the encodings for zext.h are different between RV32 and
RV64, which
This reassigns the instructions that are part of Zbb into it, with the
notable exceptions of the instructions (rev8, zext.w and orc.b) that
changed due to gorci, grevi and pack not being part of Zb[abcs].
Signed-off-by: Philipp Tomsich
---
Changes in v3:
- The changes to the Zbb instructions (i.
The bitmanipulation ISA extensions will be ratified as individual
small extension packages instead of a large B-extension. The first
new instructions through the door (these have completed public review)
are Zb[abcs].
This adds new 'x-zba', 'x-zbb', 'x-zbc' and 'x-zbs' properties for
these in tar
The 1.0.0 version of Zbb does not contain grev/grevi. Instead, a
rev8 instruction (equivalent to the rev8 pseudo-instruction built on
grevi from pre-0.93 draft-B) is available.
This commit adds the new rev8 instruction and removes grev/grevi.
Note that there is no W-form of this instruction (bot
With the addition of Zb[abcs], we also need to add disassembler
support for these new instructions.
Signed-off-by: Philipp Tomsich
---
(no changes since v2)
Changes in v2:
- Fix missing ';' from last-minute whitespace cleanups.
disas/riscv.c | 157
The slli.uw instruction is defined as
X(rd) = (EXTZ(X(rs)[31..0]) << shamt);
This rewrites its implementation to directly match this, allowing
for the small optimisation of not emitting the zero-extension if
the immediate shift is greater than 32.
Signed-off-by: Philipp Tomsich
---
(no chan
The 1.0.0 version of Zbb does not contain gorc/gorci. Instead, a
orc.b instruction (equivalent to the orc.b pseudo-instruction built on
gorci from pre-0.93 draft-B) is available, mainly targeting
string-processing workloads.
This commit adds the new orc.b instruction and removed gorc/gorci.
Sign
With everything classified as Zb[abcs] and pre-0.93 draft-B
instructions that are not part of Zb[abcs] removed, we can remove the
remaining support code for RVB.
Note that RVB has been retired for good and misa.B will neither mean
'some' or 'all of' Zb*:
https://lists.riscv.org/g/tech-bitmanip/m
This series aim to kill a recent class of bug, the infamous
"DMA reentrancy" issues found by Alexander while fuzzing.
Introduce the 'bus_perm' field in MemTxAttrs, defining 3 bits:
- MEMTXPERM_UNSPECIFIED (current default, unchanged behavior)
- MEMTXPERM_UNRESTRICTED (allow list approach)
- MEMTX
We are going to introduce more MemTxResult bits, so it is
safer to check for !MEMTX_OK rather than MEMTX_ERROR.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/intc/arm_gicv3_dist.c | 4 ++--
hw/intc/arm_gicv3_redist.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/hw/in
Check bus permission in flatview_access_allowed() before
running any bus transaction.
There is not change for the default case (MEMTXPERM_UNSPECIFIED).
The MEMTXPERM_UNRESTRICTED case works as an allow list. Devices
using it won't be checked by flatview_access_allowed().
The only deny list equiv
Remove unuseful local 'result' variables.
Signed-off-by: Philippe Mathieu-Daudé
---
softmmu/physmem.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/softmmu/physmem.c b/softmmu/physmem.c
index 2e18947598e..e534dc69918 100644
--- a/softmmu/physmem.c
+++ b/softmmu/
Add the 'direct_access' bit to the memory attributes to restrict
bus master access to ROM/RAM.
Have read/write accessors return MEMTX_BUS_ERROR if an access is
restricted and the region is not ROM/RAM ('direct').
Add corresponding trace events.
Signed-off-by: Philippe Mathieu-Daudé
---
include/e
Introduce flatview_access_allowed() to check bus permission
before running any bus transaction. For now this is a simple
stub.
Signed-off-by: Philippe Mathieu-Daudé
---
softmmu/physmem.c | 37 +++--
1 file changed, 35 insertions(+), 2 deletions(-)
diff --git a/so
On 8/23/21 9:40 AM, Philipp Tomsich wrote:
The bitmanipulation ISA extensions will be ratified as individual
small extension packages instead of a large B-extension. The first
new instructions through the door (these have completed public review)
are Zb[abcs].
This adds new 'x-zba', 'x-zbb', 'x
On 8/23/21 9:40 AM, Philipp Tomsich wrote:
For RV64, the shamt field in slli.uw is 6 bits wide. While the encoding
space currently reserves a wider shamt-field (for use is a future RV128
ISA), setting the additional bit to 1 will not map to slli.uw for RV64
and needs to be treated as an illegal i
Thanks for reviewing, and sorry for the delayed response, I just returned from
vacation.
On 8/10/2021 12:53 PM, Alex Williamson wrote:
> On Fri, 6 Aug 2021 14:43:52 -0700
> Steve Sistare wrote:
>
>> Export vfio_address_spaces and vfio_listener_skipped_section.
>> Add optional name arg to vfio_
On 8/23/21 9:40 AM, Philipp Tomsich wrote:
Zbs 1.0.0 (just as the 0.93 draft-B before) does no provide for W-form
instructions for Zbs (single-bit instructions). Remove them.
Note that these instructions had already been removed for the 0.93
version of the draft-B extenstion and have not been p
On 8/23/21 9:40 AM, Philipp Tomsich wrote:
The following instructions are part of Zba:
- add.uw (RV64 only)
- sh[123]add (RV32 and RV64)
- sh[123]add.uw (RV64-only)
- slli.uw (RV64-only)
Signed-off-by: Philipp Tomsich
---
Changes in v3:
- The changes to the Zba instructions (i.e. the RE
On 8/23/21 9:40 AM, Philipp Tomsich wrote:
The Zb[abcs] ratification package does not include the proposed
shift-one instructions. There currently is no clear plan to whether
these (or variants of them) will be ratified as Zbo (or a different
extension) or what the timeframe for such a decision c
On 8/23/21 9:40 AM, Philipp Tomsich wrote:
The following instructions are part of Zbs:
- b{set,clr,ext,inv}
- b{set,clr,ext,inv}i
Signed-off-by: Philipp Tomsich
---
Changes in v3:
- The changes to the Zbs instructions (i.e. the REQUIRE_ZBS macro) and
its use for qualifying the Zba instru
On 8/23/21 9:40 AM, Philipp Tomsich wrote:
+static bool trans_clmulh(DisasContext *ctx, arg_clmulr *a)
+{
+REQUIRE_ZBC(ctx);
+
+/* Perform a clmulr ... */
+gen_arith(ctx, a, gen_helper_clmulr);
+
+/* ... then shift the result 1 bit to the right. */
+TCGv dst = tcg_temp_new();
On 8/23/21 9:40 AM, Philipp Tomsich wrote:
This reassigns the instructions that are part of Zbb into it, with the
notable exceptions of the instructions (rev8, zext.w and orc.b) that
changed due to gorci, grevi and pack not being part of Zb[abcs].
Signed-off-by: Philipp Tomsich
---
Changes in v
04.08.2021 19:27, John Snow wrote:
On Wed, Aug 4, 2021 at 5:39 AM Vladimir Sementsov-Ogievskiy mailto:vsement...@virtuozzo.com>> wrote:
In superclass __enter__ method is defined with return value type hint
'QEMUMachine'. So, mypy thinks that return value of VM.__enter__ is
QEMUMachi
On 8/23/21 9:40 AM, Philipp Tomsich wrote:
The 1.0.0 version of Zbb does not contain gorc/gorci. Instead, a
orc.b instruction (equivalent to the orc.b pseudo-instruction built on
gorci from pre-0.93 draft-B) is available, mainly targeting
string-processing workloads.
This commit adds the new or
On 8/23/21 9:40 AM, Philipp Tomsich wrote:
With the changes to Zb[abcs], there's some encodings that are
different in RV64 and RV32 (e.g., for rev8 and zext.h). For these,
we'll need a helper macro allowing us to select on RV32, as well.
Signed-off-by: Philipp Tomsich
---
Changes in v3:
- Moved
On 8/23/21 9:40 AM, Philipp Tomsich wrote:
+++ b/target/riscv/insn32.decode
@@ -682,6 +682,7 @@ min101 .. 100 . 0110011 @r
minu 101 .. 101 . 0110011 @r
orc_b 001010 000111 . 101 . 0010011 @r2
orn010 .. 110 .
On 8/23/21 9:40 AM, Philipp Tomsich wrote:
The 1.0.0 version of Zbb does not contain pack/packu/packh. However, a
zext.h instruction is provided (built on pack/packh from pre-0.93
draft-B) is available.
This commit adds zext.h and removes the pack* instructions.
Note that the encodings for zext
On 8/23/21 9:40 AM, Philipp Tomsich wrote:
With everything classified as Zb[abcs] and pre-0.93 draft-B
instructions that are not part of Zb[abcs] removed, we can remove the
remaining support code for RVB.
Note that RVB has been retired for good and misa.B will neither mean
'some' or 'all of' Zb*
On 8/23/21 9:40 AM, Philipp Tomsich wrote:
The slli.uw instruction is defined as
X(rd) = (EXTZ(X(rs)[31..0]) << shamt);
This rewrites its implementation to directly match this, allowing
for the small optimisation of not emitting the zero-extension if
the immediate shift is greater than 32.
Add unimplemented APU mmio region to xlnx-zynqmp for booting
bare-metal guests built with standalone bsp, which access the
region from one of the following places:
https://github.com/Xilinx/embeddedsw/blob/release-2020.2/lib/bsp/standalone/src/arm/ARMv8/64bit/armclang/boot.S#L139
https://gith
This series adds the APU mmio region as an unimplemented device
to each of two Xilinx SoC to support booting guests built with
the standalone bsp published at:
https://github.com/Xilinx/embeddedsw/tree/master/lib/bsp/standalone/src/arm/ARMv8/64bit
---
Changelogs:
v1->v2:
* For xlnx-zynqmp.c:
23.08.2021 15:05, Vladimir Sementsov-Ogievskiy wrote:
10.08.2021 17:55, Hanna Reitz wrote:
On 04.08.21 11:37, Vladimir Sementsov-Ogievskiy wrote:
We'll need a possibility to set compress and use_copy_range options
after initialization of the state. So make corresponding part of
block_copy_state
Add unimplemented APU mmio region to xlnx-versal for booting
bare-metal guests built with standalone bsp, which access the
region from one of the following places:
https://github.com/Xilinx/embeddedsw/blob/release-2020.2/lib/bsp/standalone/src/arm/ARMv8/64bit/armclang/boot.S#L139
https://gith
On 8/23/21 9:06 AM, Andrew Jones wrote:
Allow CPUs that support SVE to specify which SVE vector lengths they
support by setting them in this bitmap. Currently only the 'max' and
'host' CPU types supports SVE and 'host' requires KVM which obtains
its supported bitmap from the host. So, we only nee
On 8/23/21 9:06 AM, Andrew Jones wrote:
bitmap_clear() only clears the given range. While the given
range should be sufficient in this case we might as well be
100% sure all bits are zeroed by using bitmap_zero().
Signed-off-by: Andrew Jones
Reviewed-by: Philippe Mathieu-Daudé
---
target/arm/k
Connect the support for ZynqMP eFUSE one-time field-programmable
bit array.
Signed-off-by: Tong Ho
---
hw/arm/xlnx-zynqmp.c | 29 +
include/hw/arm/xlnx-zynqmp.h | 3 +++
2 files changed, 32 insertions(+)
diff --git a/hw/arm/xlnx-zynqmp.c b/hw/arm/xlnx-zynqmp
This implements the Xilinx Versal eFuse, an one-time
field-programmable non-volatile storage device. There is
only one such device in the Xilinx Versal product family.
The command argument:
-drive if=pflash,index=N,...
Can be used to optionally connect the storage array to a
backend storage, su
This device is present in Versal and ZynqMP product
families to store a 256-bit encryption key.
Co-authored-by: Edgar E. Iglesias
Co-authored-by: Sai Pavan Boddu
Signed-off-by: Edgar E. Iglesias
Signed-off-by: Sai Pavan Boddu
Signed-off-by: Tong Ho
---
hw/nvram/Kconfig | 4 +
This series implements the Xilinx eFUSE and BBRAM devices for
the Versal and ZynqMP product families.
Furthermore, both new devices are connected to the xlnx-versal-virt
board and the xlnx-zcu102 board.
See changes in docs/system/arm/xlnx-versal-virt.rst for detail.
---
Changelogs:
v1->v2:
* M
Connect the support for Versal Battery-Backed RAM (BBRAM)
Signed-off-by: Tong Ho
---
hw/arm/xlnx-versal-virt.c| 21 +
hw/arm/xlnx-versal.c | 18 ++
include/hw/arm/xlnx-versal.h | 5 +
3 files changed, 44 insertions(+)
diff --git a/hw/arm/xlnx
Connect the support for Xilinx ZynqMP Battery-Backed RAM (BBRAM)
Signed-off-by: Tong Ho
---
hw/arm/xlnx-zynqmp.c | 21 +
include/hw/arm/xlnx-zynqmp.h | 2 ++
2 files changed, 23 insertions(+)
diff --git a/hw/arm/xlnx-zynqmp.c b/hw/arm/xlnx-zynqmp.c
index 3597e8db4d.
This introduces the QOM for Xilinx eFuse, an one-time
field-programmable storage bit array.
The actual mmio interface to the array varies by device
families and will be provided in different change-sets.
Co-authored-by: Edgar E. Iglesias
Co-authored-by: Sai Pavan Boddu
Signed-off-by: Edgar E.
Connect the support for Versal eFUSE one-time field-programmable
bit array.
Signed-off-by: Tong Ho
---
hw/arm/xlnx-versal-virt.c| 37 ++
hw/arm/xlnx-versal.c | 39
include/hw/arm/xlnx-versal.h | 12 +++
3 fi
Add BBRAM and eFUSE usage to the Xilinx Versal Virt board
document.
Signed-off-by: Tong Ho
---
docs/system/arm/xlnx-versal-virt.rst | 49
1 file changed, 49 insertions(+)
diff --git a/docs/system/arm/xlnx-versal-virt.rst
b/docs/system/arm/xlnx-versal-virt.rst
index
On 8/23/21 9:06 AM, Andrew Jones wrote:
Now that we have an ARMCPU member sve_vq_supported we no longer
need the local kvm_supported bitmap for KVM's supported vector
lengths.
Signed-off-by: Andrew Jones
Reviewed-by: Philippe Mathieu-Daudé
---
target/arm/cpu64.c | 19 +++
1
This implements the Xilinx ZynqMP eFuse, an one-time
field-programmable non-volatile storage device. There is
only one such device in the Xilinx ZynqMP product family.
The command argument:
-drive if=pflash,index=N,...
Can be used to optionally connect the storage array to a
backend storage, su
On 8/23/21 9:06 AM, Andrew Jones wrote:
Future CPU types may specify which vector lengths are supported.
We can apply nearly the same logic to validate those lengths
as we do for KVM's supported vector lengths. We merge the code
where we can, but unfortunately can't completely merge it because
KV
The Zb[abcs] extensions have complete public review and are nearing
ratifications. These individual extensions are one part of what was
previously though of as the "BitManip" (B) extension, leaving the
final details of future Zb* extensions open as they will undergo
further public discourse.
Thi
Zbs 1.0.0 (just as the 0.93 draft-B before) does no provide for W-form
instructions for Zbs (single-bit instructions). Remove them.
Note that these instructions had already been removed for the 0.93
version of the draft-B extenstion and have not been present in the
binutils patches circulating in
The bitmanipulation ISA extensions will be ratified as individual
small extension packages instead of a large B-extension. The first
new instructions through the door (these have completed public review)
are Zb[abcs].
This adds new 'x-zba', 'x-zbb', 'x-zbc' and 'x-zbs' properties for
these in tar
The following instructions are part of Zba:
- add.uw (RV64 only)
- sh[123]add (RV32 and RV64)
- sh[123]add.uw (RV64-only)
- slli.uw (RV64-only)
Signed-off-by: Philipp Tomsich
Reviewed-by: Richard Henderson
---
(no changes since v3)
Changes in v3:
- The changes to the Zba instructions (i.e.
The following instructions are part of Zbs:
- b{set,clr,ext,inv}
- b{set,clr,ext,inv}i
Signed-off-by: Philipp Tomsich
Reviewed-by: Richard Henderson
---
(no changes since v3)
Changes in v3:
- The changes to the Zbs instructions (i.e. the REQUIRE_ZBS macro) and
its use for qualifying the Zb
The 1.0.0 version of Zbb does not contain gorc/gorci. Instead, a
orc.b instruction (equivalent to the orc.b pseudo-instruction built on
gorci from pre-0.93 draft-B) is available, mainly targeting
string-processing workloads.
This commit adds the new orc.b instruction and removed gorc/gorci.
Sign
The Zb[abcs] ratification package does not include the proposed
shift-one instructions. There currently is no clear plan to whether
these (or variants of them) will be ratified as Zbo (or a different
extension) or what the timeframe for such a decision could be.
Signed-off-by: Philipp Tomsich
Rev
With everything classified as Zb[abcs] and pre-0.93 draft-B
instructions that are not part of Zb[abcs] removed, we can remove the
remaining support code for RVB.
Note that RVB has been retired for good and misa.B will neither mean
'some' or 'all of' Zb*:
https://lists.riscv.org/g/tech-bitmanip/m
With the changes to Zb[abcs], there's some encodings that are
different in RV64 and RV32 (e.g., for rev8 and zext.h). For these,
we'll need a helper macro allowing us to select on RV32, as well.
Signed-off-by: Philipp Tomsich
Reviewed-by: Richard Henderson
---
(no changes since v3)
Changes in
With the addition of Zb[abcs], we also need to add disassembler
support for these new instructions.
Signed-off-by: Philipp Tomsich
---
(no changes since v2)
Changes in v2:
- Fix missing ';' from last-minute whitespace cleanups.
disas/riscv.c | 157
The following instructions are part of Zbc:
- clmul
- clmulh
- clmulr
Note that these instructions were already defined in the pre-0.93 and
the 0.93 draft-B proposals, but had not been omitted in the earlier
addition of draft-B to QEmu.
Signed-off-by: Philipp Tomsich
---
(no changes since v3
The 1.0.0 version of Zbb does not contain pack/packu/packh. However, a
zext.h instruction is provided (built on pack/packh from pre-0.93
draft-B) is available.
This commit adds zext.h and removes the pack* instructions.
Note that the encodings for zext.h are different between RV32 and
RV64, which
For RV64, the shamt field in slli.uw is 6 bits wide. While the encoding
space currently reserves a wider shamt-field (for use is a future RV128
ISA), setting the additional bit to 1 will not map to slli.uw for RV64
and needs to be treated as an illegal instruction.
Note that this encoding being re
The 1.0.0 version of Zbb does not contain grev/grevi. Instead, a
rev8 instruction (equivalent to the rev8 pseudo-instruction built on
grevi from pre-0.93 draft-B) is available.
This commit adds the new rev8 instruction and removes grev/grevi.
Note that there is no W-form of this instruction (bot
This reassigns the instructions that are part of Zbb into it, with the
notable exceptions of the instructions (rev8, zext.w and orc.b) that
changed due to gorci, grevi and pack not being part of Zb[abcs].
Signed-off-by: Philipp Tomsich
Reviewed-by: Richard Henderson
---
(no changes since v3)
C
101 - 200 of 309 matches
Mail list logo
