target/arm: Use tcg_constant in translate-m-nocp.c
Use tcg_constant_{i32,i64} as appropriate throughout.
This fixes a bug in trans_VSCCLRM() where we were leaking a TCGv.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The length of the previous insn may be computed from
the difference of start and end addresses.
Use tcg_constant_i32 while we're at it.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Use tcg_gen_umin_i32 instead of tcg_gen_movcond_i32.
Use tcg_constant_i32 while we're at it.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
tmpd = value << (shift & 0x1f);
dest = shift & 0xe0 ? 0 : tmpd;
which has a flatter dependency tree.
Use tcg_constant_i32 while we're at it.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
For aa32, the function has a parameter to use the new el.
For aa64, that never happens.
Use tcg_constant_i32 while we're at it.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Common code for reset_btype and set_btype.
Use tcg_constant_i32.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
This function is incorrect in that it does not properly consider
CPTR_EL2.FPEN. We've already got another mechanism for raising
an FPU access trap: ARM_CP_FPU, so use that instead.
Remove CP_ACCESS_TRAP_FP_EL{2,3}, which becomes unused.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Bool is a more appropriate type for this value.
Adjust the assignments to use true/false.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Bool is a more appropriate type for this value.
Move the member down in the struct to keep the
bool type members together and remove a hole.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
target/arm: Extend store_cpu_offset to take field size
Currently we assume all fields are 32-bit.
Prepare for fields of a single byte, using sizeof_field().
Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
[PMM: use sizeof_field() instead of raw sizeof()] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Bool is a more appropriate type for this value.
Adjust the assignments to use true/false.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Bool is a more appropriate type for this value.
Move the member down in the struct to keep the
bool type members together and remove a hole.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Peter Maydell [Fri, 8 Apr 2022 14:15:50 +0000 (15:15 +0100)]
hw/arm/virt: Support TCG GICv4
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
* changing various places which were "if GICv3" to be "if not GICv2"
* the commandline option handling
Note that using GICv4 reduces the maximum possible number of CPUs on
the virt board from 512 to 317, because we can now only fit half as
many redistributors into the redistributor regions we have defined.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20220408141550.1271295-42-peter.maydell@linaro.org
Peter Maydell [Fri, 8 Apr 2022 14:15:49 +0000 (15:15 +0100)]
hw/arm/virt: Abstract out calculation of redistributor region capacity
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 that for GICv3. Abstract
out the calculation of redistributor region capacity so that we have
one place we need to change to handle GICv4 rather than several.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20220408141550.1271295-41-peter.maydell@linaro.org
Peter Maydell [Fri, 8 Apr 2022 14:15:48 +0000 (15:15 +0100)]
hw/arm/virt: Use VIRT_GIC_VERSION_* enum values in create_gic()
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 and 3.
For consistency, change this function to check the GIC version
the same way we do elsewhere. This includes not implicitly relying
on the enumeration type values happening to match the integer
'revision' values the GIC device object wants.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20220408141550.1271295-40-peter.maydell@linaro.org
Peter Maydell [Fri, 8 Apr 2022 14:15:47 +0000 (15:15 +0100)]
hw/intc/arm_gicv3: Allow 'revision' property to be set to 4
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 possibility of wanting
to specify the minor version of the GIC -- for instance there is a
GICv3.1 which adds support for extended SPI and PPI ranges, among
other things, and also GICv4.1. But since the QOM property is
internal to QEMU, not user-facing, we can cross that bridge when we
come to it. Within the GIC implementation itself code generally
checks against the appropriate ID register feature bits, and the
only use of s->revision is for setting those ID register bits.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20220408141550.1271295-39-peter.maydell@linaro.org
Peter Maydell [Fri, 8 Apr 2022 14:15:46 +0000 (15:15 +0100)]
hw/intc/arm_gicv3: Update ID and feature registers for GICv4
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
* GITS_TYPER.VIRTUAL is 1 to indicate vLPI support
* GITS_TYPER.VMOVP is 1 to indicate that our VMOVP implementation
handles cross-ITS synchronization for the guest
* ICH_VTR_EL2.nV4 is 0 to indicate direct vLPI injection support
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20220408141550.1271295-38-peter.maydell@linaro.org
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 <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20220408141550.1271295-37-peter.maydell@linaro.org
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 <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20220408141550.1271295-36-peter.maydell@linaro.org
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 <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20220408141550.1271295-35-peter.maydell@linaro.org
Peter Maydell [Fri, 8 Apr 2022 14:15:42 +0000 (15:15 +0100)]
hw/intc/arm_gicv3_redist: Use set_pending_table_bit() in mov handling
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 <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20220408141550.1271295-34-peter.maydell@linaro.org
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
definitely resident on the redistributor and the irq is in range, so
it is a bit simpler.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20220408141550.1271295-33-peter.maydell@linaro.org
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 priority pending
vLPI; otherwise we may need to ring a "doorbell" interrupt to let the
hypervisor know it might want to reschedule the vCPU.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20220408141550.1271295-32-peter.maydell@linaro.org
Peter Maydell [Fri, 8 Apr 2022 14:15:39 +0000 (15:15 +0100)]
hw/intc/arm_gicv3_redist: Factor out "update bit in pending table" code
Factor out the code which sets a single bit in an LPI pending table.
We're going to need this for handling vLPI tables, not just the
physical LPI table.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20220408141550.1271295-31-peter.maydell@linaro.org
Peter Maydell [Fri, 8 Apr 2022 14:15:38 +0000 (15:15 +0100)]
hw/intc/arm_gicv3_redist: Recalculate hppvlpi on VPENDBASER writes
The guest uses GICR_VPENDBASER to tell the redistributor when it is
scheduling or descheduling a vCPU. When it writes and changes the
VALID bit from 0 to 1, it is scheduling a vCPU, and we must update
our view of the current highest priority pending vLPI from the new
Pending and Configuration tables. When it writes and changes the
VALID bit from 1 to 0, it is descheduling, which means that there is
no longer a highest priority pending vLPI.
The specification allows the implementation to use part of the vLPI
Pending table as an IMPDEF area where it can cache information when a
vCPU is descheduled, so that it can avoid having to do a full rescan
of the tables when the vCPU is scheduled again. For now, we don't
take advantage of this, and simply do a complete rescan.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20220408141550.1271295-30-peter.maydell@linaro.org
Peter Maydell [Fri, 8 Apr 2022 14:15:37 +0000 (15:15 +0100)]
hw/intc/arm_gicv3_redist: Factor out "update hpplpi for all LPIs" logic
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.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20220408141550.1271295-29-peter.maydell@linaro.org
Peter Maydell [Fri, 8 Apr 2022 14:15:36 +0000 (15:15 +0100)]
hw/intc/arm_gicv3_redist: Factor out "update hpplpi for one LPI" logic
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 will
need to do essentially the same job, but looking at the current
virtual LPI Pending and Configuration tables and updating cs->hppvlpi
instead of cs->hpplpi.
Factor out the common part of the gicv3_redist_check_lpi_priority()
function into a new update_for_one_lpi() function, which updates
a PendingIrq struct if the specified LPI is higher priority than
what is currently recorded there.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20220408141550.1271295-28-peter.maydell@linaro.org
The maintenance interrupt state depends only on:
* ICH_HCR_EL2
* ICH_LR<n>_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
and vFIQ but not the maintenance interrupt.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20220408141550.1271295-27-peter.maydell@linaro.org
Peter Maydell [Fri, 8 Apr 2022 14:15:34 +0000 (15:15 +0100)]
hw/intc/arm_gicv3_cpuif: Support vLPIs
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 change hppvi_index() to check the vLPI and return a special-case
value if that is the right virtual interrupt to take. The callsites
(which handle HPPIR and IAR registers and the "raise vIRQ and vFIQ
lines" code) then have to handle this special-case value.
This commit includes two interfaces with the as-yet-unwritten
redistributor code:
* the new GICv3CPUState::hppvlpi will be set by the redistributor
(in the same way as the existing hpplpi does for physical LPIs)
* when the CPU interface acknowledges a vLPI it needs to set it
to non-pending; the new gicv3_redist_vlpi_pending() function
(which matches the existing gicv3_redist_lpi_pending() used
for physical LPIs) is a stub that will be filled in later
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20220408141550.1271295-26-peter.maydell@linaro.org
Peter Maydell [Fri, 8 Apr 2022 14:15:33 +0000 (15:15 +0100)]
hw/intc/arm_gicv3_cpuif: Split "update vIRQ/vFIQ" from gicv3_cpuif_virt_update()
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 re-entered
recursively. For handling vLPIs, we need the redistributor to be
able to tell the cpuif to update the vIRQ and vFIQ lines when the
highest priority pending vLPI changes. Since that change can't cause
the maintenance interrupt state to change, we can pull the "update
vIRQ/vFIQ" parts of gicv3_cpuif_virt_update() out into a separate
function, which the redistributor can then call without having to
worry about the reentrancy issue.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20220408141550.1271295-25-peter.maydell@linaro.org
Peter Maydell [Fri, 8 Apr 2022 14:15:32 +0000 (15:15 +0100)]
hw/intc/arm_gicv3: Implement new GICv4 redistributor registers
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 handling of these registers,
because they are all in the only-in-v4 extra register frames, so
they're not accessible in a GICv3.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20220408141550.1271295-24-peter.maydell@linaro.org
Peter Maydell [Fri, 8 Apr 2022 14:15:31 +0000 (15:15 +0100)]
hw/intc/arm_gicv3: Implement GICv4's new redistributor frame
The GICv4 extends the redistributor register map -- where GICv3
had two 64KB frames per CPU, GICv4 has four frames. Add support
for the extra frame by using a new gicv3_redist_size() function
in the places in the GIC implementation which currently use
a fixed constant size for the redistributor register block.
(Until we implement the extra registers they will RAZ/WI.)
Any board that wants to use a GICv4 will need to also adjust
to handle the different sized redistributor register block;
that will be done separately.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20220408141550.1271295-23-peter.maydell@linaro.org
Peter Maydell [Fri, 8 Apr 2022 14:15:30 +0000 (15:15 +0100)]
hw/intc/arm_gicv3_its: Implement VINVALL
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
redistributor part as a stub for the moment, as usual.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20220408141550.1271295-22-peter.maydell@linaro.org
Peter Maydell [Fri, 8 Apr 2022 14:15:29 +0000 (15:15 +0100)]
hw/intc/arm_gicv3_its: Implement VMOVI
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
results to a function in the redistributor which will do the
actual operation. As with the "make a VLPI pending" change,
for the moment we leave that redistributor function as a stub,
to be implemented in a later commit.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20220408141550.1271295-21-peter.maydell@linaro.org
Peter Maydell [Fri, 8 Apr 2022 14:15:28 +0000 (15:15 +0100)]
hw/intc/arm_gicv3_its: Implement INV for virtual interrupts
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 <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20220408141550.1271295-20-peter.maydell@linaro.org
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 might be
either physical or virtual, and the required action is different for
those two cases. So we need to do the full process of looking up the
ITE from the devid and eventid. This also means we can do the error
checks that the spec lists for this command.
Split out INV handling into a process_inv() function like our other
command-processing functions. For the moment, stick to handling only
physical LPIs; we will add the vLPI parts later.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20220408141550.1271295-19-peter.maydell@linaro.org
Peter Maydell [Fri, 8 Apr 2022 14:15:26 +0000 (15:15 +0100)]
hw/intc/arm_gicv3_its: Implement VSYNC
The VSYNC command forces the ITS to synchronize all outstanding ITS
operations for the specified vPEID, so that subsequent writes to
GITS_TRANSLATER honour them. The QEMU implementation is always in
sync, so for us this is a nop, like the existing SYNC command.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20220408141550.1271295-18-peter.maydell@linaro.org
Peter Maydell [Fri, 8 Apr 2022 14:15:25 +0000 (15:15 +0100)]
hw/intc/arm_gicv3_its: Implement VMOVP
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 executes the VMOVP
command.
The GICv4 spec allows two implementation choices for handling the
propagation to other ITSes:
* If GITS_TYPER.VMOVP is 1, the guest only needs to issue the command
on one ITS, and the implementation handles the propagation to
all ITSes
* If GITS_TYPER.VMOVP is 0, the guest must issue the command on
every ITS, and arrange for the ITSes to synchronize the updates
with each other by setting ITSList and Sequence Number fields
in the command packets
We choose the GITS_TYPER.VMOVP = 1 approach, and synchronously
execute the update on every ITS.
For GICv4.1 this command has extra fields in the command packet and
additional behaviour. We define the 4.1-only fields with the FIELD
macro, but only implement the GICv4.0 version of the command.
Note that we don't update the reported GITS_TYPER value here;
we'll do that later in a commit which updates all the reported
feature bit and ID register values for GICv4.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20220408141550.1271295-17-peter.maydell@linaro.org
[PMM: Moved gicv3_foreach_its() to arm_gicv3_its_common.h,
for consistency with gicv3_add_its()]
Peter Maydell [Fri, 8 Apr 2022 14:15:24 +0000 (15:15 +0100)]
hw/intc/arm_gicv3: Keep pointers to every connected ITS
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 to it
(previously it was sufficient for the ITS to have a pointer to its
GIC).
Add a glib ptrarray to the GICv3 object which holds pointers to every
connected ITS, and make the ITS add itself to the array for the GIC
it is connected to when it is realized.
Note that currently all QEMU machine types with an ITS have exactly
one ITS in the system, so typically the length of this ptrarray will
be 1. Multiple ITSes are typically used to improve performance on
real hardware, so we wouldn't need to have more than one unless we
were modelling a real machine type that had multile ITSes.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
[PMM: Moved gicv3_add_its() to arm_gicv3_its_common.h to avoid
compilation error building the KVM ITS]
Message-id: 20220408141550.1271295-16-peter.maydell@linaro.org
Peter Maydell [Fri, 8 Apr 2022 14:15:23 +0000 (15:15 +0100)]
hw/intc/arm_gicv3_its: Handle virtual interrupts in process_its_cmd()
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 of
looking up a collection ID in a collection table, we look up a vPEID
in a vPE table. As with the physical LPIs, we leave the rest of the
work to code in the redistributor device.
The redistributor half will be implemented in a later commit;
for now we just provide a stub function which does nothing.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20220408141550.1271295-15-peter.maydell@linaro.org
Peter Maydell [Fri, 8 Apr 2022 14:15:22 +0000 (15:15 +0100)]
hw/intc/arm_gicv3_its: Split out process_its_cmd() physical interrupt code
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 (involving
a lookup in the vPE table) so structuring the code with one
sub-function for the physical interrupt case and one for the virtual
interrupt case will be clearer than putting both cases in one large
function.
The code for handling the "remove mapping from ITE" for the DISCARD
command remains in process_its_cmd() because it is common to both
virtual and physical interrupts.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20220408141550.1271295-14-peter.maydell@linaro.org
Peter Maydell [Fri, 8 Apr 2022 14:15:21 +0000 (15:15 +0100)]
hw/intc/arm_gicv3_its: Factor out CTE lookup sequence
Factor out the sequence of looking up a CTE from an ICID including
the validity and error checks.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20220408141550.1271295-13-peter.maydell@linaro.org
Peter Maydell [Fri, 8 Apr 2022 14:15:20 +0000 (15:15 +0100)]
hw/intc/arm_gicv3_its: Factor out "find ITE given devid, eventid"
The operation of finding an interrupt table entry given a (DeviceID,
EventID) pair is necessary in multiple different ITS commands. The
process requires first using the DeviceID as an index into the device
table to find the DTE, and then useng the EventID as an index into
the interrupt table specified by that DTE to find the ITE. We also
need to handle all the possible error cases: indexes out of range,
table memory not readable, table entries not valid.
Factor this out into a separate lookup_ite() function which we
can then call from the places where we were previously open-coding
this sequence. We'll also need this for some of the new GICv4.0
commands.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20220408141550.1271295-12-peter.maydell@linaro.org
Peter Maydell [Fri, 8 Apr 2022 14:15:19 +0000 (15:15 +0100)]
hw/intc/arm_gicv3_its: Distinguish success and error cases of CMD_CONTINUE
In the ItsCmdResult enum, we currently distinguish only CMD_STALL
(failure, stall processing of the command queue) and CMD_CONTINUE
(keep processing the queue), and we use the latter both for "there
was a parameter error, go on to the next command" and "the command
succeeded, go on to the next command". Sometimes we would like to
distinguish those two cases, so add CMD_CONTINUE_OK to the enum to
represent the success situation, and use it in the relevant places.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20220408141550.1271295-11-peter.maydell@linaro.org
Peter Maydell [Fri, 8 Apr 2022 14:15:18 +0000 (15:15 +0100)]
hw/intc/arm_gicv3_its: Implement VMAPP
Implement the GICv4 VMAPP command, which writes an entry to the vPE
table.
For GICv4.1 this command has extra fields in the command packet
and additional behaviour. We define the 4.1-only fields with the
FIELD macro, but only implement the GICv4.0 version of the command.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20220408141550.1271295-10-peter.maydell@linaro.org
Peter Maydell [Fri, 8 Apr 2022 14:15:17 +0000 (15:15 +0100)]
hw/intc/arm_gicv3_its: Implement VMAPI and VMAPTI
Implement the GICv4 VMAPI and VMAPTI commands. These write
an interrupt translation table entry that maps (DeviceID,EventID)
to (vPEID,vINTID,doorbell). The only difference between VMAPI
and VMAPTI is that VMAPI assumes vINTID == EventID rather than
both being specified in the command packet.
(This code won't be reachable until we allow the GIC version to be
set to 4. Support for reading this new virtual-interrupt DTE and
handling it correctly will be implemented in a later commit.)
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20220408141550.1271295-9-peter.maydell@linaro.org
Peter Maydell [Fri, 8 Apr 2022 14:15:16 +0000 (15:15 +0100)]
hw/intc/arm_gicv3_its: Implement GITS_BASER2 for GICv4
The GICv4 defines a new in-guest-memory table for the ITS: this is
the vPE table. Implement the new GITS_BASER2 register which the
guest uses to tell the ITS where the vPE table is located, including
the decode of the register fields into the TableDesc structure which
we do for the GITS_BASER<n> when the guest enables the ITS.
We guard provision of the new register with the its_feature_virtual()
function, which does a check of the GITS_TYPER.Virtual bit which
indicates presence of ITS support for virtual LPIs. Since this bit
is currently always zero, GICv4-specific features will not be
accessible to the guest yet.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20220408141550.1271295-8-peter.maydell@linaro.org
Peter Maydell [Fri, 8 Apr 2022 14:15:15 +0000 (15:15 +0100)]
hw/intc/arm_gicv3_its: Factor out "is intid a valid LPI ID?"
In process_mapti() we check interrupt IDs to see whether they are
in the valid LPI range. Factor this out into its own utility
function, as we're going to want it elsewhere too for GICv4.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20220408141550.1271295-7-peter.maydell@linaro.org
Peter Maydell [Fri, 8 Apr 2022 14:15:14 +0000 (15:15 +0100)]
target/arm/cpu.c: ignore VIRQ and VFIQ if no EL2
In a GICv3, it is impossible for the GIC to deliver a VIRQ or VFIQ to
the CPU unless the CPU has EL2, because VIRQ and VFIQ are only
configurable via EL2-only system registers. Moreover, in our
implementation we were only calculating and updating the state of the
VIRQ and VFIQ lines in gicv3_cpuif_virt_irq_fiq_update() when those
EL2 system registers changed. We were therefore able to assert in
arm_cpu_set_irq() that we didn't see a VIRQ or VFIQ line update if
EL2 wasn't present.
This assumption no longer holds with GICv4:
* even if the CPU does not have EL2 the guest is able to cause the
GIC to deliver a virtual LPI by programming the ITS (which is a
silly thing for it to do, but possible)
* because we now need to recalculate the state of the VIRQ and VFIQ
lines in more cases than just "some EL2 GIC sysreg was written",
we will see calls to arm_cpu_set_irq() for "VIRQ is 0, VFIQ is 0"
even if the guest is not using the virtual LPI parts of the ITS
Remove the assertions, and instead simply ignore the state of the
VIRQ and VFIQ lines if the CPU does not have EL2.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20220408141550.1271295-6-peter.maydell@linaro.org
Peter Maydell [Fri, 8 Apr 2022 14:15:13 +0000 (15:15 +0100)]
hw/intc/arm_gicv3: Report correct PIDR0 values for ID registers
We use the common function gicv3_idreg() to supply the CoreSight ID
register values for the GICv3 for the copies of these ID registers in
the distributor, redistributor and ITS register frames. This isn't
quite correct, because while most of the register values are the
same, the PIDR0 value should vary to indicate which of these three
frames it is. (You can see this and also the correct values of these
PIDR0 registers by looking at the GIC-600 or GIC-700 TRMs, for
example.)
Make gicv3_idreg() take an extra argument for the PIDR0 value.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20220408141550.1271295-5-peter.maydell@linaro.org
Peter Maydell [Fri, 8 Apr 2022 14:15:12 +0000 (15:15 +0100)]
hw/intc/arm_gicv3: Insist that redist region capacity matches CPU count
Boards using the GICv3 need to configure it with both the total
number of CPUs and also the sizes of all the memory regions which
contain redistributors (one redistributor per CPU). At the moment
the GICv3 checks that the number of CPUs specified is not too many to
fit in the defined redistributor regions, but in fact the code
assumes that the two match exactly. For instance when we set the
GICR_TYPER.Last bit on the final redistributor in each region, we
assume that we don't need to consider the possibility of a region
being only half full of redistributors or even completely empty. We
also assume in gicv3_redist_read() and gicv3_redist_write() that we
can calculate the CPU index from the offset within the MemoryRegion
and that this will always be in range.
Fortunately all the board code sets the redistributor region sizes to
exactly match the CPU count, so this isn't a visible bug. We could
in theory make the GIC code handle non-full redistributor regions, or
have it automatically reduce the provided region sizes to match the
CPU count, but the simplest thing is just to strengthen the error
check and insist that the CPU count and redistributor region size
settings match exactly, since all the board code does that anyway.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20220408141550.1271295-4-peter.maydell@linaro.org
Peter Maydell [Fri, 8 Apr 2022 14:15:11 +0000 (15:15 +0100)]
hw/intc/arm_gicv3: Sanity-check num-cpu property
In the GICv3 code we implicitly rely on there being at least one CPU
and thus at least one redistributor and CPU interface. Sanity-check
that the property the board code sets is not zero.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20220408141550.1271295-3-peter.maydell@linaro.org
Peter Maydell [Fri, 8 Apr 2022 14:15:10 +0000 (15:15 +0100)]
hw/intc/arm_gicv3_its: Add missing blank line
In commit b6f96009acc we split do_process_its_cmd() from
process_its_cmd(), but forgot the usual blank line between function
definitions. Add it.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20220408141550.1271295-2-peter.maydell@linaro.org
Merge tag 'pull-migration-20220421a' of https://gitlab.com/dagrh/qemu into staging
V2: Migration pull 2022-04-21
Dan: Test fixes and improvements (TLS mostly)
Peter: Postcopy improvements
Me: Race fix for info migrate, and compilation fix
V2:
Fixed checkpatch nit of unneeded NULL check
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEERfXHG0oMt/uXep+pBRYzHrxb/ecFAmJhpLIACgkQBRYzHrxb
# /edCPQ//dITFWStcsvon8gBBRWY/ekz/EdmWd2KFUp1r/yzopXExW5Gy+MzzTEwk
# axf7s991eyjta1gU0IYCzWcuR36LE8YsZRgDlOhttZ/674ZnX5ZIJBggwDKE/bYE
# IEHd8qsHy6oV8UIFvBQ6wvIDJmH+8gOwnPUzOO9Ek2UkSgBGsptZ8d6Hi0hTzYFB
# omhgc2eO3XQUlxM+8MwlrZU84QkxnBn2g7nVgDQyRokAou46Yf8FD/bWv3CKAdO+
# Ph+4XjBiddBFYUtf4XWSTvVfi23kij1k/4bjH3zaocE86gQ6CUteImFtowwr6N95
# sJl1EXBOtz0BP5xONqkywpWi1Qqg+mecF4KrS4XAHszaUkaj3sTFOyItwlTzZErF
# /2dZRsPRs9fTcjjzpOe/CKoGr+CcyZdxY1qbCNfHaJagdxytN2qxOaneTUbKYUE5
# n4Om9zxDS2esZCnkx26e2wylJ1wzKZBbjsoKYQA4IGaQ6Qz8Zciea0tApwhgyVjs
# KHcYtvScPLxmEEKgzDap6B7fJxyaOg3KNX+0XzLLpLS1oaeqwvSIQM/QMMrnwGxs
# uA1LI2uqlQBitaJOhgLMnNH4ze27HC3DM4OWAE+iOhpD+LNAWstjWraNNXbG4sSj
# 55ndJHJxOCjPlFY4dB/ytUbUo7XBkztCR4c1+I+lSUbMTq3KuUg=
# =M5sx
# -----END PGP SIGNATURE-----
# gpg: Signature made Thu 21 Apr 2022 11:38:42 AM PDT
# gpg: using RSA key 45F5C71B4A0CB7FB977A9FA90516331EBC5BFDE7
# gpg: Good signature from "Dr. David Alan Gilbert (RH2) <dgilbert@redhat.com>" [full]
* tag 'pull-migration-20220421a' of https://gitlab.com/dagrh/qemu:
migration: Read state once
migration: Fix operator type
migration: Allow migrate-recover to run multiple times
migration: Move channel setup out of postcopy_try_recover()
migration: Export ram_load_postcopy()
migration: Move migrate_allow_multifd and helpers into migration.c
migration: Add pss.postcopy_requested status
migration: Drop multifd tls_hostname cache
migration: Postpone releasing MigrationState.hostname
tests: expand the migration precopy helper to support failures
tests: switch migration FD passing test to use common precopy helper
tests: introduce ability to provide hooks for migration precopy test
tests: merge code for UNIX and TCP migration pre-copy tests
tests: switch MigrateStart struct to be stack allocated
migration: fix use of TLS PSK credentials with a UNIX socket
tests: print newline after QMP response in qtest logs
tests: support QTEST_TRACE env variable
tests: improve error message when saving TLS PSK file fails
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
* tag 'pull-rx-20220421' of https://gitlab.com/rth7680/qemu:
target/rx: update PC correctly in wait instruction
target/rx: set PSW.I when executing wait instruction
hw/rx: rx-gdbsim DTB load address aligned of 16byte.
target/rx: Swap stack pointers on clrpsw/setpsw instruction
target/rx: Move DISAS_UPDATE check for write to PSW
target/rx: Store PSW.U in tb->flags
target/rx: Put tb_flags into DisasContext
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Merge tag 'python-pull-request' of https://gitlab.com/jsnow/qemu into staging
Python patches
This PR finalizes the switch from Luiz's QMP library to mine.
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEE+ber27ys35W+dsvQfe+BBqr8OQ4FAmJhdSEACgkQfe+BBqr8
# OQ43phAAkrqVMU/IJzKKMIYoZtO67gk2u2AG+FNbrQr0FuisnnMSZzvDgnlxQHii
# ingLiIFEUNIfj5QxOiD/glbh/QI6GHY5mh/FYdStc4YALb2MqXYPQhW3UCGxDPlF
# YqJzWk2WbZ20drxCgRzHN/pI5SQY6N+Ev9jyzP/cvCNIFY7xxe0IhApiNjjZt9e2
# ngZ3pX+xjX94YezTQQ1E6lDUSXDUQ4VZWl/VH8nbEeUbOWLfR238/WOqWkv1SHWM
# TtOBeYOLUDjFzplMr4Xbnd9DP/Q3/V8KKT9VHNHcF8eAkOohvxeYJx8AuuohZB4C
# qPQj+gaD0cV63qZNNRyetqtCTG6bd+GDt/s3GhUBxsufz+Y3MTMn/3zHlheiaOwO
# ZIXiEkdgKxPTx5T6Vo0BJoE4/22VhzBRQuTg/i0bWrzgKAyPDOf8uQnm5vvGV8/H
# f7KtXWPoqNVc2wWOh5vJAlsnKFDVW6d+jBbk5jRGofDKvVU31uLLu4eBBHpPgaAs
# 9fWd7NgEgqL6ZGYsVSyuwmkhKCLjBtd8K/BGQrpicQUH3J80jagSVnmmmt93KaE3
# HXdZfnE3vxcG45LGdjcu88CHOzUqTEflf6gCGg/ISaP3AlPKPZs2Ck7RPHLK1UeG
# 084wYmyuq5C/zXIriBhw75ZGoaJHOdgY31OyMdL1D/Ii+p0h3w0=
# =m2An
# -----END PGP SIGNATURE-----
# gpg: Signature made Thu 21 Apr 2022 08:15:45 AM PDT
# gpg: using RSA key F9B7ABDBBCACDF95BE76CBD07DEF8106AAFC390E
# gpg: Good signature from "John Snow (John Huston) <jsnow@redhat.com>" [undefined]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: FAEB 9711 A12C F475 812F 18F2 88A9 064D 1835 61EB
# Subkey fingerprint: F9B7 ABDB BCAC DF95 BE76 CBD0 7DEF 8106 AAFC 390E
* tag 'python-pull-request' of https://gitlab.com/jsnow/qemu:
python/qmp: remove pylint workaround from legacy.py
python: rename 'aqmp-tui' to 'qmp-tui'
python: rename qemu.aqmp to qemu.qmp
python: re-enable pylint duplicate-code warnings
python: remove the old QMP package
python/aqmp: copy qmp docstrings to qemu.aqmp.legacy
python/aqmp: fully separate from qmp.QEMUMonitorProtocol
python/aqmp: take QMPBadPortError and parse_address from qemu.qmp
python: temporarily silence pylint duplicate-code warnings
python/aqmp-tui: relicense as LGPLv2+
python/qmp-shell: relicense as LGPLv2+
python/aqmp: relicense as LGPLv2+
python/aqmp: add explicit GPLv2 license to legacy.py
iotests: switch to AQMP
iotests/mirror-top-perms: switch to AQMP
scripts/bench-block-job: switch to AQMP
python/machine: permanently switch to AQMP
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
The 'status' field for the migration is updated normally using
an atomic operation from the migration thread.
Most readers of it aren't that careful, and in most cases it doesn't
matter.
In query_migrate->fill_source_migration_info the 'state'
is read twice; the first time to decide which state fields to fill in,
and then secondly to copy the state to the status field; that can end up
with a status that's inconsistent; e.g. setting up the fields
for 'setup' and then having an 'active' status. In that case
libvirt gets upset by the lack of ram info.
The symptom is:
libvirt.libvirtError: internal error: migration was active, but no RAM info was set
Read the state exactly once in fill_source_migration_info.
This is a possible fix for:
https://bugzilla.redhat.com/show_bug.cgi?id=2074205
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Message-Id: <20220413113329.103696-1-dgilbert@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Clang spotted an & that should have been an &&; fix it.
Reported by: David Binderman / https://gitlab.com/dcb Fixes: 65dacaa04fa ("migration: introduce save_normal_page()")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/963 Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Message-Id: <20220406102515.96320-1-dgilbert@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Peter Xu [Thu, 31 Mar 2022 15:08:45 +0000 (11:08 -0400)]
migration: Allow migrate-recover to run multiple times
Previously migration didn't have an easy way to cleanup the listening
transport, migrate recovery only allows to execute once. That's done with a
trick flag in postcopy_recover_triggered.
Now the facility is already there.
Drop postcopy_recover_triggered and instead allows a new migrate-recover to
release the previous listener transport.
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com>
Message-Id: <20220331150857.74406-8-peterx@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Peter Xu [Thu, 31 Mar 2022 15:08:44 +0000 (11:08 -0400)]
migration: Move channel setup out of postcopy_try_recover()
We used to use postcopy_try_recover() to replace migration_incoming_setup() to
setup incoming channels. That's fine for the old world, but in the new world
there can be more than one channels that need setup. Better move the channel
setup out of it so that postcopy_try_recover() only handles the last phase of
switching to the recovery phase.
To do that in migration_fd_process_incoming(), move the postcopy_try_recover()
call to be after migration_incoming_setup(), which will setup the channels.
While in migration_ioc_process_incoming(), postpone the recover() routine right
before we'll jump into migration_incoming_process().
A side benefit is we don't need to pass in QEMUFile* to postcopy_try_recover()
anymore. Remove it.
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com>
Message-Id: <20220331150857.74406-7-peterx@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Peter Xu [Thu, 31 Mar 2022 15:08:43 +0000 (11:08 -0400)]
migration: Export ram_load_postcopy()
Will be reused in postcopy fast load thread.
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com>
Message-Id: <20220331150857.74406-6-peterx@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Peter Xu [Thu, 31 Mar 2022 15:08:42 +0000 (11:08 -0400)]
migration: Move migrate_allow_multifd and helpers into migration.c
This variable, along with its helpers, is used to detect whether multiple
channel will be supported for migration. In follow up patches, there'll be
other capability that requires multi-channels. Hence move it outside multifd
specific code and make it public. Meanwhile rename it from "multifd" to
"multi_channels" to show its real meaning.
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com>
Message-Id: <20220331150857.74406-5-peterx@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Peter Xu [Thu, 31 Mar 2022 15:08:41 +0000 (11:08 -0400)]
migration: Add pss.postcopy_requested status
This boolean flag shows whether the current page during migration is triggered
by postcopy or not. Then in ram_save_host_page() and deeper stack we'll be
able to have a reference on the priority of this page.
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com>
Message-Id: <20220331150857.74406-4-peterx@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Peter Xu [Thu, 31 Mar 2022 15:08:40 +0000 (11:08 -0400)]
migration: Drop multifd tls_hostname cache
The hostname is cached N times, N equals to the multifd channels.
Drop that cache because after previous patch we've got s->hostname
being alive for the whole lifecycle of migration procedure.
Cc: Juan Quintela <quintela@redhat.com> Cc: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com>
Message-Id: <20220331150857.74406-3-peterx@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
We used to release it right after migrate_fd_connect(). That's not good
enough when there're more than one socket pair required, because it'll be
needed to establish TLS connection for the rest channels.
One example is multifd, where we copied over the hostname for each channel
but that's actually not needed.
Keeping the hostname until the cleanup phase of migration.
Cc: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com>
Message-Id: <20220331150857.74406-2-peterx@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
dgilbert: Fixup checkpatch error; don't need to check for NULL
around g_free
tests: expand the migration precopy helper to support failures
The migration precopy testing helper function always expects the
migration to run to a completion state. There will be test scenarios
for TLS where expect either the client or server to fail the migration.
This expands the helper to cope with these scenarios.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20220310171821.3724080-12-berrange@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
tests: switch migration FD passing test to use common precopy helper
The combination of the start and finish hooks allow the FD passing
code to use the precopy helper
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20220310171821.3724080-11-berrange@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
tests: introduce ability to provide hooks for migration precopy test
There are alot of different scenarios to test with migration due to the
wide number of parameters and capabilities available. To enable sharing
of the basic precopy test scenario, we need to be able to set arbitrary
parameters and capabilities before the migration is initiated, but don't
want to have all this logic in the common helper function. Solve this
by defining two hooks that can be provided by the test case, one before
migration starts and one after migration finishes.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20220310171821.3724080-10-berrange@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
tests: merge code for UNIX and TCP migration pre-copy tests
The test cases differ only in the URI they provide to the migration
commands, and the ability to set the dirty_ring mode. This code is
trivially merged into a common helper.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20220310171821.3724080-9-berrange@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
tests: switch MigrateStart struct to be stack allocated
There's no compelling reason why the MigrateStart struct needs to be
heap allocated. Using stack allocation and static initializers is
simpler.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20220310171821.3724080-8-berrange@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
migration: fix use of TLS PSK credentials with a UNIX socket
The migration TLS code has a check mandating that a hostname be
available when starting a TLS session. This is expected when using
x509 credentials, but is bogus for PSK and anonymous credentials
as neither involve hostname validation.
The TLS crdentials object gained suitable error reporting in the
case of TLS with x509 credentials, so there is no longer any need
for the migration code to do its own (incorrect) validation.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20220310171821.3724080-7-berrange@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
tests: print newline after QMP response in qtest logs
The QMP commands have a trailing newline, but the response does not.
This makes the qtest logs hard to follow as the next QMP command
appears in the same line as the previous QMP response.
Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20220310171821.3724080-5-berrange@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
When debugging failing qtests it is useful to be able to turn on trace
output to stderr. The QTEST_TRACE env variable contents get injected
as a '-trace <str>' command line arg
Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20220310171821.3724080-4-berrange@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
tests: improve error message when saving TLS PSK file fails
Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20220310171821.3724080-3-berrange@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Merge tag 'pull-qapi-2022-04-21' of git://repo.or.cz/qemu/armbru into staging
QAPI patches patches for 2022-04-21
# -----BEGIN PGP SIGNATURE-----
#
# iQJGBAABCAAwFiEENUvIs9frKmtoZ05fOHC0AOuRhlMFAmJhZgISHGFybWJydUBy
# ZWRoYXQuY29tAAoJEDhwtADrkYZTuZQP/iesk/r4ytyk+q+ksNCQHTZl4B4uZcbI
# TgbA1dwbwkKOfNaqByKZzXvbymL9Y4RpZavZ0i1qa3hK5orKHThLK4omRaFD+SPp
# sH53TeTgkG/UNUQk00dim1BzuWJefqFo1rYSqvTzaXVPyx1Q9Gk9193q5zDTlMJs
# w6UKD+q+Yxne9aoi1IH2NzzEKElHz7MMFeBDsnxDbkedzBxY1Ka05IOI2ucXhJ7X
# mYTZxHsrjncW4qJNkf57u9y4faNDIBeT3vkFqBaIeTXSSqm+xO1rkLanGOLQKtIM
# zD6JDMcqsIkZttEy0QCOrjKvMueWaOTZsS0sbdCC+JpBAbyVeS83kmRyYwEhyGre
# FJzf81zcEH6FtnDYudWWUT7hKV6sHWbw+4ho5WTkCYnr/Cfqr3TyDbSW+f/eIxUK
# vaujP/8MTypS4p0mx4QfM2/eO05oZHwEaslOn0gkg7siAJWuC7KUkkWSwz6ZNZCp
# qj/+jtDRGhvB4bGFusciqwtbnLNtVPX2meUuVxK74lmKa00+zXraNFfvGIxfzzC0
# pJ6weJj2jMLo5OEsZ2xWfNqhDigFQYxbGR8X3N2hg5GZTx1k5WXx7mRz3GlAwd8Q
# /4hcTBXKTFxDNxXqzL2eHBtaruKHjnHoVo2eAodyF+9FqErInjr/wisVm6I+R8NR
# Z94UBs8lvMIC
# =a3AD
# -----END PGP SIGNATURE-----
# gpg: Signature made Thu 21 Apr 2022 07:11:14 AM PDT
# gpg: using RSA key 354BC8B3D7EB2A6B68674E5F3870B400EB918653
# gpg: issuer "armbru@redhat.com"
# gpg: Good signature from "Markus Armbruster <armbru@redhat.com>" [undefined]
# gpg: aka "Markus Armbruster <armbru@pond.sub.org>" [undefined]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 354B C8B3 D7EB 2A6B 6867 4E5F 3870 B400 EB91 8653
* tag 'pull-qapi-2022-04-21' of git://repo.or.cz/qemu/armbru:
qapi: Fix version of cpu0-id field
qapi: Fix typo
qapi: Fix documentation for query-xen-replication-status
docs: qapi: Remove outdated reference to simple unions
qapi-schema: test: add a unit test for parsing array alternates
qapi-schema: test: add a qapi-schema-test for array alternates
qapi-schema: support alternates with array type
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
target/rx: update PC correctly in wait instruction
`cpu_pc` at this point does not necessary point to the current
instruction (i.e., the wait instruction being translated), so it's
incorrect to calculate the new value of `cpu_pc` based on this. It must
be updated with `ctx->base.pc_next`, which contains the correct address
of the next instruction.
This change fixes the wait instruction skipping the subsequent branch
when used in an idle loop like this:
0: wait
bra.b 0b
brk // should be unreachable
Signed-off-by: Tomoaki Kawada <i@yvt.jp> Reviewed-by: Yoshinori Sato <ysato@users.sourceforge.jp> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20220417060224.2131788-1-i@yvt.jp> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Yoshinori Sato [Mon, 7 Feb 2022 13:27:58 +0000 (22:27 +0900)]
hw/rx: rx-gdbsim DTB load address aligned of 16byte.
Linux kernel required alined address of DTB.
But missing align in dtb load function.
Fixed to load to the correct address.
Signed-off-by: Yoshinori Sato <ysato@users.sourceforge.jp> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20220207132758.84403-1-ysato@users.sourceforge.jp> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
target/rx: Move DISAS_UPDATE check for write to PSW
Have one check in move_to_cr instead of one in each
function that calls move_to_cr.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Yoshinori Sato <ysato@users.sourceforge.jp>
Message-Id: <20220417165130.695085-4-richard.henderson@linaro.org>
With this, we don't need movcond to determine
which stack pointer is current.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Yoshinori Sato <ysato@users.sourceforge.jp>
Message-Id: <20220417165130.695085-3-richard.henderson@linaro.org>
Copy tb->flags into ctx->tb_flags; we'll want to modify
this value throughout the tb in future.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Yoshinori Sato <ysato@users.sourceforge.jp>
Message-Id: <20220417165130.695085-2-richard.henderson@linaro.org>
* tag 'misc-pull-request' of gitlab.com:marcandre.lureau/qemu: (30 commits)
qga: use fixed-length and GDateTime for log timestamp
tests/fuzz: fix warning
qga: remove need for QEMU atomic.h
util: replace qemu_get_local_state_pathname()
util: use qemu_create() in qemu_write_pidfile()
util: use qemu_write_full() in qemu_write_pidfile()
util: simplify write in signal handler
qtest: simplify socket_send()
qga: move qga_get_host_name()
Move error_printf_unless_qmp() with monitor unit
tests: run-time skip test-qga if TSAN is enabled
compiler.h: add QEMU_SANITIZE_{ADDRESS,THREAD}
tests: remove block/qdict checks from check-qobject.c
include: move qdict_{crumple,flatten} declarations
include: add qemu/keyval.h
include: move qemu_fdatasync() to osdep
include: move qemu_msync() to osdep
compiler.h: replace QEMU_NORETURN with G_NORETURN
osdep.h: move qemu_build_not_reached()
doc/style: CLang -> Clang
...
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Merge tag 'pull-target-arm-20220421' of https://git.linaro.org/people/pmaydell/qemu-arm into staging
target-arm queue:
* hw/arm/virt: Check for attempt to use TrustZone with KVM or HVF
* versal: Add the Cortex-R5s in the Real-Time Processing Unit (RPU) subsystem
* versal: model enough of the Clock/Reset Low-power domain (CRL) to allow control of the Cortex-R5s
* xlnx-zynqmp: Connect 4 TTC timers
* exynos4210: Refactor GIC/combiner code to stop using qemu_split_irq
* realview: replace 'qemu_split_irq' with 'TYPE_SPLIT_IRQ'
* stellaris: replace 'qemu_split_irq' with 'TYPE_SPLIT_IRQ'
* hw/core/irq: remove unused 'qemu_irq_split' function
* npcm7xx: use symbolic constants for PWRON STRAP bit fields
* virt: document impact of gic-version on max CPUs
* tag 'pull-target-arm-20220421' of https://git.linaro.org/people/pmaydell/qemu-arm: (31 commits)
hw/arm: Use bit fields for NPCM7XX PWRON STRAPs
hw/misc: Add PWRON STRAP bit fields in GCR module
hw/arm/virt: impact of gic-version on max CPUs
hw/core/irq: remove unused 'qemu_irq_split' function
hw/arm/stellaris: replace 'qemu_split_irq' with 'TYPE_SPLIT_IRQ'
hw/arm/realview: replace 'qemu_split_irq' with 'TYPE_SPLIT_IRQ'
hw/arm/exynos4210: Drop Exynos4210Irq struct
hw/arm/exynos4210: Put combiners into state struct
hw/arm/exynos4210: Fold combiner splits into exynos4210_init_board_irqs()
hw/arm/exynos4210: Don't connect multiple lines to external GIC inputs
hw/arm/exynos4210: Connect MCT_G0 and MCT_G1 to both combiners
hw/arm/exynos4210: Fill in irq_table[] for internal-combiner-only IRQ lines
hw/arm/exynos4210: Use TYPE_SPLIT_IRQ in exynos4210_init_board_irqs()
hw/arm/exynos4210: Delete unused macro definitions
hw/arm/exynos4210: Move exynos4210_combiner_get_gpioin() into exynos4210.c
hw/arm/exynos4210: Drop ext_gic_irq[] from Exynos4210Irq struct
hw/arm/exynos4210: Put external GIC into state struct
hw/arm/exynos4210: Move exynos4210_init_board_irqs() into exynos4210.c
hw/arm/exynos4210: Fix code style nit in combiner_grp_to_gic_id[]
hw/arm/exynos4210: Coalesce board_irqs and irq_table
...
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
John Snow [Wed, 30 Mar 2022 17:28:12 +0000 (13:28 -0400)]
python/qmp: remove pylint workaround from legacy.py
Pylint upgraded recently (2.13.z) and having a pylint: disable comment
in the middle of an argument field causes it some grief (It appears to
stop parsing when it encounters it, causing some syntax problems). Since
the duplicate line threshold was bumped up in 22305c2a081b, we don't
need this workaround anymore. Drop it.
Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@openvz.org>
Message-id: 20220330172812.3427355-10-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
John Snow [Wed, 30 Mar 2022 17:28:10 +0000 (13:28 -0400)]
python: rename qemu.aqmp to qemu.qmp
Now that we are fully switched over to the new QMP library, move it back
over the old namespace. This is being done primarily so that we may
upload this package simply as "qemu.qmp" without introducing confusion
over whether or not "aqmp" is a new protocol or not.
The trade-off is increased confusion inside the QEMU developer
tree. Sorry!
Note: the 'private' member "_aqmp" in legacy.py also changes to "_qmp";
not out of necessity, but just to remove any traces of the "aqmp"
name.
Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Beraldo Leal <bleal@redhat.com> Acked-by: Hanna Reitz <hreitz@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@openvz.org>
Message-id: 20220330172812.3427355-8-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
John Snow [Wed, 30 Mar 2022 17:28:06 +0000 (13:28 -0400)]
python/aqmp: fully separate from qmp.QEMUMonitorProtocol
After this patch, qemu.aqmp.legacy.QEMUMonitorProtocol no longer
inherits from qemu.qmp.QEMUMonitorProtocol. To do this, several
inherited methods need to be explicitly re-defined.
(Licensing: This is copying and modifying GPLv2-only code into a
GPLv2-only file.)
Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Beraldo Leal <bleal@redhat.com>
Message-id: 20220330172812.3427355-4-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
The next several commits copy some code from qemu.qmp to qemu.aqmp, then
delete qemu.qmp. In the interim, to prevent test failures, the duplicate
code detection needs to be silenced to prevent bisect problems with CI
testing.
Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-id: 20220330172812.3427355-2-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
John Snow [Fri, 25 Mar 2022 20:04:38 +0000 (16:04 -0400)]
python/aqmp-tui: relicense as LGPLv2+
aqmp-tui, the async QMP text user interface tool, is presently licensed
as GPLv2+. I intend to include this tool as an add-on to an LGPLv2+
library package hosted on PyPI.org. I've selected LGPLv2+ to maximize
compatibility with other licenses while retaining a copyleft license.
To keep licensing matters simple, I'd like to relicense this tool as
LGPLv2+ as well in order to keep the resultant license of the hosted
release files simple -- even if library users won't "link against" this
command line tool.
Therefore, I am asking permission to loosen the license.
Niteesh is effectively the sole author of this code, with scattered
lines from myself.
Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: G S Niteesh Babu <niteesh.gs@gmail.com>
Message-id: 20220325200438.2556381-5-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
John Snow [Fri, 25 Mar 2022 20:04:37 +0000 (16:04 -0400)]
python/qmp-shell: relicense as LGPLv2+
qmp-shell is presently licensed as GPLv2 (only). I intend to include
this tool as an add-on to an LGPLv2+ library package hosted on
PyPI.org. I've selected LGPLv2+ to maximize compatibility with other
licenses while retaining a copyleft license.
To keep licensing matters simple, I'd like to relicense this tool as
LGPLv2+ as well in order to keep the resultant license of the hosted
release files simple -- even if library users won't "link against" this
command line tool.
Therefore, I am asking permission from the current authors of this
tool to loosen the license. At present, those people are:
(All of which appear to have been written under redhat.com addresses.)
Eduardo's fixes are largely automated from 2to3 conversion tools and may
not necessarily constitute authorship, but his signature would put to
rest any questions.
Cleber's changes concern a single import statement change. Also won't
hurt to ask.
Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Acked-by: Fam Zheng <fam@euphon.net> Acked-by: Luiz Capitulino <lcapitulino@redhat.com> Acked-by: Eduardo Habkost <eduardo@habkost.net> Acked-by: Daniel P. Berrangé <berrange@redhat.com> Acked-by: Cleber Rosa <crosa@redhat.com>
Message-id: 20220325200438.2556381-4-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
John Snow [Fri, 25 Mar 2022 20:04:36 +0000 (16:04 -0400)]
python/aqmp: relicense as LGPLv2+
I am the sole author of all of the async QMP code (python/qemu/aqmp)
with the following exceptions:
python/qemu/aqmp/qmp_shell.py and python/qemu/aqmp/legacy.py were
written by Luiz Capitulino (et al) and are already licensed separately
as GPLv2 (only).
aqmp_tui.py was written by Niteesh Babu G S and is licensed as GPLv2+.
I wish to relicense as LGPLv2+ in order to provide as much flexibility
as I reasonably can, while retaining a copyleft license. It is my belief
that LGPLv2+ is a suitable license for the Python ecosystem that aligns
with the goals and philosophy of the QEMU project.
The intent is to eventually drop legacy.py, leaving only library code
that is LGPLv2+.
Signed-off-by: John Snow <jsnow@redhat.com>
Message-id: 20220325200438.2556381-3-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
John Snow [Fri, 25 Mar 2022 20:04:35 +0000 (16:04 -0400)]
python/aqmp: add explicit GPLv2 license to legacy.py
The legacy.py module is heavily based on the QMP module by Luiz
Capitulino (et al) which is licensed as explicit GPLv2-only. The async
QMP package is currently licensed similarly, but I intend to relicense
the async package to the more flexible LGPLv2+.
In preparation for that change, make the license on legacy.py explicit.
Signed-off-by: John Snow <jsnow@redhat.com>
Message-id: 20220325200438.2556381-2-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
projects / mirror_qemu.git / log