The generated qapi_event_send_FOO() take an Error ** argument.  They
can't actually fail, because all they do with the argument is passing it
to functions that can't fail: the QObject output visitor, and the
@qmp_emit callback, which is either monitor_qapi_event_queue() or
event_test_emit().

Drop the argument, and pass &error_abort to the QObject output visitor
and @qmp_emit instead.
Suggested-by: NEric Blake <eblake@redhat.com>
Suggested-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NPeter Xu <peterx@redhat.com>
Message-Id: <20180815133747.25032-4-peterx@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
[Commit message rewritten, update to qapi-code-gen.txt corrected]
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>

Replace all the trace_vtd_err_*() hooks with the new error_report_once()
since they are similar to trace_vtd_err() - dumping the first error
would be mostly enough, then we have them on by default too.
Signed-off-by: NPeter Xu <peterx@redhat.com>
Message-Id: <20180815095328.32414-4-peterx@redhat.com>
[Use "%x" instead of "%" PRIx16 to print uint16_t, whitespace tidied up]
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>

Replace existing trace_vtd_err() with error_report_once() then stderr
will capture something if any of the error happens, meanwhile we don't
suffer from any DDOS.  Then remove the trace point.  Since at it,
provide more information where proper (now we can pass parameters into
the report function).
Signed-off-by: NPeter Xu <peterx@redhat.com>
Message-Id: <20180815095328.32414-3-peterx@redhat.com>
Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org>
[Two format strings fixed, whitespace tidied up]
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>

Fix passing argument for nanoMIPS bare metal related to the
semihosting regime.
Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: NAleksandar Markovic <amarkovic@wavecomp.com>
Signed-off-by: NYongbok Kim <yongbok.kim@mips.com>
Signed-off-by: NAleksandar Markovic <amarkovic@wavecomp.com>
Signed-off-by: NStefan Markovic <smarkovic@wavecomp.com>

Setup the GT64120 BARs in the nanoMIPS bootloader, in the same way that
they are setup in the MIPS32 bootloader. This is necessary for Linux to
be able to access peripherals, including the UART.
Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: NAleksandar Markovic <amarkovic@wavecomp.com>
Signed-off-by: NPaul Burton <pburton@wavecomp.com>
Signed-off-by: NYongbok Kim <yongbok.kim@mips.com>
Signed-off-by: NAleksandar Markovic <amarkovic@wavecomp.com>
Signed-off-by: NStefan Markovic <smarkovic@wavecomp.com>

Add basic nanoMIPS boot code for Malta.
Reviewed-by: NAleksandar Markovic <amarkovic@wavecomp.com>
Signed-off-by: NYongbok Kim <yongbok.kim@mips.com>
Signed-off-by: NAleksandar Markovic <amarkovic@wavecomp.com>
Signed-off-by: NStefan Markovic <smarkovic@wavecomp.com>

Fix MPS2 SCC config register values for the mps2-an511
and mps2-an385 boards:
 * the SCC_AID bits [23:20] specify the FPGA build target board revision,
   and the SCC_CFG4 register specifies the actual board revision, so
   these should have matching values. Claim to be board revision C,
   consistently -- we had the revision in the wrong part of SCC_AID.
 * SCC_ID bits [15:4] should be the board number in hex, not decimal
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
Message-id: 20180823175225.22612-1-peter.maydell@linaro.org

Refactor bcm2835_fb_mbox_push() to work by calling
bcm2835_fb_validate_config() and bcm2835_fb_reconfigure(),
so that config set this way is also validated.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
Message-id: 20180814144436.679-9-peter.maydell@linaro.org

Validate the config settings that the guest tries to set.

The wiki page documentation is not really accurate here:
generally rather than failing requests to set bad parameters,
the hardware will just clip them to something sensible.

Validate the most important parameters: sizes and
the viewport offsets. This prevents the framebuffer
code from trying to read out-of-range memory.

In the property handling code, we validate the new parameters every
time we encounter a tag that sets them. This means we validate the
config multiple times if the request includes multiple config-setting
tags, but the code would require significant restructuring to do a
validation only once but still return the clipped settings for
get-parameter tags and the buffer allocation tag.

Validation of settings made via the older bcm2835_fb_mbox_push()
function will be done in the next commit.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
Message-id: 20180814144436.679-8-peter.maydell@linaro.org

The raspi framebuffir in bcm2835_fb supports the definition
of a virtual "viewport", which is smaller than the full
physical framebuffer size and at an adjustable offset within
it. Only the viewport area is sent to the screen. This allows
the guest to do things like double buffering, or scrolling
by adjusting the viewport origin. Currently QEMU doesn't
implement this at all.

Add support for this feature:
 * the property mailbox code needs to distinguish the
   virtual width/height from the physical width/height
 * the framebuffer code needs to do something with the
   virtual width/height/origin information

