The Cortex-M CPU and its NVIC are two intimately intertwined parts of
the same hardware; it is not possible to use one without the other.
Unfortunately a lot of our board models don't do any sanity checking
on the CPU type the user asks for, so a command line like
qemu-system-arm -M versatilepb -cpu cortex-m3
will create an M3 without an NVIC, and coredump immediately.
In the other direction, trying a non-M-profile CPU in an M-profile
board won't blow up, but doesn't do anything useful either:
qemu-system-arm -M lm3s6965evb -cpu arm926
Add some checking in the NVIC and CPU realize functions that the
user isn't trying to use an NVIC without an M-profile CPU or
an M-profile CPU without an NVIC, so we can produce a helpful
error message rather than a core dump.
Fixes: https://bugs.launchpad.net/qemu/+bug/1766896
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-id: 20180601160355.15393-1-peter.maydell@linaro.org
ppc patch queue 2018-06-12
Here's another batch of ppc patches towards the 3.0 release. There's
a fair bit here, because I've been working through my mail backlog
after a holiday. There's not much of a central theme, amongst other
things we have:
* ppc440 / sam460ex improvements
* logging and error cleanups
* 40p (PReP) bugfixes
* Macintosh fixes and cleanups
* Add emulation of the new POWER9 store-forwarding barrier
instruction variant
* Hotplug cleanups
# gpg: Signature made Tue 12 Jun 2018 07:43:21 BST
# gpg: using RSA key 6C38CACA20D9B392
# gpg: Good signature from "David Gibson <david@gibson.dropbear.id.au>"
# gpg: aka "David Gibson (Red Hat) <dgibson@redhat.com>"
# gpg: aka "David Gibson (ozlabs.org) <dgibson@ozlabs.org>"
# gpg: aka "David Gibson (kernel.org) <dwg@kernel.org>"
# Primary key fingerprint: 75F4 6586 AE61 A66C C44E 87DC 6C38 CACA 20D9 B392
* remotes/dgibson/tags/ppc-for-3.0-20180612: (33 commits)
spapr_pci: Remove unhelpful pagesize warning
xics_kvm: use KVM helpers
ppc/pnv: fix LPC HC firmware address space
spapr: handle cpu core unplug via hotplug handler chain
spapr: handle pc-dimm unplug via hotplug handler chain
spapr: introduce machine unplug handler
spapr: move memory hotplug support check into spapr_memory_pre_plug()
spapr: move lookup of the node into spapr_memory_plug()
spapr: no need to verify the node
target/ppc: Allow PIR read in privileged mode
ppc4xx_i2c: Clean up and improve error logging
target/ppc: extend eieio for POWER9
mos6522: convert VMSTATE_TIMER_PTR_TEST to VMSTATE_TIMER_PTR
mos6522: move timer frequency initialisation to mos6522_reset
cuda: embed mos6522_cuda device directly rather than using QOM object link
mos6522: fix vmstate_mos6522_timer version in vmstate_mos6522
ppc: add missing FW_CFG_PPC_NVRAM_FLAT definition
ppc: remove obsolete macio_init() definition from mac.h
ppc: remove obsolete pci_pmac_init() definitions from mac.h
hw/misc/mos6522: Add trailing '\n' to qemu_log() calls
...
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
A link property can be set during creation, with
object_property_add_link() and later with object_property_set_link().
add_link() doesn't add a reference to the target object, while
set_link() does.
Furthemore, OBJ_PROP_LINK_UNREF_ON_RELEASE flags, set during add_link,
says whether a reference must be released when the property is destroyed.
This can lead to leaks if the property was later set_link(), as the
added reference is never released.
Instead, rename OBJ_PROP_LINK_UNREF_ON_RELEASE to OBJ_PROP_LINK_STRONG
and use that has an indication on how the link handle reference
management in set_link().
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-id: 20180531195119.22021-3-marcandre.lureau@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
According to PowerISA, the PIR register should be readable in privileged
mode also, not only in hypervisor privileged mode.
PowerISA 3.0 - 4.3.3 Processor Identification Register
"Read access to the PIR is privileged; write access is not provided."
Figure 18 in section 4.4.4 explicitly confirms that mfspr PIR is privileged
and doesn't require hypervisor state.
Cc: David Gibson <david@gibson.dropbear.id.au>
Cc: Alexander Graf <agraf@suse.de>
Cc: qemu-ppc@nongnu.org
Signed-off-by: Leandro Lupori <leandro.lupori@gmail.com>
Reviewed-by: Jose Ricardo Ziviani <joserz@linux.ibm.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Greg Kurz <groug@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
POWER9 introduced a new variant of the eieio instruction using bit 6
as a hint to tell the CPU it is a store-forwarding barrier.
The usage of this eieio extension was recently added in Linux 4.17
which activated the "support for a store forwarding barrier at kernel
entry/exit".
Unfortunately, it is not possible to insert this new eieio instruction
without considerable change in ppc_tr_translate_insn(). So instead we
loosen the QEMU eieio instruction mask and modify the gen_eieio()
helper to test for bit6. On non-POWER9 CPUs, the bit6 is just ignored
but a warning is emitted as this is not an instruction software should
be using.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The powerpc Linux kernel[1] and skiboot firmware[2] recently gained changes
that cause the Processor Compatibility Register (PCR) SPR to be cleared.
These changes cause Linux to fail to boot on the Qemu powernv machine
with an error:
Trying to write privileged spr 338 (0x152) at 0000000030017f0c
With this patch Qemu makes this register available as a hypervisor
privileged register.
Note that bits set in this register disable features of the processor.
Currently the only register state that is supported is when the register
is zeroed (enable all features). This is sufficient for guests to
once again boot.
[1] https://lkml.kernel.org/r/20180518013742.24095-1-mikey@neuling.org
[2] https://patchwork.ozlabs.org/patch/915932/
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Factor out the parsing of struct kvm_ppc_cpu_char in
kvmppc_get_cpu_characteristics() into a separate function for each cap
for simplicity.
Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
fprintf() and qemu_log_separate() are frowned upon these days for printing
logging information in QEMU. Accessing the wrong SPRs indicates wrong guest
behaviour in most cases, and we've got a proper way to log such situations,
which is the qemu_log_mask(LOG_GUEST_ERROR, ...) function. So use this
function now for logging the bad SPR accesses instead.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Greg Kurz <groug@kaod.org>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The name gen_lookup_tb is at odds with tcg_gen_lookup_and_goto_tb.
For these cases, we do indeed want to exit back to the main loop.
Similarly, DISAS_UPDATE performs no actual update, whereas DISAS_EXIT
does what it says.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20180512050250.12774-6-richard.henderson@linaro.org>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Add information for cpuid 0x8000001D leaf. Populate cache topology information
for different cache types (Data Cache, Instruction Cache, L2 and L3) supported
by 0x8000001D leaf. Please refer to the Processor Programming Reference (PPR)
for AMD Family 17h Model for more details.
Signed-off-by: Babu Moger <babu.moger@amd.com>
Message-Id: <1527176614-26271-3-git-send-email-babu.moger@amd.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Always initialize CPUCaches structs with cache information, even
if legacy_cache=true. Use different CPUCaches struct for
CPUID[2], CPUID[4], and the AMD CPUID leaves.
This will simplify a lot the logic inside cpu_x86_cpuid().
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Babu Moger <babu.moger@amd.com>
Message-Id: <1527176614-26271-2-git-send-email-babu.moger@amd.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
move more data to arch specific files
fix SPARC %tick
replace strcpy() by g_strlcpy() in syscall.c
# gpg: Signature made Mon 04 Jun 2018 16:19:44 BST
# gpg: using RSA key F30C38BD3F2FBE3C
# gpg: Good signature from "Laurent Vivier <lvivier@redhat.com>"
# gpg: aka "Laurent Vivier <laurent@vivier.eu>"
# gpg: aka "Laurent Vivier (Red Hat) <lvivier@redhat.com>"
# Primary key fingerprint: CD2F 75DD C8E3 A4DC 2E4F 5173 F30C 38BD 3F2F BE3C
* remotes/vivier2/tags/linux-user-for-3.0-pull-request:
linux-user: remove useless #if
linux-user: move hppa signal definitions to hppa/target_signal.h
linux-user: move alpha signal definitions to alpha/target_signal.h
linux-user: move openrisc signal definitions to openrisc/target_signal.h
linux-user: move mips signal definitions to mips/target_signal.h
linux-user: move sparc signal definitions to sparc/target_signal.h
linux-user: move generic signal definitions to generic/signal.h
linux-user: move get_sp_from_cpustate() to target_cpu.h
linux-user: move sparc/sparc64 fcntl definitions to sparc/target_fcntl.h
linux-user: move ppc fcntl definitions to ppc/target_fcntl.h
linux-user: move mips/mips64 fcntl definitions to mips/target_fcntl.h
linux-user: move arm/aarch64/m68k fcntl definitions to [arm|aarch64|m68k]/target_fcntl.h
linux-user: move hppa fcntl definitions to hppa/target_fcntl.h
linux-user: move alpha fcntl definitions to alpha/target_fcntl.h
linux-user: move generic fcntl definitions to generic/fcntl.h
linux-user: SPARC "rd %tick" can be used by user application
syscall: replace strcpy() by g_strlcpy()
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
we have the same problem decribed in 7d6b1daedd
("linux-user, ppc: mftbl can be used by user application")
for ppc in the case of sparc.
When we use an application trying to resolve a name, it hangs in
0x00000000ff5dd40c: rd %tick, %o5
0x00000000ff5dd410: srlx %o5, 0x20, %o4
0x00000000ff5dd414: btst %o5, %g4
0x00000000ff5dd418: be %icc, 0xff5dd40c
because %tick is staying at 0.
As QEMU_CLOCK_VIRTUAL is not available in linux-user mode,
simply use cpu_get_host_ticks() instead.
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20180528194812.31216-1-laurent@vivier.eu>
Do the cast to uintptr_t within the helper, so that the compiler
can type check the pointer argument. We can also do some more
sanity checking of the index argument.
Reviewed-by: Laurent Vivier <laurent@vivier.eu>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
In kernel header commit 633711e8287, the define KVM_HINTS_DEDICATED
was renamed to KVM_HINTS_REALTIME. Work around this compatibility
break by (a) using the new constant name, and (b) defining it
if the headers don't.
Part (b) can be removed once we've updated our copy of the kernel
headers to a version that defines KVM_HINTS_REALTIME.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20180525132755.21839-5-peter.maydell@linaro.org>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>