The XIVE and XICS-on-XIVE KVM devices on POWER9 hosts can greatly reduce
their consumption of some scarce HW resources, namely Virtual Presenter
identifiers, if they know the maximum number of vCPUs that may run in the
VM.
Prepare ground for this by passing the value down to xics_kvm_connect()
and kvmppc_xive_connect(). This is purely mechanical, no functional
change.
Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <157478678301.67101.2717368060417156338.stgit@bahia.tlslab.ibm.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Update to mainline commit be2eca94d144 ("Merge tag 'for-linus-5.5-1'`
of git://github.com/cminyard/linux-ipmi")
Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <157478677756.67101.11558821804418331832.stgit@bahia.tlslab.ibm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The TIMA operations are performed on behalf of the XIVE IVPE sub-engine
(Presenter) on the thread interrupt context registers. The current
operations supported by the model are simple and do not require access
to the controller but more complex operations will need access to the
controller NVT table and to its configuration.
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20191125065820.927-13-clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The XiveFabric QOM interface acts as the PowerBUS interface between
the interrupt controller and the system and should be implemented by
the QEMU machine. On HW, the XIVE sub-engine is responsible for the
communication with the other chip is the Common Queue (CQ) bridge
unit.
This interface offers a 'match_nvt' handler to perform the CAM line
matching when looking for a XIVE Presenter with a dispatched NVT.
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20191125065820.927-9-clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
When the TIMA of a CPU needs to be accessed from the indirect page,
the thread id of the target CPU is first stored in the PC_TCTXT_INDIR0
register. This thread id is relative to the chip and not to the system.
Introduce a helper routine to look for a CPU of a given PIR and fix
pnv_xive_get_indirect_tctx() to scan only the threads of the local
chip and not the whole machine.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20191125065820.927-8-clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
and use this helper to exclude CPUs which are not enabled in the XIVE
controller.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20191125065820.927-7-clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Allocating a big void * array to store multiple objects isn't a
recommended practice for various reasons:
- no compile time type checking
- potential dangling pointers if a reference on an individual is
taken and the array is freed later on
- duplicate boiler plate everywhere the array is browsed through
Allocate an array of pointers and populate it instead.
Signed-off-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20191125065820.927-4-clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
When the XIVE IVRE sub-engine (XiveRouter) looks for a Notification
Virtual Target (NVT) to notify, it broadcasts a message on the
PowerBUS to find an XIVE IVPE sub-engine (Presenter) with the NVT
dispatched on one of its HW threads, and then forwards the
notification if any response was received.
The current XIVE presenter model is sufficient for the pseries machine
because it has a single interrupt controller device, but the PowerNV
machine can have multiple chips each having its own interrupt
controller. In this case, the XIVE presenter model is too simple and
the CAM line matching should scan all chips of the system.
To start fixing this issue, we first extend the XIVE Router model with
a new XivePresenter QOM interface representing the XIVE IVPE
sub-engine. This interface exposes a 'match_nvt' handler which the
sPAPR and PowerNV XIVE Router models will need to implement to perform
the CAM line matching.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20191125065820.927-2-clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The BMC of the OpenPOWER systems monitors the machine state using
sensors, controls the power and controls the access to the PNOR flash
device containing the firmware image required to boot the host.
QEMU models the power cycle process, access to the sensors and access
to the PNOR device. But, for these features to be available, the QEMU
PowerNV machine needs two extras devices on the command line, an IPMI
BT device for communication and a BMC backend device:
-device ipmi-bmc-sim,id=bmc0 -device isa-ipmi-bt,bmc=bmc0,irq=10
The BMC properties are then defined accordingly in the device tree and
OPAL self adapts. If a BMC device and an IPMI BT device are not
available, OPAL does not try to communicate with the BMC in any
manner. This is not how real systems behave.
To be closer to the default behavior, create an IPMI BMC simulator
device and an IPMI BT device at machine initialization time. We loose
the ability to define an external BMC device but there are benefits:
- a better match with real systems,
- a better test coverage of the OPAL code,
- system powerdown and reset commands that work,
- a QEMU device tree compliant with the specifications (*).
(*) Still needs a MBOX device.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20191121162340.11049-1-clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
This activates HIOMAP support on the QEMU PowerNV machine. The PnvPnor
model is used to access the flash contents. The model simply maps the
contents at a fix offset and enables or disables the mapping.
HIOMAP Protocol description :
https://github.com/openbmc/hiomapd/blob/master/Documentation/protocol.md
Reviewed-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20191028070027.22752-3-clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Each vCPU in the system is identified with an NVT identifier which is
pushed in the OS CAM line (QW1W2) of the HW thread interrupt context
register when the vCPU is dispatched on a HW thread. This identifier
is used by the presenter subengine to find a matching target to notify
of an event. It is also used to fetch the associate NVT structure
which may contain pending interrupts that need a resend.
Add a couple of helpers for the NVT ids. The NVT space is 19 bits
wide, giving a maximum of 512K per chip.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20191115162436.30548-3-clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
When an interrupt can not be presented to a vCPU, because it is not
running on any of the HW treads, the XIVE presenter updates the
Interrupt Pending Buffer register of the associated XIVE NVT
structure. This is only done if backlog is activated in the END but
this is generally the case.
The current code assumes that the fields of the NVT structure is
architected with the same layout of the thread interrupt context
registers. Fix this assumption and define an offset for the IPB
register backup value in the NVT.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20191115162436.30548-2-clg@kaod.org>
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
On a POWERPC PowerNV system, the host firmware is stored in a PNOR
flash chip which contents is mapped on the LPC bus. This model adds a
simple dummy device to map the contents of a block device in the host
address space.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20191021131215.3693-2-clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* Add support for Cortex-M7 CPU
* exynos4210_gic: Suppress gcc9 format-truncation warnings
* aspeed: Various minor bug fixes and improvements
* aspeed: Add support for the tacoma-bmc board
* Honour HCR_EL32.TID1 and .TID2 trapping requirements
* Handle trapping to EL2 of AArch32 VMRS instructions
* Handle AArch32 CP15 trapping via HSTR_EL2
* Add support for missing Jazelle system registers
* arm/arm-powerctl: set NSACR.{CP11, CP10} bits in arm_set_cpu_on
* Add support for DC CVAP & DC CVADP instructions
* Fix assertion when SCR.NS is changed in Secure-SVC &c
* enable SHPC native hot plug in arm ACPI
-----BEGIN PGP SIGNATURE-----
iQJNBAABCAA3FiEE4aXFk81BneKOgxXPPCUl7RQ2DN4FAl33ZZcZHHBldGVyLm1h
eWRlbGxAbGluYXJvLm9yZwAKCRA8JSXtFDYM3o16D/9RvnobR+zYPcXUTfEy1pX3
zGdjgesm2iwots4NPnYEKQdOsoKOcaoCZASlisjTdXOcAWBl6OVIQ9VC3uiydheF
KInvG2nI31ISFGkAbRzuVK01gY3R7Oz/HKPZqfdWT0GaUh8WFaEUPPfM4osnKrj2
Lbz2S6YRs1i5BzZHQq41R02T/S31gI57n8SWItjvN//psOOZdnmgjDtoh8J9l6i3
uEVcBS6/jeSiYK191y9PIOeLtuqtnW1AsHI7hpKHMkla6kGkCBaz7KchyfmbTU/E
tJhJbk5i18irekXdsTlI/RqixO06/l2GLRhSdgyFYHT8PvABQcEjZl5+mYv0965i
DVNv8Ehqk5ICCVfHVAqN17xNs0V8iMH5H3L9MnnFkrjHpM3j3VXLLMRWsZNAE4u4
BDypXrcbGK57vE6Intl9G+FASQTdQm9hgYrFwbfLPT8f29LqKnxmMK9MgBIizTr2
m+Fd6iW6mrhKSdBQyxnCq0T6/KkY2zM7GPg/ISnEtHAN6HzagxORRukk/cYYdv4W
dK/aCgfYVXjjqP0VDR0+p8xsxXsMv1Y/FiiPpZuMX0RciKUpcEbH1Yg1R04nhdq+
lJAbXmA7ZYE7CVQRw5oWVR5GMkfTbfcx9XsaWQ7YQRfrKeZIOSnl1rt3DFhtwQp8
jpq8btNBr4QBpw5xejtgkA==
=V+AK
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20191216-1' into staging
target-arm queue:
* Add support for Cortex-M7 CPU
* exynos4210_gic: Suppress gcc9 format-truncation warnings
* aspeed: Various minor bug fixes and improvements
* aspeed: Add support for the tacoma-bmc board
* Honour HCR_EL32.TID1 and .TID2 trapping requirements
* Handle trapping to EL2 of AArch32 VMRS instructions
* Handle AArch32 CP15 trapping via HSTR_EL2
* Add support for missing Jazelle system registers
* arm/arm-powerctl: set NSACR.{CP11, CP10} bits in arm_set_cpu_on
* Add support for DC CVAP & DC CVADP instructions
* Fix assertion when SCR.NS is changed in Secure-SVC &c
* enable SHPC native hot plug in arm ACPI
# gpg: Signature made Mon 16 Dec 2019 11:08:07 GMT
# gpg: using RSA key E1A5C593CD419DE28E8315CF3C2525ED14360CDE
# gpg: issuer "peter.maydell@linaro.org"
# gpg: Good signature from "Peter Maydell <peter.maydell@linaro.org>" [ultimate]
# gpg: aka "Peter Maydell <pmaydell@gmail.com>" [ultimate]
# gpg: aka "Peter Maydell <pmaydell@chiark.greenend.org.uk>" [ultimate]
# Primary key fingerprint: E1A5 C593 CD41 9DE2 8E83 15CF 3C25 25ED 1436 0CDE
* remotes/pmaydell/tags/pull-target-arm-20191216-1: (34 commits)
target/arm: ensure we use current exception state after SCR update
hw/arm/virt: Simplify by moving the gic in the machine state
hw/arm/acpi: enable SHPC native hot plug
hw/arm/acpi: simplify AML bit and/or statement
hw/arm/sbsa-ref: Simplify by moving the gic in the machine state
target/arm: Add support for DC CVAP & DC CVADP ins
migration: ram: Switch to ram block writeback
Memory: Enable writeback for given memory region
tcg: cputlb: Add probe_read
arm/arm-powerctl: set NSACR.{CP11, CP10} bits in arm_set_cpu_on()
target/arm: Add support for missing Jazelle system registers
target/arm: Handle AArch32 CP15 trapping via HSTR_EL2
target/arm: Handle trapping to EL2 of AArch32 VMRS instructions
target/arm: Honor HCR_EL2.TID1 trapping requirements
target/arm: Honor HCR_EL2.TID2 trapping requirements
aspeed: Change the "nic" property definition
aspeed: Change the "scu" property definition
gpio: fix memory leak in aspeed_gpio_init()
aspeed: Add support for the tacoma-bmc board
aspeed: Remove AspeedBoardConfig array and use AspeedMachineClass
...
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Make the gic a field in the machine state, and instead of filling
an array of qemu_irq and passing it around, directly call
qdev_get_gpio_in() on the gic field.
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Luc Michel <luc.michel@greensocs.com>
Message-id: 20191209090306.20433-1-philmd@redhat.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Add an option to trigger memory writeback to sync given memory region
with the corresponding backing store, case one is available.
This extends the support for persistent memory, allowing syncing on-demand.
Signed-off-by: Beata Michalska <beata.michalska@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20191121000843.24844-3-beata.michalska@linaro.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
AspeedBoardConfig is a redundant way to define class attributes and it
complexifies the machine definition and initialization.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Message-id: 20191119141211.25716-14-clg@kaod.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Each CS has its own Read Timing Compensation Register on newer SoCs.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Message-id: 20191119141211.25716-13-clg@kaod.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The AST2600 control register sneakily changed the meaning of bit 4
without anyone noticing. It no longer controls the 1MHz vs APB clock
select, and instead always runs at 1MHz.
The AST2500 was always 1MHz too, but it retained bit 4, making it read
only. We can model both using the same fixed 1MHz calculation.
Fixes: 6b2b2a703c ("hw: wdt_aspeed: Add AST2600 support")
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Message-id: 20191119141211.25716-10-clg@kaod.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The I2C controller of the Aspeed AST2500 and AST2600 SoCs supports DMA
transfers to and from DRAM.
A pair of registers defines the buffer address and the length of the
DMA transfer. The address should be aligned on 4 bytes and the maximum
length should not exceed 4K. The receive or transmit DMA transfer can
then be initiated with specific bits in the Command/Status register of
the controller.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Tested-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Message-id: 20191119141211.25716-5-clg@kaod.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Currently, we link the DRAM memory region to the FMC model (for DMAs)
through a property alias at the SoC level. The I2C model will need a
similar region for DMA support, add a DRAM region property at the SoC
level for both model to use.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Tested-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Message-id: 20191119141211.25716-4-clg@kaod.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The SRAM must be enabled before using the Buffer Pool mode or the DMA
mode. This is not required on other SoCs.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Tested-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Message-id: 20191119141211.25716-3-clg@kaod.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The Aspeed I2C controller can operate in different transfer modes :
- Byte Buffer mode, using a dedicated register to transfer a
byte. This is what the model supports today.
- Pool Buffer mode, using an internal SRAM to transfer multiple
bytes in the same command sequence.
Each SoC has different SRAM characteristics. On the AST2400, 2048
bytes of SRAM are available at offset 0x800 of the controller AHB
window. The pool buffer can be configured from 1 to 256 bytes per bus.
On the AST2500, the SRAM is at offset 0x200 and the pool buffer is of
16 bytes per bus.
On the AST2600, the SRAM is at offset 0xC00 and the pool buffer is of
32 bytes per bus. It can be splitted in two for TX and RX but the
current model does not add support for it as it it unused by known
drivers.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Tested-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Message-id: 20191119141211.25716-2-clg@kaod.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Add 5.0 machine types for arm/i440fx/q35/s390x/spapr.
For i440fx and q35, unversioned cpu models are still translated
to -v1; I'll leave changing this (if desired) to the respective
maintainers.
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
Message-Id: <20191112104811.30323-1-cohuck@redhat.com>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Virtio spec 1.1 (and earlier), 5.2.5.2 Driver Requirements: Device
Initialization:
"Devices SHOULD always offer VIRTIO_BLK_F_FLUSH, and MUST offer it if
they offer VIRTIO_BLK_F_CONFIG_WCE"
Currently F_CONFIG_WCE and F_WCE are not connected to each other.
Qemu will advertise F_CONFIG_WCE if config-wce argument is
set for virtio-blk device. And F_WCE is advertised only if
underlying block backend actually has it's caching enabled.
Fix this by advertising F_WCE if F_CONFIG_WCE is also advertised.
To preserve backwards compatibility with newer machine types make this
behaviour governed by "x-enable-wce-if-config-wce" virtio-blk-device
property and introduce hw_compat_4_2 with new property being off by
default for all machine types <= 4.2 (but don't introduce 4.3
machine type itself yet).
Signed-off-by: Evgeny Yakovlev <wrfsh@yandex-team.ru>
Message-Id: <1572978137-189218-1-git-send-email-wrfsh@yandex-team.ru>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
The property doesn't make much sense for a vhost-user device.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20191116112016.14872-1-marcandre.lureau@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Here's the first 4.2 hard freeze pull request from me. This has:
* A fix for some testcases that cause errors on older host kernels
(e.g. RHEL7), with our new default configuration of VSMT mode
* Changes to make VFIO devices interact properly with change of irq
chip caused by PAPR feature negotiation. This is more involved
than I would like, but it's a problem in real use cases and I
can't see an easier way to handle it.
* Fix an error with ms6522 counters for the g3beige machine
* Fix a coverity warning
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEdfRlhq5hpmzETofcbDjKyiDZs5IFAl3cvZAACgkQbDjKyiDZ
s5LzYA/+KUmXnvvaVfRMLqYZuBVLxUN7+b472mYxrZY8neQ4yO9JYcFRb1FWlZKo
zqUjBXljARPJZoT4pGhobqgR6hs/nbn6WaN0oI0ZrxHKMUsPe56c90PbvprtiGMe
qGCoSuWQHccwouSZFmMcOUqO8rT+wlwMV+if/WbwNvhm4oCvA9Lcx2bBNllLN8XB
bIdiZACsk+XHJDm5SDNr/Wyhz/N8tODStuKPYtyoHd5LarXVUymqljaNJhEIcqQZ
awFP200fX6fKR+jRUV7AnG5faF2p1P6K2khwMYQF0QzpEQg4d9hKBs7SsSkzY3YD
8nVeXGi6201kw9V5tqzqiG0mNcCME8Pb3K4fsmOfLSWbnOax8yv9tisz8+FYuful
KxUBjp9cE/Tla+Zg1SeQ8VZrHJhcX98aT57CWQCtuYX+82krHQCKMSRpbEJ6ECRJ
dChfXrAqmtG0mPd7sypeQPuJRBMOwuJsuJr6a0glDY61XmXCJbH5R6Jf+iDQ2Nf8
owx07xNQ5fVO0RYDqr+eZSTfllW1P2FNI8sz0XFp6/dAz3KbLuNbzREFZcdEV1Gp
CdJd9UA1P45c/BOOQy7FAeewKhuhgBE1S7m5brX9t1CorUW2zaM/hLwd3ZII0UyE
if8hYpfeTY+lhNpu0hCpyzecZOMBabLAmQqIUUKO/wkydcIKYUg=
=GHGC
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-4.2-20191126' into staging
ppc patch queue for 2019-11-26
Here's the first 4.2 hard freeze pull request from me. This has:
* A fix for some testcases that cause errors on older host kernels
(e.g. RHEL7), with our new default configuration of VSMT mode
* Changes to make VFIO devices interact properly with change of irq
chip caused by PAPR feature negotiation. This is more involved
than I would like, but it's a problem in real use cases and I
can't see an easier way to handle it.
* Fix an error with ms6522 counters for the g3beige machine
* Fix a coverity warning
# gpg: Signature made Tue 26 Nov 2019 05:52:16 GMT
# gpg: using RSA key 75F46586AE61A66CC44E87DC6C38CACA20D9B392
# gpg: Good signature from "David Gibson <david@gibson.dropbear.id.au>" [full]
# gpg: aka "David Gibson (Red Hat) <dgibson@redhat.com>" [full]
# gpg: aka "David Gibson (ozlabs.org) <dgibson@ozlabs.org>" [full]
# gpg: aka "David Gibson (kernel.org) <dwg@kernel.org>" [unknown]
# Primary key fingerprint: 75F4 6586 AE61 A66C C44E 87DC 6C38 CACA 20D9 B392
* remotes/dgibson/tags/ppc-for-4.2-20191126:
ppc/spapr_events: fix potential NULL pointer dereference in rtas_event_log_dequeue
mos6522: update counters when timer interrupts are off
spapr: Work around spurious warnings from vfio INTx initialization
spapr: Handle irq backend changes with VFIO PCI devices
vfio/pci: Respond to KVM irqchip change notifier
vfio/pci: Split vfio_intx_update()
kvm: Introduce KVM irqchip change notifier
pseries: fix migration-test and pxe-test
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Add the CRP as unimplemented thus avoiding bus errors when
guests access these registers.
Signed-off-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Luc Michel <luc.michel@greensocs.com>
Message-id: 20191115154734.26449-2-edgar.iglesias@gmail.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Awareness of an in kernel irqchip is usually local to the machine and its
top-level interrupt controller. However, in a few cases other things need
to know about it. In particular vfio devices need this in order to
accelerate interrupt delivery.
If interrupt routing is changed, such devices may need to readjust their
connection to the KVM irqchip. pci_bus_fire_intx_routing_notifier() exists
to do just this.
However, for the pseries machine type we have a situation where the routing
remains constant but the top-level irq chip itself is changed. This occurs
because of PAPR feature negotiation which allows the guest to decide
between the older XICS and newer XIVE irq chip models (both of which are
paravirtualized).
To allow devices like vfio to adjust to this change, introduce a new
notifier for the purpose kvm_irqchip_change_notify().
Cc: Alex Williamson <alex.williamson@redhat.com>
Cc: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Tested-by: Alex Williamson <alex.williamson@redhat.com>
Reviewed-by: Alex Williamson <alex.williamson@redhat.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
Acked-by: Alex Williamson <alex.williamson@redhat.com>
This patch adds an optional function pointer, "sym_cb", to
riscv_load_kernel() which provides the possibility to access the symbol
table during kernel loading.
The pointer is ignored, if supplied with Image or uImage file.
The Spike board requires the access to locate the HTIF symbols.
Fixes: 0ac24d56c5 ("hw/riscv: Split out the boot functions")
Buglink: https://bugs.launchpad.net/qemu/+bug/1835827
Signed-off-by: Siwei Zhuang <siwei.zhuang@data61.csiro.au>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
Attempting to migrate a VM using the microvm machine class results in the source
QEMU aborting with the following message/backtrace:
target/i386/machine.c:955:tsc_khz_needed: Object 0x555556608fa0 is not an
instance of type generic-pc-machine
abort()
object_class_dynamic_cast_assert()
vmstate_save_state_v()
vmstate_save_state()
vmstate_save()
qemu_savevm_state_complete_precopy()
migration_thread()
migration_thread()
migration_thread()
qemu_thread_start()
start_thread()
clone()
The access to the machine class returned by MACHINE_GET_CLASS() in
tsc_khz_needed() is crashing as it is trying to dereference a different
type of machine class object (TYPE_PC_MACHINE) to that of this microVM.
This can be resolved by extending the changes in the following commit
f0bb276bf8 ("hw/i386: split PCMachineState deriving X86MachineState from it")
and moving the save_tsc_khz field in PCMachineClass to X86MachineClass.
Fixes: f0bb276bf8 ("hw/i386: split PCMachineState deriving X86MachineState from it")
Signed-off-by: Liam Merwick <liam.merwick@oracle.com>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Message-Id: <1574075605-25215-1-git-send-email-liam.merwick@oracle.com>
Reviewed-by: Sergio Lopez <slp@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Qemu as server currently won't accept export names larger than 256
bytes, nor create dirty bitmap names longer than 1023 bytes, so most
uses of qemu as client or server have no reason to get anywhere near
the NBD spec maximum of a 4k limit per string.
However, we weren't actually enforcing things, ignoring when the
remote side violates the protocol on input, and also having several
code paths where we send oversize strings on output (for example,
qemu-nbd --description could easily send more than 4k). Tighten
things up as follows:
client:
- Perform bounds check on export name and dirty bitmap request prior
to handing it to server
- Validate that copied server replies are not too long (ignoring
NBD_INFO_* replies that are not copied is not too bad)
server:
- Perform bounds check on export name and description prior to
advertising it to client
- Reject client name or metadata query that is too long
- Adjust things to allow full 4k name limit rather than previous
256 byte limit
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20191114024635.11363-4-eblake@redhat.com>
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
We document that for qcow2 persistent bitmaps, the name cannot exceed
1023 bytes. It is inconsistent if transient bitmaps do not have to
abide by the same limit, and it is unlikely that any existing client
even cares about using bitmap names this long. It's time to codify
that ALL bitmaps managed by qemu (whether persistent in qcow2 or not)
have a documented maximum length.
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20191114024635.11363-3-eblake@redhat.com>
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
As long as we limit NBD names to 256 bytes (the bare minimum permitted
by the standard), stack-allocation works for parsing a name received
from the client. But as mentioned in a comment, we eventually want to
permit up to the 4k maximum of the NBD standard, which is too large
for stack allocation; so switch everything in the server to use heap
allocation. For now, there is no change in actually supported name
length.
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20191114024635.11363-2-eblake@redhat.com>
[eblake: fix uninit variable compile failure]
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
SpaprInterruptControllerClass and PnvChipClass have an intc_create() method
that calls the appropriate routine, ie. icp_create() or xive_tctx_create(),
to establish the link between the VCPU and the presenter component of the
interrupt controller during realize.
There aren't any symmetrical call to be called when the VCPU gets unrealized
though. It is assumed that object_unparent() is the only thing to do.
This is questionable because the parenting logic around the CPU and
presenter objects is really an implementation detail of the interrupt
controller. It shouldn't be open-coded in the machine code.
Fix this by adding an intc_destroy() method that undoes what was done in
intc_create(). Also NULLify the presenter pointers to avoid having
stale pointers around. This will allow to reliably check if a vCPU has
a valid presenter.
Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <157192724208.3146912.7254684777515287626.stgit@bahia.lan>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Laurent Vivier <lvivier@redhat.com>
This is a very simple versioning API which allows the plugin
infrastructure to check the API a plugin was built against. We also
expose a min/cur API version to the plugin via the info block in case
it wants to avoid using old deprecated APIs in the future.
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Robert Foley <robert.foley@linaro.org>
The boot.c code usually puts the CPU into NS mode directly when it is
booting a kernel. Since fc1120a7f5 this has included a
requirement to set NSACR to give NS state access to the FPU; we fixed
that for the usual code path in ece628fcf6. However, it is also
possible for a board model to request an alternative mode of booting,
where its 'board_setup' code hook runs in Secure state and is
responsible for doing the S->NS transition after it has done whatever
work it must do in Secure state. In this situation the board_setup
code now also needs to update NSACR.
This affects all boards which set info->secure_board_setup, which is
currently the 'raspi' and 'highbank' families. They both use the
common arm_write_secure_board_setup_dummy_smc().
Set the NSACR CP11 and CP10 bits in the code written by that
function, to allow FPU access in Non-Secure state when using dummy
SMC setup routine. Otherwise an AArch32 kernel booted on the
highbank or raspi boards will UNDEF as soon as it tries to use the
FPU.
Update the comment describing secure_board_setup to note the new
requirements on users of it.
This fixes a kernel panic when booting raspbian on raspi2.
Successfully tested with:
2017-01-11-raspbian-jessie-lite.img
2018-11-13-raspbian-stretch-lite.img
2019-07-10-raspbian-buster-lite.img
Fixes: fc1120a7f5
Signed-off-by: Clement Deschamps <clement.deschamps@greensocs.com>
Tested-by: Laurent Bonnans <laurent.bonnans@here.com>
Message-id: 20191104151137.81931-1-clement.deschamps@greensocs.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
[PMM: updated comment to boot.h to note new requirement on
users of secure_board_setup; edited/rewrote commit message]
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
All targets have now migrated away from the old unassigned_access
hook to the new do_transaction_failed hook. This means we can remove
the core-code infrastructure for that hook and the code that calls it.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-id: 20191108173732.11816-1-peter.maydell@linaro.org
Now all the users of ptimers have converted to the transaction-based
API, we can remove ptimer_init_with_bh() and all the code paths
that are used only by bottom-half based ptimers, and tidy up the
documentation comments to consider the transaction-based API the
only possibility.
The code changes result from:
* s->bh no longer exists
* s->callback is now always non-NULL
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20191025142411.17085-1-peter.maydell@linaro.org
PIIX southbridge is also used by the Malta MIPS machine.
Split the PIIX3 southbridge from i440FX northbridge.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEicHnj2Ae6GyGdJXLoqP9bt6twN4FAl3B/CwACgkQoqP9bt6t
wN5frA/9FNpyolvQu5bEUAPsNv8wpWH/+XAxoHhdhAVZYPTMot6Iv2liwAav9GsU
9M4JK8qjcwvbN0yqkt6ZUjzhIZoXGnNVOEXVz/gUuk2EDr7EwXymsTwWDErIt0Ap
0IUEDfaISntxgf4vq7aPjXEk9644uZOn1MYuIm+oI8rEP6xj/fCj18TDQtGNlJRr
sgY5S9jbv+qxK402QB9B8gpXxcP2IO5WN6jAwgOsMOOqxALwAzPNqRbMEBsuGbwk
Aoj0jrC9h0Y8puAwl8DHbEOFAmf7YBskH2fyOjasUT1t7p1FreGNW7Esf7Oq34Ui
9G3CSUMN6rDVn0yVUd9qdv34imfa7eq9ci1gfzBYRg5VtQkC3vC2Tn5XrT7ZVABp
721KtCl701O+lSn3AyBcl9/lbBLdEaHDq/OPR/08vkmJBJ1hUP13KwvdFtYYwxPT
BCq6ZxTKNmPNNJCSEHYhkJ7J4lkPobipN8bNnAZB9xq58vjPXcmZmDKo0R1VanHN
JXLGw/ZM3wEaVEWi/P3qydo3Vshr1g/vr7ZB+xjgnfr+/bTfjWZ3UkMHvFW18HOP
n5VT2Hqnf9qZrBRaoDVy3dPCXDoXmBZx0urAKcP+J6/6UacvOS9G+e/cEFuNDGTe
SVqtALilkfAhuJBKUHw2gH3pb22fatDHYJ6hDMDHs3PvCcEGffg=
=cQ/y
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/philmd-gitlab/tags/mips-next-20191105' into staging
The i440FX northbridge is only used by the PC machine, while the
PIIX southbridge is also used by the Malta MIPS machine.
Split the PIIX3 southbridge from i440FX northbridge.
# gpg: Signature made Tue 05 Nov 2019 22:48:12 GMT
# gpg: using RSA key 89C1E78F601EE86C867495CBA2A3FD6EDEADC0DE
# gpg: Good signature from "Philippe Mathieu-Daudé (Phil) <philmd@redhat.com>" [marginal]
# gpg: WARNING: This key is not certified with sufficiently trusted signatures!
# gpg: It is not certain that the signature belongs to the owner.
# Primary key fingerprint: 89C1 E78F 601E E86C 8674 95CB A2A3 FD6E DEAD C0DE
* remotes/philmd-gitlab/tags/mips-next-20191105: (21 commits)
hw/pci-host/i440fx: Remove the last PIIX3 traces
hw/pci-host: Rename incorrectly named 'piix' as 'i440fx'
hw/pci-host/piix: Extract PIIX3 functions to hw/isa/piix3.c
hw/pci-host/piix: Fix code style issues
hw/pci-host/piix: Move i440FX declarations to hw/pci-host/i440fx.h
hw/pci-host/piix: Define and use the PIIX IRQ Route Control Registers
hw/pci-host/piix: Move RCR_IOPORT register definition
hw/pci-host/piix: Extract piix3_create()
hw/i386: Remove obsolete LoadStateHandler::load_state_old handlers
hw/isa/piix4: Move piix4_create() to hw/isa/piix4.c
hw/mips/mips_malta: Extract the PIIX4 creation code as piix4_create()
hw/mips/mips_malta: Create IDE hard drive array dynamically
piix4: Add a MC146818 RTC Controller as specified in datasheet
piix4: Add an i8254 PIT Controller as specified in datasheet
piix4: Add an i8257 DMA Controller as specified in datasheet
piix4: Rename PIIX4 object to piix4-isa
Revert "irq: introduce qemu_irq_proxy()"
piix4: Add an i8259 Interrupt Controller as specified in datasheet
piix4: Add the Reset Control Register
MAINTAINERS: Keep PIIX4 South Bridge separate from PC Chipsets
...
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
'the' has a tendency to double up; squash them back down.
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Laurent Vivier <laurent@vivier.eu>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20191104185202.102504-1-dgilbert@redhat.com>
[lv: removed disas/libvixl/vixl/invalset.h change]
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