Note that the wiki documentation on the semantics of the
virtual and physical height and width has it the wrong way
around -- the virtual size is the size of the allocated
buffer, and the physical size is the size of the display,
so the virtual size is always the same as or larger than
the physical.

If the viewport size is set smaller than the physical
screen size, we ignore the viewport settings completely
and just display the physical screen area.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
Message-id: 20180814144436.679-7-peter.maydell@linaro.org

Abstract out the calculation of the pitch and size of the
framebuffer into functions that operate on the BCM2835FBConfig
struct -- these are about to get a little more complicated
when we add support for virtual and physical sizes differing.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
Message-id: 20180814144436.679-6-peter.maydell@linaro.org

The bcm2835_fb's initial resolution and other parameters are set
via QOM properties. We should reset to those initial values on
device reset, which means we need to save the QOM property
values somewhere that they are not overwritten by guest
changes to the framebuffer configuration.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
Message-id: 20180814144436.679-5-peter.maydell@linaro.org

The BCM2835FBState struct has a 'pitch' field which is a
cached copy of xres * (bpp >> 3), and a 'size' field which is
a cached copy of pitch * yres. However we don't actually do
anything with these fields; delete them. We retain the
now-unused slots in the VMState struct for migration
compatibility.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
Message-id: 20180814144436.679-4-peter.maydell@linaro.org

Refactor the fb property setting code so that rather than
using a set of pointers to local variables to track
whether a config value has been updated in the current
mbox and if so what its new value is, we just copy
all the current settings of the fb at the start, and
then update that copy as we go along, before asking
the fb to switch to it at the end.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
Message-id: 20180814144436.679-3-peter.maydell@linaro.org

The handling of framebuffer properties in the bcm2835_property code
is a bit clumsy, because for each of the many fb related properties
we try to track the value we're about to set and whether we're going
to be setting a value, and then we hand all the new values off
to the framebuffer via a function which takes them all as separate
arguments. It would be simpler if the property code could easily
copy all the framebuffer's current settings, update them with
the new specified values and then ask the framebuffer to switch
to the new set.

As the first part of this refactoring, pull all the fb config
settings fields in BCM2835FBState out into their own struct.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
Message-id: 20180814144436.679-2-peter.maydell@linaro.org

Some of the config register values we were setting for the MPS2 SCC
weren't correct:
 * the SCC_AID bits [23:20] specify the FPGA build target board revision,
   and the SCC_CFG4 register specifies the actual board revision, so
   these should have matching values. Claim to be board revision C,
   consistently -- we had the revision in the wrong part of SCC_AID.
 * SCC_ID bits [15:4] should be 0x505, not decimal 505
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Message-id: 20180820141116.9118-23-peter.maydell@linaro.org
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>

The SPI controllers in the MPS2 AN505 board are PL022s.
We have a model of the PL022, so create these devices.

We don't currently model the LCD controller that sits behind
one of the PL022s; the others are intended to control devices
that sit on the FPGA's general purpose SPI connector or
"shield" expansion connectors.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Message-id: 20180820141116.9118-22-peter.maydell@linaro.org
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>

In the PL022, register offset 0x20 is the ICR, a write-only
interrupt-clear register.  Register offset 0x24 is DMACR, the DMA
control register.  We were incorrectly implementing (a stub version
of) DMACR at 0x20, and not implementing anything at 0x24.  Fix this
bug.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Message-id: 20180820141116.9118-21-peter.maydell@linaro.org
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>

The PL022 interrupt registers have bits allocated as:
 0: ROR (receive overrun)
 1: RT (receive timeout)
 2: RX (receive FIFO half full or less)
 3: TX (transmit FIFO half full or less)

A cut and paste error meant we had the wrong value for
the PL022_INT_RT constant. This bug doesn't affect device
behaviour, because we don't implement the receive timeout
feature and so never set that interrupt bit.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Message-id: 20180820141116.9118-20-peter.maydell@linaro.org
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>

Move from the legacy SysBusDevice::init method to using
DeviceState::realize.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org>
Message-id: 20180820141116.9118-19-peter.maydell@linaro.org
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>

Use the DeviceState vmsd pointer rather than calling vmstate_register()
directly.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Message-id: 20180820141116.9118-18-peter.maydell@linaro.org
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>

Currently the PL022 calls pl022_reset() from its class init
function. Make it register a DeviceState reset method instead,
so that we reset the device on system reset.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org>
Message-id: 20180820141116.9118-17-peter.maydell@linaro.org
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>

Create a new include file for the pl022's device struct,
type macros, etc, so that it can be instantiated using
the "embedded struct" coding style.

While we're adding the new file to MAINTAINERS, add
also the .c file, which was missing an entry.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org>
Message-id: 20180820141116.9118-16-peter.maydell@linaro.org
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>

The AN505 FPGA image includes four PL081 DMA controllers, each
of which is gated by a Master Security Controller that allows
the guest to prevent a non-secure DMA controller from accessing
memory that is used by secure guest code. Create and wire
up these devices.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org>
Message-id: 20180820141116.9118-15-peter.maydell@linaro.org
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>

