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()]
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
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
The current riscv_load_fdt() forces fdt_load_addr to be placed at a dram address within 3GB,
but not all platforms have dram_base within 3GB.
This patch adds an exception for dram base not within 3GB,
which will place fdt at dram_end align 16MB.
riscv_setup_rom_reset_vec() also needs to be modified
Signed-off-by: Dylan Jhong <dylan@andestech.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-Id: <20220419115945.37945-1-dylan@andestech.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
RISC-V privilege spec defines that mtime is exposed as a memory-mapped
machine-mode read-write register. However, as QEMU uses host monotonic
timer as timer source, this makes mtime to be read-only in RISC-V
ACLINT.
This patch makes mtime to be writable by recording the time delta value
between the mtime value to be written and the timer value at the time
mtime is written. Time delta value is then added back whenever the timer
value is retrieved.
Signed-off-by: Frank Chang <frank.chang@sifive.com>
Reviewed-by: Jim Shu <jim.shu@sifive.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-Id: <20220420080901.14655-4-frank.chang@sifive.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
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
# -----BEGIN PGP SIGNATURE-----
#
# iQJNBAABCAA3FiEE4aXFk81BneKOgxXPPCUl7RQ2DN4FAmJhPSUZHHBldGVyLm1h
# eWRlbGxAbGluYXJvLm9yZwAKCRA8JSXtFDYM3hAsD/4qzZK6LFL4kFH6E4z3tWIn
# ErHrfPGUt/SEfHLP+stQP/loFgkR1SNzcrIZ/HiDCB/W+IqQKuP+tHin2lMhO1tR
# KM6suUO1In2hoxfzimVta4F4GVN8ifY69qUYhaRxcBYSUpRXDNFJGsRIeT5JeUMd
# SArZUifRs7JUo25rIkg5Y+YZE37dmiA5gcuswtoLPa/UlDVqRxihLnItySmeutsc
# /Y8d/iym/ydlhvtL1OUt1KKYeg4ykrPzJCfvopsT2xgkwwB0PYci8//fa5IrRVlp
# Uw6yDssZrDIcXfVz88rdriILaszicCv8lOhTH6I74oXCatiyvi4BEzW8uGqVS8wt
# ff+AaKvGqb5t4GKKhCdpL2NzDwKBGWZHuruACs9IfvMkz62HE12Vr99qAKdQ3s93
# QnFIyUKg90mGkvKy8336zX3hnWjPH8wTASOXbNrgnt6GVLkqwy9ibug5kS+n77eJ
# BnkE5p3OfMVJ5a4o+iZbbDJKfzhNUHDSMIBbG1jRNzax1RgxOBtHFSqP5jmbpm+S
# agyr8h+Md0Tx1dwZKxdCGyvcbSZiG2WxRnci3dyT4MqYY1t1GEpOfcs1EN+CYKwG
# iuezZzJopjOFGaXQaB3OvbvCKxuroHKG61SmDmx+5OkfAxhrqe4ulwYij4jhsyhH
# t8zGzDOKLakv3li90xCX/w==
# =Rke9
# -----END PGP SIGNATURE-----
# gpg: Signature made Thu 21 Apr 2022 04:16:53 AM PDT
# gpg: using RSA key E1A5C593CD419DE28E8315CF3C2525ED14360CDE
# gpg: issuer "peter.maydell@linaro.org"
# gpg: Good signature from "Peter Maydell <peter.maydell@linaro.org>" [full]
# gpg: aka "Peter Maydell <pmaydell@gmail.com>" [full]
# gpg: aka "Peter Maydell <pmaydell@chiark.greenend.org.uk>" [full]
* 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>
The only time we use the int_combiner_irq[] and ext_combiner_irq[]
arrays in the Exynos4210Irq struct is during realize of the SoC -- we
initialize them with the input IRQs of the combiner devices, and then
connect those to outputs of other devices in
exynos4210_init_board_irqs(). Now that the combiner objects are
easily accessible as s->int_combiner and s->ext_combiner we can make
the connections directly from one device to the other without going
via these arrays.
Since these are the only two remaining elements of Exynos4210Irq,
we can remove that struct entirely.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20220404154658.565020-19-peter.maydell@linaro.org
At this point, the function exynos4210_init_board_irqs() splits input
IRQ lines to connect them to the input combiner, output combiner and
external GIC. The function exynos4210_combiner_get_gpioin() splits
some of the combiner input lines further to connect them to multiple
different inputs on the combiner.
Because (unlike qemu_irq_split()) the TYPE_SPLIT_IRQ device has a
configurable number of outputs, we can do all this in one place, by
making exynos4210_init_board_irqs() add extra outputs to the splitter
device when it must be connected to more than one input on each
combiner.
We do this with a new data structure, the combinermap, which is an
array each of whose elements is a list of the interrupt IDs on the
combiner which must be tied together. As we loop through each
interrupt ID, if we find that it is the first one in one of these
lists, we configure the splitter device with eonugh extra outputs and
wire them up to the other interrupt IDs in the list.
Conveniently, for all the cases where this is necessary, the
lowest-numbered interrupt ID in each group is in the range of the
external combiner, so we only need to code for this in the first of
the two loops in exynos4210_init_board_irqs().
The old code in exynos4210_combiner_get_gpioin() which is being
deleted here had several problems which don't exist in the new code
in its handling of the multi-core timer interrupts:
(1) the case labels specified bits 4 ... 8, but bit '8' doesn't
exist; these should have been 4 ... 7
(2) it used the input irq[EXYNOS4210_COMBINER_GET_IRQ_NUM(1, bit + 4)]
multiple times as the input of several different splitters,
which isn't allowed
(3) in an apparent cut-and-paste error, the cases for all the
multi-core timer inputs used "bit + 4" even though the
bit range for the case was (intended to be) 4 ... 7, which
meant it was looking at non-existent bits 8 ... 11.
None of these exist in the new code.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20220404154658.565020-17-peter.maydell@linaro.org
The combiner_grp_to_gic_id[] array includes the EXT_GIC_ID_MCT_G0
and EXT_GIC_ID_MCT_G1 multiple times. This means that we will
connect multiple IRQs up to the same external GIC input, which
is not permitted. We do the same thing in the code in
exynos4210_init_board_irqs() because the conditionals selecting
an irq_id in the first loop match multiple interrupt IDs.
Overall we do this for interrupt IDs
(1, 4), (12, 4), (35, 4), (51, 4), (53, 4) for EXT_GIC_ID_MCT_G0
and
(1, 5), (12, 5), (35, 5), (51, 5), (53, 5) for EXT_GIC_ID_MCT_G1
These correspond to the cases for the multi-core timer that we are
wiring up to multiple inputs on the combiner in
exynos4210_combiner_get_gpioin(). That code already deals with all
these interrupt IDs being the same input source, so we don't need to
connect the external GIC interrupt for any of them except the first
(1, 4) and (1, 5). Remove the array entries and conditionals which
were incorrectly causing us to wire up extra lines.
This bug didn't cause any visible effects, because we only connect
up a device to the "primary" ID values (1, 4) and (1, 5), so the
extra lines would never be set to a level.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20220404154658.565020-16-peter.maydell@linaro.org
The function exynos4210_combiner_get_gpioin() currently lives in
exynos4210_combiner.c, but it isn't really part of the combiner
device itself -- it is a function that implements the wiring up of
some interrupt sources to multiple combiner inputs. Move it to live
with the other SoC-level code in exynos4210.c, along with a few
macros previously defined in exynos4210.h which are now used only
in exynos4210.c.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20220404154658.565020-11-peter.maydell@linaro.org
The only time we use the ext_gic_irq[] array in the Exynos4210Irq
struct is during realize of the SoC -- we initialize it with the
input IRQs of the external GIC device, and then connect those to
outputs of other devices further on in realize (including in the
exynos4210_init_board_irqs() function). Now that the ext_gic object
is easily accessible as s->ext_gic we can make the connections
directly from one device to the other without going via this array.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20220404154658.565020-10-peter.maydell@linaro.org
The function exynos4210_init_board_irqs() currently lives in
exynos4210_gic.c, but it isn't really part of the exynos4210.gic
device -- it is a function that implements (some of) the wiring up of
interrupts between the SoC's GIC and combiner components. This means
it fits better in exynos4210.c, which is the SoC-level code. Move it
there. Similarly, exynos4210_git_irq() is used almost only in the
SoC-level code, so move it too.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20220404154658.565020-8-peter.maydell@linaro.org
The exynos4210 code currently has two very similar arrays of IRQs:
* board_irqs is a field of the Exynos4210Irq struct which is filled
in by exynos4210_init_board_irqs() with the appropriate qemu_irqs
for each IRQ the board/SoC can assert
* irq_table is a set of qemu_irqs pointed to from the
Exynos4210State struct. It's allocated in exynos4210_init_irq,
and the only behaviour these irqs have is that they pass on the
level to the equivalent board_irqs[] irq
The extra indirection through irq_table is unnecessary, so coalesce
these into a single irq_table[] array as a direct field in
Exynos4210State which exynos4210_init_board_irqs() fills in.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20220404154658.565020-6-peter.maydell@linaro.org
The only time we use the int_gic_irq[] array in the Exynos4210Irq
struct is in the exynos4210_realize() function: we initialize it with
the GPIO inputs of the a9mpcore device, and then a bit later on we
connect those to the outputs of the internal combiner. Now that the
a9mpcore object is easily accessible as s->a9mpcore we can make the
connection directly from one device to the other without going via
this array.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20220404154658.565020-5-peter.maydell@linaro.org
The exynos4210 SoC mostly creates its child devices as if it were
board code. This includes the a9mpcore object. Switch that to a
new-style "embedded in the state struct" creation, because in the
next commit we're going to want to refer to the object again further
down in the exynos4210_realize() function.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20220404154658.565020-4-peter.maydell@linaro.org
The Exynos4210 SoC device currently uses a custom device
"exynos4210.irq_gate" to model the OR gate that feeds each CPU's IRQ
line. We have a standard TYPE_OR_IRQ device for this now, so use
that instead.
(This is a migration compatibility break, but that is OK for this
machine type.)
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20220404154658.565020-2-peter.maydell@linaro.org
Use an anonymous output GPIO line to connect the OCC device with the
PSIHB device and raise the appropriate PSI IRQ line depending on the
processor model.
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20220323072846.1780212-4-clg@kaod.org>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Create an anonymous output GPIO line to connect the LPC device with
the PSIHB device and raise the appropriate PSI IRQ line depending on
the processor model.
A temporary __pnv_psi_irq_set() routine is introduced to handle the
transition. It will be removed when all devices raising PSI interrupts
are converted to use GPIOs.
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20220323072846.1780212-3-clg@kaod.org>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
On HW, the PSI and FSP interrupt levels are muxed under the same
interrupt number. For coding reasons, an extra IRQ number was
introduced to index register values in an array. It increased the
count of IRQs which do not fit in the PSI IRQ range anymore.
The PSI and FSP interrupts should be modeled with an extra level of
GPIO lines but since QEMU does not support them, simply drop the extra
number to stay within the IRQ range.
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20220323072846.1780212-2-clg@kaod.org>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
* Add cpu0-id to query-sev-capabilities
* whpx support for breakpoints and stepping
* initial support for Hyper-V Synthetic Debugging
* use monotonic clock for QemuCond and QemuSemaphore
* Remove qemu-common.h include from most units and lots of other clenaups
* do not include headers for all virtio devices in virtio-ccw.h
# -----BEGIN PGP SIGNATURE-----
#
# iQFIBAABCAAyFiEE8TM4V0tmI4mGbHaCv/vSX3jHroMFAmJXCQAUHHBib256aW5p
# QHJlZGhhdC5jb20ACgkQv/vSX3jHroNT6wf+NHDJUEdDiwaVGVTGXgHuiaycsymi
# FpNPiw/+XxSGN5xF3fkUGgqaDrcwIYwVfnXlghKSz8kp1cP3cjxa5CzNMLGTp5je
# N6BxFbD7yC6dhagGm3mj32jlsptv3M38OHqKc3t+RaUAotP5RF2VdCyfUBLG6vU0
# aMzvMfMtB5aG0D8Fr5EV63t1JMTceFU0YxsG73UCFs2Yx4Z0cGBbNxMbHweRhd1q
# tPeVDS46MFPM3/2cGGHpeeqxkoCTU7A9j1VuNQI3k+Kg+6W5YVxiK/UP7bw77E/a
# yAHsmIVTNro8ajMBch73weuHtGtdfFLvCKc6QX6aVjzK4dF1voQ01E7gPQ==
# =rMle
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 13 Apr 2022 10:31:44 AM PDT
# gpg: using RSA key F13338574B662389866C7682BFFBD25F78C7AE83
# gpg: issuer "pbonzini@redhat.com"
# gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>" [undefined]
# gpg: aka "Paolo Bonzini <pbonzini@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: 46F5 9FBD 57D6 12E7 BFD4 E2F7 7E15 100C CD36 69B1
# Subkey fingerprint: F133 3857 4B66 2389 866C 7682 BFFB D25F 78C7 AE83
* tag 'for-upstream' of https://gitlab.com/bonzini/qemu: (53 commits)
target/i386: Remove unused XMMReg, YMMReg types and CPUState fields
target/i386: do not access beyond the low 128 bits of SSE registers
virtio-ccw: do not include headers for all virtio devices
virtio-ccw: move device type declarations to .c files
virtio-ccw: move vhost_ccw_scsi to a separate file
s390x: follow qdev tree to detect SCSI device on a CCW bus
hw: hyperv: Initial commit for Synthetic Debugging device
hyperv: Add support to process syndbg commands
hyperv: Add definitions for syndbg
hyperv: SControl is optional to enable SynIc
thread-posix: optimize qemu_sem_timedwait with zero timeout
thread-posix: implement Semaphore with QemuCond and QemuMutex
thread-posix: use monotonic clock for QemuCond and QemuSemaphore
thread-posix: remove the posix semaphore support
whpx: Added support for breakpoints and stepping
build-sys: simplify AF_VSOCK check
build-sys: drop ntddscsi.h check
Remove qemu-common.h include from most units
qga: remove explicit environ argument from exec/spawn
Move fcntl_setfl() to oslib-posix
...
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
vmstate_acpi_pcihp_use_acpi_index() was expecting AcpiPciHpState
as state but it actually received PIIX4PMState, because
VMSTATE_PCI_HOTPLUG is a macro and not another struct.
So it ended up accessing random pointer, which resulted
in 'false' return value and acpi_index field wasn't ever
sent.
However in 7.0 that pointer de-references to value > 0, and
destination QEMU starts to expect the field which isn't
sent in migratioon stream from older QEMU (6.2 and older).
As result migration fails with:
qemu-system-x86_64: Missing section footer for 0000:00:01.3/piix4_pm
qemu-system-x86_64: load of migration failed: Invalid argument
In addition with QEMU-6.2, destination due to not expected
state, also never expects the acpi_index field in migration
stream.
Q35 is not affected as it always sends/expects the field as
long as acpi based PCI hotplug is enabled.
Fix issue by introducing compat knob to never send/expect
acpi_index in migration stream for 6.2 and older PC machine
types and always send it for 7.0 and newer PC machine types.
Diagnosed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Fixes: b32bd76 ("pci: introduce acpi-index property for PCI device")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/932
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
SynDbg commands can come from two different flows:
1. Hypercalls, in this mode the data being sent is fully
encapsulated network packets.
2. SynDbg specific MSRs, in this mode only the data that needs to be
transfered is passed.
Signed-off-by: Jon Doron <arilou@gmail.com>
Reviewed-by: Emanuele Giuseppe Esposito <eesposit@redhat.com>
Message-Id: <20220216102500.692781-4-arilou@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Replace a config-time define with a compile time condition
define (compatible with clang and gcc) that must be declared prior to
its usage. This avoids having a global configure time define, but also
prevents from bad usage, if the config header wasn't included before.
This can help to make some code independent from qemu too.
gcc supports __BYTE_ORDER__ from about 4.6 and clang from 3.2.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
[ For the s390x parts I'm involved in ]
Acked-by: Halil Pasic <pasic@linux.ibm.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20220323155743.1585078-7-marcandre.lureau@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The spec defines 3 registers, even though only index 0 and 2 are valid
on POWER9. The same model is used on POWER10. Register 1 is defined
there but we currently don't use it in skiboot. So we can keep
reporting an error on write.
Reported by Coverity (CID 1487176).
Fixes: 4f9924c4d4 ("ppc/pnv: Add models for POWER9 PHB4 PCIe Host bridge")
Suggested-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20220401091925.770803-1-fbarrat@linux.ibm.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
The timebase is allocated during spapr_realize_vcpu() and it's not
freed. This results in memory leaks when doing vcpu unplugs:
==636935==
==636935== 144 (96 direct, 48 indirect) bytes in 1 blocks are definitely lost in loss record 6
,461 of 8,135
==636935== at 0x4897468: calloc (vg_replace_malloc.c:760)
==636935== by 0x5077213: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.6400.4)
==636935== by 0x507757F: g_malloc0_n (in /usr/lib64/libglib-2.0.so.0.6400.4)
==636935== by 0x93C3FB: cpu_ppc_tb_init (ppc.c:1066)
==636935== by 0x97BC2B: spapr_realize_vcpu (spapr_cpu_core.c:268)
==636935== by 0x97C01F: spapr_cpu_core_realize (spapr_cpu_core.c:337)
==636935== by 0xD4626F: device_set_realized (qdev.c:531)
==636935== by 0xD55273: property_set_bool (object.c:2273)
==636935== by 0xD523DF: object_property_set (object.c:1408)
==636935== by 0xD588B7: object_property_set_qobject (qom-qobject.c:28)
==636935== by 0xD52897: object_property_set_bool (object.c:1477)
==636935== by 0xD4579B: qdev_realize (qdev.c:333)
==636935==
This patch adds a cpu_ppc_tb_free() helper in hw/ppc/ppc.c to allow us
to free the timebase. This leak is then solved by calling
cpu_ppc_tb_free() in spapr_unrealize_vcpu().
Fixes: 6f4b5c3ec5 ("spapr: CPU hot unplug support")
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Message-Id: <20220329124545.529145-2-danielhb413@gmail.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
One less qemu-specific macro. It also helps to make some headers/units
only depend on glib, and thus moved in standalone projects eventually.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Richard W.M. Jones <rjones@redhat.com>
