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
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,
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
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
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 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*:
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 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
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.
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
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
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
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.
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
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,
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
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
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
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 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
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
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:
*
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 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,
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
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é
---
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
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
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
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:
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
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.
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'
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
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:
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:
-
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
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
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
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:
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
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
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
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
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
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
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',
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
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é
---
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
+++
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
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
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)
-
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*:
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.
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
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 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
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
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
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,
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
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
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
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:
-
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.
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
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.
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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,
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
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
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
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
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
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
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.
>
>
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
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
> >
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
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 +
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 +
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.
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
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 +
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.
$ qemu-system-aarch64 -gdb tcp::1234,endianness=big
When loading encrypted RAM pages of a confidential guest, ask the
in-guest migration helper to decrypt the incoming page and place it
correctly in the guest memory at the appropriate address. This way the
page's plaintext content remains inaccessible to the host.
Signed-off-by: Dov Murik
---
101 - 200 of 305 matches
Mail list logo
