Now that we have a monitor/ subdirectory, let's move hmp.c and qmp.c
from the root directory there. As they contain implementations of
monitor commands, rename them to {hmp,qmp}-cmds.c, so that {hmp,qmp}.c
are free for the HMP and QMP infrastructure.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20190613153405.24769-9-kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Create a new monitor/ subdirectory and move monitor.c there. As the plan
is to move the monitor core into separate files, use the chance to
rename it to misc.c.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20190613153405.24769-8-kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
This renames the type for HMP monitor commands and the tables holding
the commands to make clear that they are related to HMP and to allow
making them public later:
* mon_cmd_t -> HMPCommand (fixing use of a reserved name, too)
* mon_cmds -> hmp_cmds
* info_cmds -> hmp_info_cmds
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-Id: <20190613153405.24769-7-kwolf@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
[sortcmdlist() cleaned up to make checkpatch.pl happy]
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Monitor.cmd_table is initialised to point to mon_cmds and never changed
afterwards. We can remove the indirection and just reference mon_cmds
directly instead.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-Id: <20190613153405.24769-6-kwolf@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
The ReadLineState in Monitor is only used for HMP monitors. Create
MonitorHMP and move it there.
Can't use container_of() in hmp_change(). Cast instead, and mark
FIXME. Will be cleaned up shortly.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Message-Id: <20190613153405.24769-5-kwolf@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
[Superfluous variable in monitor_data_destroy() eliminated, whitespace
tweaked in hmp_change(), commit message improved]
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Currently, struct Monitor mixes state that is only relevant for HMP,
state that is only relevant for QMP, and some actually shared state.
In particular, a MonitorQMP field is present in the state of any
monitor, even if it's not a QMP monitor and therefore doesn't use the
state.
As a first step towards a clean separation between QMP and HMP, let
MonitorQMP extend Monitor and create a MonitorQMP object only when the
monitor is actually a QMP monitor.
Some places accessed Monitor.qmp unconditionally, even for HMP monitors.
They can't keep doing this now, so during the conversion, they are
either changed to become conditional on monitor_is_qmp() or to assert()
that they always get a QMP monitor.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Message-Id: <20190613153405.24769-4-kwolf@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
[Superfluous variable in monitor_data_destroy() eliminated]
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Instead of mixing HMP and QMP monitors in the same function, separate
the monitor creation function for both.
While in theory, one could pass both MONITOR_USE_CONTROL and
MONITOR_USE_READLINE before this patch and both flags would do
something, readline support is tightly coupled with HMP: QMP never feeds
its input to readline, and the tab completion function treats the input
as an HMP command. Therefore, this configuration is useless.
After this patch, the QMP path asserts that MONITOR_USE_READLINE is not
set. The HMP path can be used with or without MONITOR_USE_READLINE, like
before.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20190613153405.24769-3-kwolf@redhat.com>
[Zero initialization of Monitor moved from monitor_data_init() to
callers]
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Commit 788cf9f8c removed the code for password prompting from the
monitor. Since then, the Monitor fields password_completion_cb and
password_opaque have been unused. Remove them.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20190613153405.24769-2-kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
monitor_fdset_dup_fd_find_remove() and monitor_fdset_dup_fd_find()
return mon_fdset->id which is int64_t. Downcasting from int64_t to int
leads to a bug with removing fd from fdset with id >= 2^32.
So, fix return types for these function.
Signed-off-by: Yury Kotov <yury-kotov@yandex-team.ru>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20190523094433.30297-1-yury-kotov@yandex-team.ru>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
* fix some minor syntax issues in docs/specs/index.rst
* build and install the 'specs' manual, since it now has some content
* delete the "QEMU compared to other emulators" section of the docs
* Convert "translator internals" docs to RST, move to devel manual
-----BEGIN PGP SIGNATURE-----
iQJNBAABCAA3FiEE4aXFk81BneKOgxXPPCUl7RQ2DN4FAl0HqgcZHHBldGVyLm1h
eWRlbGxAbGluYXJvLm9yZwAKCRA8JSXtFDYM3sMBEACr1RgVssLylaLcaKSCe5kV
roDPnWvVj4KUOHfYrbP6P16v3SzZA/Cyli0CkvwBz663SxS638PEFD1+lv7CCvYK
x1h27aKr+aP2COZsOupwRmmWyMp0ei2z4oqUgQvNjjV5Ig/IRETinSNla4faG1Xk
/By6BM0nl8MFDQAyzQk8xmRLQRGRHKYF4kilAaFfz1baxojqyb67ttRHqDxOUHVN
7kOEf1nNB6CnPTpVfXKx46h0ephzQD7puYnIht1s1SEyXasCvD2l6QOrxE8nPrB7
CACqOP23vDnXqAH0yfz2Mk7SOvkHrYqFt+VHbuTQWQppPAOnPRvxty5GlvMbiW39
Anb/KmymeZZHwxnz6sP+ccSgb3e4E0uXO/rCqVdv/eX28spX0uQ4dfzrZLfaDgn7
4gECJXM1nJb6WCuHoCPdBKKoh0XYlWETTIQ/cbE2w8uQTYHrF0MQkLSwb6+cEaI4
xxbn2QedDBMaxyBWaYrJRKoB4bRATRajrWTiSqSGuzWsFnbDh+XtGK40QDE3eR9y
08APNeO4uCvXOZjxeAhCS8/kPkBbNGuAy35ueRORdzfAxDcFRJ3vP6d2zWG4xg+k
TkOrJl4NQpCpo7JgWd6SiTmryT38bE2wChC8RgJymIGJTpJy6BFvANtlL6guUklP
TRu9PKGgE40Uz14TAUWUig==
=VjFp
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/pmaydell/tags/pull-docs-20190617' into staging
docs infrastructure queue:
* fix some minor syntax issues in docs/specs/index.rst
* build and install the 'specs' manual, since it now has some content
* delete the "QEMU compared to other emulators" section of the docs
* Convert "translator internals" docs to RST, move to devel manual
# gpg: Signature made Mon 17 Jun 2019 15:56:07 BST
# 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-docs-20190617:
docs: Build and install specs manual
docs/specs/index.rst: Fix minor syntax issues
qemu-tech.texi: Remove "QEMU compared to other emulators" section
Convert "translator internals" docs to RST, move to devel manual
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Now we have some rST format docs in the docs/specs/ manual, we should
actually build and install it.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Acked-by: Aleksandar Markovic <amarkovic@wavecomp.com>
Message-id: 20190610152444.20859-3-peter.maydell@linaro.org
The docs/specs/index.rst has a couple of minor issues which
we didn't notice because we weren't building the manual:
* the ToC entry for the new PPC XIVE docs points to
a nonexistent file
* the initial comment needs to be marked by '..', not '.',
or it will appear in the output
* the title doesn't match the capitialization used by
the existing interop or devel manuals, and uses
'full-system emulation' rather than the 'system emulation'
that the interop manual title uses
Fix these minor issues before we start trying to build the manual.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Acked-by: Aleksandar Markovic <amarkovic@wavecomp.com>
Message-id: 20190610152444.20859-2-peter.maydell@linaro.org
The "QEMU compared to other emulators" section of our documentation
hasn't been updated since 2015 (and parts of the text are even older).
We're clearly not very well placed to track the evolution of a
dozen other emulation projects, and an inaccurate or out of date
comparison doesn't serve anybody, so we're best off just removing
the whole documentation section.
If anybody cares strongly about maintaining a comparison page,
it's probably better to do that on the project's wiki where
we can update it more dynamically.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Acked-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20190607152827.18003-3-peter.maydell@linaro.org
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Our user-facing manual currently has a section "translator internals"
which has some high-level information about the design of the
TCG translator. This should really be in our new devel/ manual.
Convert it to RST format and move it there.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Acked-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20190607152827.18003-2-peter.maydell@linaro.org
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
* support large kernel images in bootloader (by avoiding
putting the initrd over the top of them)
* correctly disable FPU/DSP in the CPU for the mps2-an521, musca-a boards
* arm_gicv3: Fix decoding of ID register range
* arm_gicv3: GICD_TYPER.SecurityExtn is RAZ if GICD_CTLR.DS == 1
* some code cleanups following on from the VFP decodetree conversion
* Only implement doubles if the FPU supports them
(so we now correctly model Cortex-M4, -M33 as single precision only)
-----BEGIN PGP SIGNATURE-----
iQJNBAABCAA3FiEE4aXFk81BneKOgxXPPCUl7RQ2DN4FAl0HpJ0ZHHBldGVyLm1h
eWRlbGxAbGluYXJvLm9yZwAKCRA8JSXtFDYM3sjOD/4tXT0achhuXaDOYhMyIHzJ
XK2DSIi0KC2d/c0NRtJX5JCUoWXW1rJGS2JYvknHRyrr77Hyf2HM7ESZLcFldzyp
tjA0NJ7VwM2ykkeC13DSgM2AL72ayA+i0y3GjbUL6HefZOC0MMpg+u2sg10pNmcY
FajUn4ejLGgsl1OmkG1QDu+hrmY9LEPaOrnTHWy/PGLsBjqJ4fAfOmLmjpCNvZzR
WDbcK0AIAtqH/98PthSdsjyecDkVo3JEJld0fnfjoCLfhDKFg6YWi9WBD7QMF2VA
5LOxbrw6kjt1NzAJ1b6S6jImTU3yfGh6luqCRcqAeUPyU7WN/5rWUGInFJAhHtyA
tDeHQy2w73o6Onr6Tps+co17YxXr066I9ADmTc0zxDfE2Fc3dC4+b54rNQ6S0URi
7EsXEwAKLRKHpzr8HW8kk7P87DEjxq0WpCiTaV2/p6fMbXhFLwAWexr5z4wzWFAx
OMFTo04Aqw9K+ouQ2xhpuA4gPXxExa2EbSj6T1Zmby/iFJf3uXPXgY/Uj4k48P2k
J8RMwr9f7BGTuh6F8GhGxXAWMAfTJcVHJ9E+CEPKHN5WAHQimv7X5aQLTK7SI0xE
4ij2JGsE9Drq/g4fLsXB45yYrGLOCPZZ+NpGSIYdkN9/sH+vxAp1OedGERftb7PX
CvACBM9VmEYRo/+S1BZu+w==
=mGBo
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20190617' into staging
target-arm queue:
* support large kernel images in bootloader (by avoiding
putting the initrd over the top of them)
* correctly disable FPU/DSP in the CPU for the mps2-an521, musca-a boards
* arm_gicv3: Fix decoding of ID register range
* arm_gicv3: GICD_TYPER.SecurityExtn is RAZ if GICD_CTLR.DS == 1
* some code cleanups following on from the VFP decodetree conversion
* Only implement doubles if the FPU supports them
(so we now correctly model Cortex-M4, -M33 as single precision only)
# gpg: Signature made Mon 17 Jun 2019 15:33:01 BST
# 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-20190617: (24 commits)
target/arm: Only implement doubles if the FPU supports them
target/arm: Fix typos in trans function prototypes
target/arm: Remove unused cpu_F0s, cpu_F0d, cpu_F1s, cpu_F1d
target/arm: Stop using deprecated functions in NEON_2RM_VCVT_F32_F16
target/arm: stop using deprecated functions in NEON_2RM_VCVT_F16_F32
target/arm: Stop using cpu_F0s in Neon VCVT fixed-point ops
target/arm: Stop using cpu_F0s for Neon f32/s32 VCVT
target/arm: Stop using cpu_F0s for NEON_2RM_VRECPE_F and NEON_2RM_VRSQRTE_F
target/arm: Stop using cpu_F0s for NEON_2RM_VCVT[ANPM][US]
target/arm: Stop using cpu_F0s for NEON_2RM_VRINT*
target/arm: Stop using cpu_F0s for NEON_2RM_VNEG_F
target/arm: Stop using cpu_F0s for NEON_2RM_VABS_F
target/arm: Use vfp_expand_imm() for AArch32 VFP VMOV_imm
target/arm: Move vfp_expand_imm() to translate.[ch]
hw/intc/arm_gicv3: GICD_TYPER.SecurityExtn is RAZ if GICD_CTLR.DS == 1
hw/intc/arm_gicv3: Fix decoding of ID register range
hw/arm: Correctly disable FPU/DSP for some ARMSSE-based boards
hw/arm/armv7m: Forward "vfp" and "dsp" properties to CPU
target/arm: Allow M-profile CPUs to disable the DSP extension via CPU property
target/arm: Allow VFP and Neon to be disabled via a CPU property
...
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The architecture permits FPUs which have only single-precision
support, not double-precision; Cortex-M4 and Cortex-M33 are
both like that. Add the necessary checks on the MVFR0 FPDP
field so that we UNDEF any double-precision instructions on
CPUs like this.
Note that even if FPDP==0 the insns like VMOV-to/from-gpreg,
VLDM/VSTM, VLDR/VSTR which take double precision registers
still exist.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20190614104457.24703-3-peter.maydell@linaro.org
In several places cut and paste errors meant we were using the wrong
type for the 'arg' struct in trans_ functions called by the
decodetree decoder, because we were using the _sp version of the
struct in the _dp function. These were harmless, because the two
structs were identical and so decodetree made them typedefs of the
same underlying structure (and we'd have had a compile error if they
were not harmless), but we should clean them up anyway.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20190614104457.24703-2-peter.maydell@linaro.org
Remove the now unused TCG globals cpu_F0s, cpu_F0d, cpu_F1s, cpu_F1d.
cpu_M0 is still used by the iwmmxt code, and cpu_V0 and
cpu_V1 are used by both iwmmxt and Neon.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20190613163917.28589-13-peter.maydell@linaro.org
Remove some old constructns from NEON_2RM_VCVT_F16_F32 code:
* don't use CPU_F0s
* don't use tcg_gen_st_f32
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20190613163917.28589-12-peter.maydell@linaro.org
Remove some old constructs from NEON_2RM_VCVT_F16_F32 code:
* don't use cpu_F0s
* don't use tcg_gen_ld_f32
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20190613163917.28589-11-peter.maydell@linaro.org
Stop using cpu_F0s in the Neon VCVT fixed-point operations.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20190613163917.28589-10-peter.maydell@linaro.org
Stop using cpu_F0s for the Neon f32/s32 VCVT operations.
Since this is the last user of cpu_F0s in the Neon 2rm-op
loop, we can remove the handling code for it too.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20190613163917.28589-9-peter.maydell@linaro.org
Stop using cpu_F0s for NEON_2RM_VRECPE_F and NEON_2RM_VRSQRTE_F.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20190613163917.28589-8-peter.maydell@linaro.org
Stop using cpu_F0s for the NEON_2RM_VCVT[ANPM][US] ops.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20190613163917.28589-7-peter.maydell@linaro.org
Switch NEON_2RM_VRINT* away from using cpu_F0s.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20190613163917.28589-6-peter.maydell@linaro.org
Switch NEON_2RM_VABS_F away from using cpu_F0s.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20190613163917.28589-5-peter.maydell@linaro.org
Where Neon instructions are floating point operations, we
mostly use the old VFP utility functions like gen_vfp_abs()
which work on the TCG globals cpu_F0s and cpu_F1s. The
Neon for-each-element loop conditionally loads the inputs
into either a plain old TCG temporary for most operations
or into cpu_F0s for float operations, and similarly stores
back either cpu_F0s or the temporary.
Switch NEON_2RM_VABS_F away from using cpu_F0s, and
update neon_2rm_is_float_op() accordingly.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20190613163917.28589-4-peter.maydell@linaro.org
The AArch32 VMOV (immediate) instruction uses the same VFP encoded
immediate format we already handle in vfp_expand_imm(). Use that
function rather than hand-decoding it.
Suggested-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20190613163917.28589-3-peter.maydell@linaro.org
We want to use vfp_expand_imm() in the AArch32 VFP decode;
move it from the a64-only header/source file to the
AArch32 one (which is always compiled even for AArch64).
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20190613163917.28589-2-peter.maydell@linaro.org
The GICv3 specification says that the GICD_TYPER.SecurityExtn bit
is RAZ if GICD_CTLR.DS is 1. We were incorrectly making it RAZ
if the security extension is unsupported. "Security extension
unsupported" always implies GICD_CTLR.DS == 1, but the guest can
also set DS on a GIC which does support the security extension.
Fix the condition to correctly check the GICD_CTLR.DS bit.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20190524124248.28394-3-peter.maydell@linaro.org
The GIC ID registers cover an area 0x30 bytes in size
(12 registers, 4 bytes each). We were incorrectly decoding
only the first 0x20 bytes.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20190524124248.28394-2-peter.maydell@linaro.org
The SSE-200 hardware has configurable integration settings which
determine whether its two CPUs have the FPU and DSP:
* CPU0_FPU (default 0)
* CPU0_DSP (default 0)
* CPU1_FPU (default 1)
* CPU1_DSP (default 1)
Similarly, the IoTKit has settings for its single CPU:
* CPU0_FPU (default 1)
* CPU0_DSP (default 1)
Of our four boards that use either the IoTKit or the SSE-200:
* mps2-an505, mps2-an521 and musca-a use the default settings
* musca-b1 enables FPU and DSP on both CPUs
Currently QEMU models all these boards using CPUs with
both FPU and DSP enabled. This means that we are incorrect
for mps2-an521 and musca-a, which should not have FPU or DSP
on CPU0.
Create QOM properties on the ARMSSE devices corresponding to the
default h/w integration settings, and make the Musca-B1 board
enable FPU and DSP on both CPUs. This fixes the mps2-an521
and musca-a behaviour, and leaves the musca-b1 and mps2-an505
behaviour unchanged.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Message-id: 20190517174046.11146-5-peter.maydell@linaro.org
Create "vfp" and "dsp" properties on the armv7m container object
which will be forwarded to its CPU object, so that SoCs can
configure whether the CPU has these features.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Message-id: 20190517174046.11146-4-peter.maydell@linaro.org
Allow the DSP extension to be disabled via a CPU property for
M-profile CPUs. (A and R-profile CPUs don't have this extension
as a defined separate optional architecture extension, so
they don't need the property.)
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Message-id: 20190517174046.11146-3-peter.maydell@linaro.org
Allow VFP and neon to be disabled via a CPU property. As with
the "pmu" property, we only allow these features to be removed
from CPUs which have it by default, not added to CPUs which
don't have it.
The primary motivation here is to be able to optionally
create Cortex-M33 CPUs with no FPU, but we provide switches
for both VFP and Neon because the two interact:
* AArch64 can't have one without the other
* Some ID register fields only change if both are disabled
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Message-id: 20190517174046.11146-2-peter.maydell@linaro.org
Since Linux v3.17, the kernel's Image header includes a field image_size,
which gives the total size of the kernel including unpopulated data
sections such as the BSS). If this is present, then return it from
load_aarch64_image() as the true size of the kernel rather than
just using the size of the Image file itself. This allows the code
which calculates where to put the initrd to avoid putting it in
the kernel's BSS area.
This means that we should be able to reliably load kernel images
which are larger than 128MB without accidentally putting the
initrd or dtb in locations that clash with the kernel itself.
Fixes: https://bugs.launchpad.net/qemu/+bug/1823998
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Tested-by: Mark Rutland <mark.rutland@arm.com>
Message-id: 20190516144733.32399-5-peter.maydell@linaro.org
We currently put the initrd at the smaller of:
* 128MB into RAM
* halfway into the RAM
(with the dtb following it).
However for large kernels this might mean that the kernel
overlaps the initrd. For some kinds of kernel (self-decompressing
32-bit kernels, and ELF images with a BSS section at the end)
we don't know the exact size, but even there we have a
minimum size. Put the initrd at least further into RAM than
that. For image formats that can give us an exact kernel size, this
will mean that we definitely avoid overlaying kernel and initrd.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Tested-by: Mark Rutland <mark.rutland@arm.com>
Message-id: 20190516144733.32399-4-peter.maydell@linaro.org
We calculate the locations in memory where we want to put the
initrd and the DTB based on the size of the kernel, since they
come after it. Add some explicit checks that these aren't off the
end of RAM entirely.
(At the moment the way we calculate the initrd_start means that
it can't ever be off the end of RAM, but that will change with
the next commit.)
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Tested-by: Mark Rutland <mark.rutland@arm.com>
Message-id: 20190516144733.32399-3-peter.maydell@linaro.org
In the Arm kernel/initrd loading code, in some places we make the
incorrect assumption that info->ram_size can be treated as the
address of the end of RAM, as for instance when we calculate the
available space for the initrd using "info->ram_size - info->initrd_start".
This is wrong, because many Arm boards (including "virt") specify
a non-zero info->loader_start to indicate that their RAM area
starts at a non-zero physical address.
Correct the places which make this incorrect assumption.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Tested-by: Mark Rutland <mark.rutland@arm.com>
Message-id: 20190516144733.32399-2-peter.maydell@linaro.org
A bunch of minor fixes all over the place.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
-----BEGIN PGP SIGNATURE-----
iQEcBAABAgAGBQJdBqqnAAoJECgfDbjSjVRp7isIAK7kmHhPtGNhv+7Nz35Dk5fo
de2OQO8Luqv58yAbqIIo8JVH/AAN+EZAx1gyI4lW1lzV8DFxCaim9JBriXVchc8l
1I1oaRh62nVhJnzP+9U1AiAYW/3L/4N1dkGVqSPfAN4P+TxBH4MbavlwUPDJhao/
iNHF9sxG4fxcBzN/IGbNuSnHAf1Kadd0Lf7hX7ltAHItsrLM7DUy/nT0WikoDVhO
vT7eDv/9B1Cgzt2mx5pyud+zLsjW/2RIxMDZFc40R5DhqPtnoHxm1zRkXIwvfGNO
oBoZ05P36kUt0jcRYEcsrz9vDfmBBWp7CtOT4oZW58K4VMGZRoUlU6bnjBf1B2Q=
=nes2
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into staging
virtio, acpi: fixes, cleanups
A bunch of minor fixes all over the place.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
# gpg: Signature made Sun 16 Jun 2019 21:46:31 BST
# gpg: using RSA key 281F0DB8D28D5469
# gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>" [full]
# gpg: aka "Michael S. Tsirkin <mst@redhat.com>" [full]
# Primary key fingerprint: 0270 606B 6F3C DF3D 0B17 0970 C350 3912 AFBE 8E67
# Subkey fingerprint: 5D09 FD08 71C8 F85B 94CA 8A0D 281F 0DB8 D28D 5469
* remotes/mst/tags/for_upstream:
tests/rebuild-expected-aml.sh: blow out difflist
q35: update DSDT
q35: fix mmconfig and PCI0._CRS
hw/acpi: extract acpi_add_rom_blob()
vhost: fix vhost_log size overflow during migration
docs/vhost-user.json: some firmware.json copy leftovers
vhost-user-gpu: initialize msghdr & iov at declaration
vhost-user-input: check ioctl(EVIOCGNAME) return value
vhost-user: improve error report
vhost-user: check unix_listen() return value
vhost-user-gpu: do not send scanout update if no GPU socket
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
https://github.com/tianocore/edk2/releases/tag/edk2-stable201905
Advance QEMU's edk2 submodule to edk2-stable201905, and rebuild the
firmware binaries. This should be the edk2 release that goes into QEMU
4.1.
Launchpad: https://bugs.launchpad.net/qemu/+bug/1831477
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABCAAGBQJdA/75AAoJENOdpx4NSWz6YtEP/iEW2F2CXtGmOmBoL67vvbXT
kFbVyto2Z4agMS4C7TSQyoDQ3eWbDQoaupnKfAhmpLzi9bNOvT53YaO+5vKty7P6
9uD+G0obdUTTrn510EE6Np5ph5eHakaEnhwSJv0sNQhYA1xgD1ZHmkxQS1swbSA0
NSWxWpI6puzJyvVO4YNzulVTt7RFoo2jXw2gvyOaJ0KPACigKO0LQpNfmX0CPAGQ
4RSVajuMSZAhLGnKk5ctt0+ucbi/KYmdy7SP3aifoHm9KvIdqkovH67YGdkVrfCL
/pwlpmFgkzxXSovOAEJPjmdYvJzWG9GN2Y6ichOLy/2d8ZHh5cFR4mhYa/x16nAV
eb3EmM1CqqTlmqCJ6Q2NIar8ADD4YsUGX7/s/ETdP5SaWM4dR1oKZe8c3gKDt47T
vbP/yCIETsYWztS7tSTMnUWEDoZfucUd1PyiKyt9TMmbI8wHRFtVGjLT7HvMUqqk
+rs9zRbwbOlHWusvjInMX2XDDlfqVfGsZq5EWgXUd0m/yK3/lE36wE3X3KXwva/h
uYOhUQDvegdvIjg043FX9GNCIm7JRZ1tWhMIujXW0WSqWSiPOqcv6BeC3MbU3WZQ
TMAjNMRWyBWGbMEfGyBMGkVsv5UkY+pEMwyxuJAcN9oXpeMjYZaSou1CregRt+Sn
ApLrzSrCkMMCokFuIrPX
=2MB6
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/lersek/tags/edk2-pull-2019-06-14' into staging
edk2-stable201905 was released on 2019-06-06:
https://github.com/tianocore/edk2/releases/tag/edk2-stable201905
Advance QEMU's edk2 submodule to edk2-stable201905, and rebuild the
firmware binaries. This should be the edk2 release that goes into QEMU
4.1.
Launchpad: https://bugs.launchpad.net/qemu/+bug/1831477
# gpg: Signature made Fri 14 Jun 2019 21:09:29 BST
# gpg: using RSA key D39DA71E0D496CFA
# gpg: Good signature from "Laszlo Ersek <lersek@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: F5D9 660F 1BA5 F310 A95A C5E0 466A EAE0 6125 3988
# Subkey fingerprint: B3A5 5D3F 88A8 90ED 2E63 3E8D D39D A71E 0D49 6CFA
* remotes/lersek/tags/edk2-pull-2019-06-14:
pc-bios: update the README file with edk2-stable201905 information
pc-bios: refresh edk2 build artifacts for edk2-stable201905
roms/Makefile.edk2: update input file list for "pc-bios/edk2-licenses.txt"
roms/Makefile.edk2: remove edk2-stable201903 network feature test macros
roms/edk2: update submodule from edk2-stable201903 to edk2-stable201905
roms/Makefile.edk2: define edk2-stable201905 network feature test macros
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
As expected files have been updated, make sure we
do not forget to remove them from the allowed
diff list.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
update expected files and drop them from allowed diff list.
Fixes: 4a4418369d ("q35: fix mmconfig and PCI0._CRS")
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
This patch changes the handling of the mmconfig area. Thanks to the
pci(e) expander devices we already have the logic to exclude address
ranges from PCI0._CRS. We can simply add the mmconfig address range
to the list get it excluded as well.
With that in place we can go with a fixed pci hole which covers the
whole area from the end of (low) ram to the ioapic.
This will make the whole logic alot less fragile. No matter where the
firmware places the mmconfig xbar, things should work correctly. The
guest also gets a bit more PCI address space (seabios boot):
# cat /proc/iomem
[ ... ]
7ffdd000-7fffffff : reserved
80000000-afffffff : PCI Bus 0000:00 <<-- this is new
b0000000-bfffffff : PCI MMCONFIG 0000 [bus 00-ff]
b0000000-bfffffff : reserved
c0000000-febfffff : PCI Bus 0000:00
f8000000-fbffffff : 0000:00:01.0
[ ... ]
So this is a guest visible change.
Cc: László Érsek <lersek@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20190607073429.3436-1-kraxel@redhat.com>
arm and i386 has almost the same function acpi_add_rom_blob(), except
giving different FWCfgCallback function.
This patch moves acpi_add_rom_blob() to utils.c by passing
FWCfgCallback to it.
Signed-off-by: Wei Yang <richardw.yang@linux.intel.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
v7:
* rebase on top of current master because of conflict
v6:
* change author from Igor to Michael
v5:
* remove unnecessary header glib/gprintf.h
* rearrange include header to make it more suitable
v4:
* extract -> moves
* adjust comment in source to make checkpatch happy
v3:
* put acpi_add_rom_blob() to hw/acpi/utils.c
v2:
* remove unused header in original source file
Message-Id: <20190610011830.28398-1-richardw.yang@linux.intel.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
When a guest which doesn't support multiqueue is migrated with a multi queues
vhost-user-blk deivce, a crash will occur like:
0 qemu_memfd_alloc (name=<value optimized out>, size=562949953421312, seals=<value optimized out>, fd=0x7f87171fe8b4, errp=0x7f87171fe8a8) at util/memfd.c:153
1 0x00007f883559d7cf in vhost_log_alloc (size=70368744177664, share=true) at hw/virtio/vhost.c:186
2 0x00007f88355a0758 in vhost_log_get (listener=0x7f8838bd7940, enable=1) at qemu-2-12/hw/virtio/vhost.c:211
3 vhost_dev_log_resize (listener=0x7f8838bd7940, enable=1) at hw/virtio/vhost.c:263
4 vhost_migration_log (listener=0x7f8838bd7940, enable=1) at hw/virtio/vhost.c:787
5 0x00007f88355463d6 in memory_global_dirty_log_start () at memory.c:2503
6 0x00007f8835550577 in ram_init_bitmaps (f=0x7f88384ce600, opaque=0x7f8836024098) at migration/ram.c:2173
7 ram_init_all (f=0x7f88384ce600, opaque=0x7f8836024098) at migration/ram.c:2192
8 ram_save_setup (f=0x7f88384ce600, opaque=0x7f8836024098) at migration/ram.c:2219
9 0x00007f88357a419d in qemu_savevm_state_setup (f=0x7f88384ce600) at migration/savevm.c:1002
10 0x00007f883579fc3e in migration_thread (opaque=0x7f8837530400) at migration/migration.c:2382
11 0x00007f8832447893 in start_thread () from /lib64/libpthread.so.0
12 0x00007f8832178bfd in clone () from /lib64/libc.so.6
This is because vhost_get_log_size() returns a overflowed vhost-log size.
In this function, it uses the uninitialized variable vqs->used_phys and
vqs->used_size to get the vhost-log size.
Signed-off-by: Li Hangjing <lihangjing@baidu.com>
Reviewed-by: Xie Yongji <xieyongji@baidu.com>
Reviewed-by: Chai Wen <chaiwen@baidu.com>
Message-Id: <20190603061524.24076-1-lihangjing@baidu.com>
Cc: qemu-stable@nongnu.org
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20190605131221.29432-1-marcandre.lureau@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
This should fix uninitialized fields found by coverity CID 1401762.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20190605145829.7674-6-marcandre.lureau@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
This should fix coverity CID 1401704.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20190605145829.7674-5-marcandre.lureau@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
g_printerr() needs a trailing \n
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20190605145829.7674-4-marcandre.lureau@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