The IoTKit doesn't have any MSCs itself but it does need
some wiring to connect the external signals from MSCs
in the outer board model up to the registers and the
NVIC IRQ line.

We also need to expose a MemoryRegion corresponding to
the AHB bus, so that MSCs in the outer board model can
use that as their downstream port. (In the FPGA this is
the "AHB Slave Expansion" ports shown in the block
diagram in the AN505 documentation.)
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org>
Message-id: 20180820141116.9118-14-peter.maydell@linaro.org
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>

The IoTKit does not have any Master Security Contollers itself,
but it does provide registers in the secure privilege control
block which allow control of MSCs in the external system.
Add support for these registers.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org>
Message-id: 20180820141116.9118-13-peter.maydell@linaro.org
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>

Implement a model of the TrustZone Master Securtiy Controller,
as documented in the Arm CoreLink SIE-200 System IP for
Embedded TRM  (DDI0571G):
  https://developer.arm.com/products/architecture/m-profile/docs/ddi0571/g

The MSC is intended to sit in front of a device which can
be a bus master (eg a DMA controller) and programmably gate
its transactions. This allows a bus-mastering device to be
controlled by non-secure code but still restricted from
making accesses to addresses which are secure-only.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Message-id: 20180820141116.9118-12-peter.maydell@linaro.org
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>

Wire up the system control element's register banks
(sysctl and sysinfo).

This is the last of the previously completely unimplemented
components in the IoTKit.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
Message-id: 20180820141116.9118-11-peter.maydell@linaro.org

Implement the IoTKit system control element's system information
block; this is just a pair of read-only version/config registers,
plus the usual PID/CID ID registers.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
Message-id: 20180820141116.9118-10-peter.maydell@linaro.org

The Arm IoTKit includes a system control element which
provides a block of read-only ID registers and a block
of read-write control registers. Implement a minimal
version of this.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
Message-id: 20180820141116.9118-9-peter.maydell@linaro.org

The IoTKit has a CMSDK timer device that runs on the S32KCLK.
Create this and wire it up.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
Message-id: 20180820141116.9118-8-peter.maydell@linaro.org

The IoTKit includes three different instances of the
CMSDK APB watchdog; create and wire them up.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
Message-id: 20180820141116.9118-7-peter.maydell@linaro.org

The MPS2 FPGA images for the Cortex-M3 (mps2-an385 and mps2-511)
both include a CMSDK dual-timer module. Wire this up.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
Message-id: 20180820141116.9118-6-peter.maydell@linaro.org

Now we have a model of the CMSDK dual timer, we can wire it
up in the IoTKit.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
Message-id: 20180820141116.9118-5-peter.maydell@linaro.org

The Arm Cortex-M System Design Kit includes a "dual-input timer module"
which combines two programmable down-counters. Implement a model
of this device.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
Message-id: 20180820141116.9118-4-peter.maydell@linaro.org

In the MPS2 FPGAIO, PSCNTR is a free-running downcounter with
a reload value configured via the PRESCALE register, and
COUNTER counts up by 1 every time PSCNTR reaches zero.
Implement these counters.

We can just increment the counters migration subsection's
version ID because we only added it in the previous commit,
so no released QEMU versions will be using it.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NAlistair Francis <alistair.francis@wdc.com>
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
Message-id: 20180820141116.9118-3-peter.maydell@linaro.org

The MPS2 FPGAIO block includes some simple free-running counters.
Implement these.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
Message-id: 20180820141116.9118-2-peter.maydell@linaro.org

The kernel booting specification for an AArch32 kernel requires that
it is booted in Hyp mode if available; otherwise the kernel can't
enable KVM. We were incorrectly leaving the kernel in SVC mode.
If we're booting an AArch32 kernel in the Nonsecure state and Hyp
mode is available, start in it.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
Reviewed-by: NEdgar E. Iglesias <edgar.iglesias@xilinx.com>
Reviewed-by: NLuc Michel <luc.michel@greensocs.com>
Message-id: 20180820153020.21478-7-peter.maydell@linaro.org

Add a "virtualization" property to the vexpress-a15 board,
controlling presence of EL2. As with EL3, we default to
enabling it, but the user can disable it if they have an
older guest which can't cope with it being present.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NLuc Michel <luc.michel@greensocs.com>
Message-id: 20180821132811.17675-10-peter.maydell@linaro.org

Don't request that the arm_load_kernel() code should boot in secure
state if the CPU doesn't have a secure state. Currently this
doesn't make a difference because the boot.c code only examines
the secure_boot flag in code guarded by an ARM_FEATURE_EL3 check,
but upcoming changes for supporting booting into Hyp mode will
change that.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NLuc Michel <luc.michel@greensocs.com>
Message-id: 20180821132811.17675-9-peter.maydell@linaro.org