There is no branch prediction in TCG, therefore there is no
need to actually include the context number into the predictor.
Therefore all we need to do is add the state for SCXTNUM_ELx.
Signed-off-by: Richard Henderson
---
target/arm/cpu.h| 16 +++
target/arm/cpu64.c | 2 +-
This extension concerns branch speculation, which TCG does
not implement. Thus we can trivially enable this feature.
Signed-off-by: Richard Henderson
---
target/arm/cpu64.c | 1 +
target/arm/cpu_tcg.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/target/arm/cpu64.c
Based-on: 20220409000742.293691-1-richard.hender...@linaro.org
("target/arm: Implement features Debugv8p4, RAS, IESB")
3 more completely trivial features, and a 4th that merely
needs to add some state words.
Add definitions for cortex-a76 (also requires gicv4) and
neoverse-n1 (also requires
On 4/8/2022 12:47 PM, Thomas Huth wrote:
QEMU 7.1 won't support Ubuntu 18.04 anymore, so the last big important
distro that did not have a pre-packaged libslirp has been dismissed.
All other major distros seem to have a libslirp package in their
distribution already - according to repology.org:
Handling potential memory allocation failures in dirtyrate.
Signed-off-by: jianchunfu
---
migration/dirtyrate.c | 8
1 file changed, 8 insertions(+)
diff --git a/migration/dirtyrate.c b/migration/dirtyrate.c
index aace12a787..5dd40f32c8 100644
--- a/migration/dirtyrate.c
+++
On 4/8/22 07:15, Peter Maydell wrote:
Add support for the TCG GICv4 to the virt board. For the board,
the GICv4 is very similar to the GICv3, with the only difference
being the size of the redistributor frame. The changes here are thus:
* calculating virt_redist_capacity correctly for GICv4
On 4/8/22 07:15, Peter Maydell wrote:
In several places in virt.c we calculate the number of redistributors that
fit in a region of our memory map, which is the size of the region
divided by the size of a single redistributor frame. For GICv4, the
redistributor frame is a different size from
On 4/8/22 07:15, Peter Maydell wrote:
Everywhere we need to check which GIC version we're using, we look at
vms->gic_version and use the VIRT_GIC_VERSION_* enum values, except
in create_gic(), which copies vms->gic_version into a local 'int'
variable and makes direct comparisons against values 2
On 4/8/22 07:15, Peter Maydell wrote:
Now that we have implemented all the GICv4 requirements, relax the
error-checking on the GIC object's 'revision' property to allow a TCG
GIC to be a GICv4, whilst still constraining the KVM GIC to GICv3.
Our 'revision' property doesn't consider the
On 4/8/22 07:15, Peter Maydell wrote:
Update the various GIC ID and feature registers for GICv4:
* PIDR2 [7:4] is the GIC architecture revision
* GICD_TYPER.DVIS is 1 to indicate direct vLPI injection support
* GICR_TYPER.VLPIS is 1 to indicate redistributor support for vLPIs
*
On 4/8/22 07:15, Peter Maydell wrote:
Implement the function gicv3_redist_inv_vlpi(), which was previously
left as a stub. This is the function that does the work of the INV
command for a virtual interrupt.
Signed-off-by: Peter Maydell
---
hw/intc/arm_gicv3_redist.c | 7 +--
1 file
On 4/8/22 07:15, Peter Maydell wrote:
Implement the gicv3_redist_vinvall() function (previously left as a
stub). This function handles the work of a VINVALL command: it must
invalidate any cached information associated with a specific vCPU.
Signed-off-by: Peter Maydell
---
On 4/8/22 07:15, Peter Maydell wrote:
Implement the gicv3_redist_mov_vlpi() function (previously left as a
stub). This function handles the work of a VMOVI command: it marks
the vLPI not-pending on the source and pending on the destination.
Signed-off-by: Peter Maydell
---
On 4/8/22 07:15, Peter Maydell wrote:
We can use our new set_pending_table_bit() utility function
in gicv3_redist_mov_lpi() to clear the bit in the source
pending table, rather than doing the "load, clear bit, store"
ourselves.
Signed-off-by: Peter Maydell
---
hw/intc/arm_gicv3_redist.c | 9
On 4/8/22 07:15, Peter Maydell wrote:
Implement the function gicv3_redist_vlpi_pending(), which was
previously left as a stub. This is the function that is called by
the CPU interface when it changes the state of a vLPI. It's similar
to gicv3_redist_process_vlpi(), but we know that the vCPU is
On 4/8/22 07:15, Peter Maydell wrote:
Implement the function gicv3_redist_process_vlpi(), which was left as
just a stub earlier. This function deals with being handed a VLPI by
the ITS. It must set the bit in the pending table. If the vCPU is
currently resident we must recalculate the highest
On 4/8/22 07:15, Peter Maydell wrote:
+if (extract32(pend, irq % 8, 1) == level) {
Here you assume level in {0,1}...
+pend = deposit32(pend, irq % 8, 1, level ? 1 : 0);
... and here you force it into {0,1}.
Better to have the compiler do that with bool level.
You might consider
On 4/8/22 07:15, Peter Maydell wrote:
+if (oldvalid && newvalid) {
+/*
+ * Changing other fields while VALID is 1 is UNPREDICTABLE;
+ * we choose to log and ignore the write.
+ */
+if (cs->gicr_vpendbaser ^ newval) {
+
spapr_nvdimm_flush_completion_cb() and flush_worker_cb() are using the
DRC object returned by spapr_drc_index() without checking it for NULL.
In this case we would be dereferencing a NULL pointer when doing
SPAPR_NVDIMM(drc->dev) and PC_DIMM(drc->dev).
This can happen if, during a scm_flush(),
Changes from v1:
- clarified in the commit message which kind of errors we aim to prevent
- changed the H_HARDWARE return to g_assert() exit
- v1 link: https://lists.gnu.org/archive/html/qemu-devel/2022-04/msg00569.html
Daniel Henrique Barboza (1):
hw/ppc: check if spapr_drc_index() returns
On 4/8/22 07:15, Peter Maydell wrote:
Factor out the common part of gicv3_redist_update_lpi_only() into
a new function update_for_all_lpis(), which does a full rescan
of an LPI Pending table and sets the specified PendingIrq struct
with the highest priority pending enabled LPI it finds.
On 4/8/22 07:15, Peter Maydell wrote:
Currently the functions which update the highest priority pending LPI
information by looking at the LPI Pending and Configuration tables
are hard-coded to use the physical LPI tables addressed by
GICR_PENDBASER and GICR_PROPBASER. To support virtual LPIs we
On 4/8/22 07:15, Peter Maydell wrote:
The maintenance interrupt state depends only on:
* ICH_HCR_EL2
* ICH_LR_EL2
* ICH_VMCR_EL2 fields VENG0 and VENG1
Now we have a separate function that updates only the vIRQ and vFIQ
lines, use that in places that only change state that affects vIRQ
On 4/8/22 07:15, Peter Maydell wrote:
The CPU interface changes to support vLPIs are fairly minor:
in the parts of the code that currently look at the list registers
to determine the highest priority pending virtual interrupt, we
must also look at the highest priority pending vLPI. To do this
we
On 4/8/22 07:15, Peter Maydell wrote:
The function gicv3_cpuif_virt_update() currently sets all of vIRQ,
vFIQ and the maintenance interrupt. This implies that it has to be
used quite carefully -- as the comment notes, setting the maintenance
interrupt will typically cause the GIC code to be
On 4/8/22 07:15, Peter Maydell wrote:
Implement the new GICv4 redistributor registers: GICR_VPROPBASER
and GICR_VPENDBASER; for the moment we implement these as simple
reads-as-written stubs, together with the necessary migration
and reset handling.
We don't put ID-register checks on the
On 4/8/22 07:15, Peter Maydell wrote:
diff --git a/hw/intc/arm_gicv3_redist.c b/hw/intc/arm_gicv3_redist.c
index 7c75dd6f072..9f1fe09a78e 100644
--- a/hw/intc/arm_gicv3_redist.c
+++ b/hw/intc/arm_gicv3_redist.c
@@ -442,8 +442,8 @@ MemTxResult gicv3_redist_read(void *opaque, hwaddr offset,
On 4/8/22 07:15, Peter Maydell wrote:
The VINVALL command should cause any cached information in the
ITS or redistributor for the specified vCPU to be dropped or
otherwise made consistent with the in-memory LPI configuration
tables.
Here we implement the command and table parsing, leaving the
On 4/8/22 07:15, Peter Maydell wrote:
Implement the GICv4 VMOVI command, which moves the pending state
of a virtual interrupt from one redistributor to another. As with
MOVI, we handle the "parse and validate command arguments and
table lookups" part in the ITS source file, and pass the final
On 4/8/22 07:15, Peter Maydell wrote:
The VSYNC command forces the ITS to synchronize all outstanding ITS
operations for the specified vPEID, so that subsequent writse to
writes.
r~
On 4/8/22 07:15, Peter Maydell wrote:
Implement the ITS side of the handling of the INV command for
virtual interrupts; as usual this calls into a redistributor
function which we leave as a stub to fill in later.
Signed-off-by: Peter Maydell
---
hw/intc/gicv3_internal.h | 9 +
On 4/8/22 07:15, Peter Maydell wrote:
We were previously implementing INV (like INVALL) to just blow away
cached highest-priority-pending-LPI information on all connected
redistributors. For GICv4.0, this isn't going to be sufficient,
because the LPI we are invalidating cached information for
On 4/8/22 07:15, Peter Maydell wrote:
The VSYNC command forces the ITS to synchronize all outstanding ITS
operations for the specified vPEID, so that subsequent writse to
GITS_TRANSLATER honour them. The QEMU implementation is always in
sync, so for us this is a nop, like the existing SYNC
On 4/8/22 07:15, Peter Maydell wrote:
Implement the GICv4 VMOVP command, which updates an entry in the vPE
table to change its rdbase field. This command is unique in the ITS
command set because its effects must be propagated to all the other
ITSes connected to the same GIC as the ITS which
On 4/8/22 07:15, Peter Maydell wrote:
The GICv4 ITS VMOVP command's semantics require it to perform the
operation on every ITS connected to the same GIC that the ITS that
received the command is attached to. This means that the GIC object
needs to keep a pointer to every ITS that is connected
On 4/8/22 07:15, Peter Maydell wrote:
For GICv4, interrupt table entries read by process_its_cmd() may
indicate virtual LPIs which are to be directly injected into a VM.
Implement the ITS side of the code for handling this. This is
similar to the existing handling of physical LPIs, but instead
On 4/8/22 07:15, Peter Maydell wrote:
Split the part of process_its_cmd() which is specific to physical
interrupts into its own function. This is the part which starts by
taking the ICID and looking it up in the collection table. The
handling of virtual interrupts is significantly different
On 4/8/22 09:47, Alex Bennée wrote:
This gives a little more insight into what is going on as we
invalidate a range of TBs.
Signed-off-by: Alex Bennée
---
accel/tcg/translate-all.c | 9 +
accel/tcg/trace-events| 1 +
2 files changed, 10 insertions(+)
diff --git
On 4/8/22 09:47, Alex Bennée wrote:
Signed-off-by: Alex Bennée
---
accel/tcg/translate-all.c | 2 ++
accel/tcg/trace-events| 1 +
2 files changed, 3 insertions(+)
Reviewed-by: Richard Henderson
r~
On 4/8/22 09:47, Alex Bennée wrote:
This helps track when pages are tagged for detecting code changes.
Signed-off-by: Alex Bennée
---
accel/tcg/cputlb.c | 14 ++
accel/tcg/trace-events | 3 +++
2 files changed, 13 insertions(+), 4 deletions(-)
Reviewed-by: Richard
On 4/8/22 09:47, Alex Bennée wrote:
Rather than assembling our output piecemeal lets use the same approach
as the plugin disas interface to build the disassembly string before
printing it.
Signed-off-by: Alex Bennée
---
disas.c | 23 +++
1 file changed, 15 insertions(+),
On 4/8/22 09:47, Alex Bennée wrote:
This gets especially confusing if you start plugging in host addresses
from a trace and you wonder why the output keeps changing. Report when
read_memory_func fails instead of blindly disassembling the buffer
contents.
Signed-off-by: Alex Bennée
---
disas.c
On 4/8/22 09:47, Alex Bennée wrote:
This helps us construct strings elsewhere before echoing to the
monitor. It avoids having to jump through hoops like:
monitor_printf(mon, "%s", s->str);
Signed-off-by: Alex Bennée
---
include/monitor/monitor.h | 1 +
monitor/monitor-internal.h | 1 -
On 4/8/22 09:47, Alex Bennée wrote:
These events can be very expensive for the translator so lets add a
tracepoint to help with debugging what might be causing them. Clean up
the comments while we are at it.
Signed-off-by: Alex Bennée
---
accel/tcg/translate-all.c | 15 +++
On 4/8/22 09:47, Alex Bennée wrote:
Signed-off-by: Alex Bennée
---
accel/tcg/cputlb.c | 2 +-
accel/tcg/trace-events | 4
trace-events | 4
3 files changed, 5 insertions(+), 5 deletions(-)
Reviewed-by: Richard Henderson
r~
On 4/9/22 02:46, Frédéric Pétrot wrote:
Since we now have xlen in misa, let's not use TARGET_LONG_BITS while
forging the isa string, and use instead riscv_cpu_mxl_bits.
Signed-off-by: Frédéric Pétrot
---
target/riscv/cpu.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
On 4/9/22 02:46, Frédéric Pétrot wrote:
Now that we have misa xlen, use that in riscv gdbstub.c instead of the
TARGET_LONG_BITS define, and use riscv_cpu_mxl_bits to provide the number of
bits in a consistent way.
Signed-off-by: Frédéric Pétrot
---
target/riscv/gdbstub.c | 7 ---
1 file
Make the code a little more maintainable by using dc->vmsd to register
the vmstate instead of using vmstate_(un)register calls.
'instance_id' was being set to VMSTATE_INSTANCE_ID_ANY so there is no need
for qdev_set_legacy_instance_id() calls.
spapr_nvdimm_unrealize() was removed since it was
Hi,
This v2 contains only the last patch from v1, patch 4, given that all
other patches are breaking backward migration due to how
qdev_set_legacy_instance_id() works when vmstate_register() is passing
an id to the vmsds.
Changes from v1:
- patches 1-3: removed
- v1 link:
Since we now have xlen in misa, let's not use TARGET_LONG_BITS while
forging the isa string, and use instead riscv_cpu_mxl_bits.
Signed-off-by: Frédéric Pétrot
---
target/riscv/cpu.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
Now that we have misa xlen, use that in riscv gdbstub.c instead of the
TARGET_LONG_BITS define, and use riscv_cpu_mxl_bits to provide the number of
bits in a consistent way.
Signed-off-by: Frédéric Pétrot
---
target/riscv/gdbstub.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
On Thu, 7 Apr 2022 at 15:50, Michael S. Tsirkin wrote:
>
> On Thu, Apr 07, 2022 at 11:03:16AM +0100, Peter Maydell wrote:
> > On Thu, 7 Apr 2022 at 10:52, Michael S. Tsirkin wrote:
> > >
> > > From: Wentao Liang
> > >
> > > A potential Use-after-free was reported in virtio_iommu_handle_command
52 matches
Mail list logo
