KONRAD Frederic [Thu, 3 May 2018 15:17:16 +0000 (17:17 +0200)]
riscv: requires libfdt
When compiling on a machine without libfdt installed the configure script
should try to get libfdt from the git or should die because otherwise
CONFIG_LIBFDT is not set and the build process end in an error in the link
phase.. eg:
hw/riscv/virt.o: In function `riscv_virt_board_init':
qemu/src/hw/riscv/virt.c:317: undefined reference to `qemu_fdt_setprop_cell'
qemu/src/hw/riscv/virt.c:319: undefined reference to `qemu_fdt_setprop_cell'
qemu/src/hw/riscv/virt.c:345: undefined reference to `qemu_fdt_dumpdtb'
collect2: error: ld returned 1 exit status
make[1]: *** [qemu-system-riscv64] Error 1
make: *** [subdir-riscv64-softmmu] Error 2
Cc: qemu-stable@nongnu.org Reviewed-by: Bastian Koppelmann <kbastian@mail.uni-paderborn.de> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Michael Clark <mjc@sifive.com> Signed-off-by: KONRAD Frederic <frederic.konrad@adacore.com> Signed-off-by: Michael Clark <mjc@sifive.com>
Message-Id: <1525360636-18229-4-git-send-email-frederic.konrad@adacore.com>
Reviewed-by: Michael Clark <mjc@sifive.com> Signed-off-by: KONRAD Frederic <frederic.konrad@adacore.com> Signed-off-by: Michael Clark <mjc@sifive.com>
Message-Id: <1525360636-18229-3-git-send-email-frederic.konrad@adacore.com>
KONRAD Frederic [Thu, 3 May 2018 15:17:14 +0000 (17:17 +0200)]
riscv: spike: allow base == 0
The sanity check on base doesn't allow htif to be mapped @0. Check if the
symbol exists instead so we can map it where we want.
Reviewed-by: Michael Clark <mjc@sifive.com> Signed-off-by: KONRAD Frederic <frederic.konrad@adacore.com> Signed-off-by: Michael Clark <mjc@sifive.com>
Message-Id: <1525360636-18229-2-git-send-email-frederic.konrad@adacore.com>
Peter Maydell [Fri, 4 May 2018 13:42:46 +0000 (14:42 +0100)]
Merge remote-tracking branch 'remotes/ericb/tags/pull-nbd-2018-05-04' into staging
nbd patches for 2018-05-04
- Vladimir Sementsov-Ogievskiy: 0/2 fix coverity bugs
- Eric Blake: nbd/client: Fix error messages during NBD_INFO_BLOCK_SIZE
- Eric Blake: nbd/client: Relax handling of large NBD_CMD_BLOCK_STATUS reply
# gpg: Signature made Fri 04 May 2018 14:25:55 BST
# gpg: using RSA key A7A16B4A2527436A
# gpg: Good signature from "Eric Blake <eblake@redhat.com>"
# gpg: aka "Eric Blake (Free Software Programmer) <ebb9@byu.net>"
# gpg: aka "[jpeg image of size 6874]"
# Primary key fingerprint: 71C2 CC22 B1C4 6029 27D2 F3AA A7A1 6B4A 2527 436A
* remotes/ericb/tags/pull-nbd-2018-05-04:
nbd/client: Relax handling of large NBD_CMD_BLOCK_STATUS reply
nbd/client: Fix error messages during NBD_INFO_BLOCK_SIZE
migration/block-dirty-bitmap: fix memory leak in dirty_bitmap_load_bits
nbd/client: fix nbd_negotiate_simple_meta_context
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Eric Blake [Thu, 3 May 2018 22:26:26 +0000 (17:26 -0500)]
nbd/client: Relax handling of large NBD_CMD_BLOCK_STATUS reply
The NBD spec is proposing a relaxation of NBD_CMD_BLOCK_STATUS
where a server may have the final extent per context give a
length beyond the original request, if it can easily prove that
subsequent bytes have the same status, on the grounds that a
client can take advantage of this information for fewer block
status requests. Since qemu 2.12 as a client always sends
NBD_CMD_FLAG_REQ_ONE, and rejects a server that sends extra
length, the upstream NBD spec will probably limit this behavior
to clients that don't request REQ_ONE semantics; but it doesn't
hurt to relax qemu to always be permissive of this server
behavior, even if it continues to use REQ_ONE.
CC: qemu-stable@nongnu.org Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20180503222626.1303410-1-eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Eric Blake [Tue, 1 May 2018 15:46:53 +0000 (10:46 -0500)]
nbd/client: Fix error messages during NBD_INFO_BLOCK_SIZE
A missing space makes for poor error messages, and sizes can't
go negative. Also, we missed diagnosing a server that sends
a maximum block size less than the minimum.
Fixes: 081dd1fe CC: qemu-stable@nongnu.org Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20180501154654.943782-1-eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Initialize received variable. Otherwise, is is possible for server to
answer without any contexts, but we will set context_id to something
random (received_id is not initialized too) and return 1, which is
wrong.
To solve it, just initialize received to false. Initialize received_id
too, just to make all possible checkers happy.
Bug was introduced in 78a33ab58782efdb206de14 "nbd: BLOCK_STATUS for
standard get_block_status function: client part" with the whole
function.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20180427142002.21930-2-vsementsov@virtuozzo.com> Reviewed-by: Eric Blake <eblake@redhat.com> CC: qemu-stable@nongnu.org Signed-off-by: Eric Blake <eblake@redhat.com>
Peter Maydell [Fri, 4 May 2018 12:49:08 +0000 (13:49 +0100)]
Merge remote-tracking branch 'remotes/armbru/tags/pull-qapi-2018-05-04' into staging
QAPI patches for 2018-05-04
# gpg: Signature made Fri 04 May 2018 08:59:16 BST
# gpg: using RSA key 3870B400EB918653
# gpg: Good signature from "Markus Armbruster <armbru@redhat.com>"
# gpg: aka "Markus Armbruster <armbru@pond.sub.org>"
# Primary key fingerprint: 354B C8B3 D7EB 2A6B 6867 4E5F 3870 B400 EB91 8653
* remotes/armbru/tags/pull-qapi-2018-05-04:
qapi: deprecate CpuInfoFast.arch
qapi: discriminate CpuInfoFast on SysEmuTarget, not CpuInfoArch
qapi: change the type of TargetInfo.arch from string to enum SysEmuTarget
qapi: add SysEmuTarget to "common.json"
qapi: fill in CpuInfoFast.arch in query-cpus-fast
qobject: Modify qobject_ref() to return obj
qobject: Replace qobject_incref/QINCREF qobject_decref/QDECREF
qobject: use a QObjectBase_ struct
qobject: Ensure base is at offset 0
qobject: Use qobject_to() instead of type cast
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Peter Maydell [Fri, 4 May 2018 10:53:58 +0000 (11:53 +0100)]
Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20180504' into staging
First s390x pull request for 2.13.
- new machine type
- extend SCLP event masks
- support configuration of consoles via -serial
- firmware improvements: non-sequential entries in boot menu, support
for indirect loading via .INS files in s390-netboot
- bugfixes and cleanups
* remotes/cohuck/tags/s390x-20180504:
pc-bios/s390: Update firmware images
s390-ccw: force diag 308 subcode to unsigned long
pc-bios/s390-ccw/net: Add support for .INS config files
pc-bios/s390-ccw/net: Use diag308 to reset machine before jumping to the OS
pc-bios/s390-ccw/net: Split up net_load() into init, load and release parts
pc-bios/s390-ccw: fix non-sequential boot entries (enum)
pc-bios/s390-ccw: fix non-sequential boot entries (eckd)
pc-bios/s390-ccw: fix loadparm initialization and int conversion
pc-bios/s390-ccw: rename MAX_TABLE_ENTRIES to MAX_BOOT_ENTRIES
pc-bios/s390-ccw: size_t should be unsigned
hw/s390x: Allow to configure the consoles with the "-serial" parameter
s390x/kvm: cleanup calls to cpu_synchronize_state()
vfio-ccw: introduce vfio_ccw_get_device()
s390x/sclp: extend SCLP event masks to 64 bits
s390x: introduce 2.13 compat machine
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Peter Maydell [Fri, 4 May 2018 09:13:13 +0000 (10:13 +0100)]
Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-2.13-20180504' into staging
ppc patch queue 2018-05-04
Second patch of patches for qemu-2.13 (or whatever the version ends up
being called). Highlights are:
* Preliminary patches for POWER9 hash MMU support for powernv
* A number of cleanups fo pseries startup and LPCR handling
* Remove support for explicitly allocated RMAs (which require kernel
support that's been gone for 3+ years)
* Some mac_newworld cleanups
* A few bugfixes
* remotes/dgibson/tags/ppc-for-2.13-20180504:
spapr: don't advertise radix GTSE if max-compat-cpu < power9
spapr: don't migrate "spapr_option_vector_ov5_cas" to pre 2.8 machines
target/ppc: always set PPC_MEM_TLBIE in pre 2.8 migration hack
mac_newworld: move wiring of macio IRQs to macio_newworld_realize()
mac_newworld: remove pics IRQ array and wire up macio to OpenPIC directly
uninorth: create new uninorth device
spapr: Clean up handling of LPCR power-saving exit bits
spapr: Move PAPR mode cpu setup fully to spapr code
target/ppc: Delay initialization of LPCR_UPRT for secondary cpus
spapr: Clean up LPCR updates from hypercalls
spapr: Make a helper to set up cpu entry point state
spapr: Remove unhelpful helpers from rtas_start_cpu()
spapr: Clean up rtas_start_cpu() & rtas_stop_self()
target/ppc: Add ppc_store_lpcr() helper
spapr: Remove support for explicitly allocated RMAs
target/ppc: add basic support for PTCR on POWER9
target/ppc: return a nil HPT base address on sPAPR machines
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* remotes/vivier2/tags/linux-user-for-2.13-pull-request:
linux-user: remove useless padding in flock64 structure
linux-user: introduce target_sigsp() and target_save_altstack()
linux-user: ARM-FDPIC: Add support for signals for FDPIC targets
linux-user: ARM-FDPIC: Add support of FDPIC for ARM.
linux-user: ARM-FDPIC: Identify ARM FDPIC binaries
Remove CONFIG_USE_FDPIC.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The TARGET_BASE_ARCH values from "configure" don't all map to the
@CpuInfoArch enum constants; in particular "s390x" from the former does
not match @s390 in the latter. Clients are known to rely on the @s390
constant specifically, so we can't change it silently. Instead, deprecate
the @CpuInfoFast.@arch member (in favor of @CpuInfoFast.@target) using the
regular deprecation process.
(No deprecation reminder is added to sysemu_target_to_cpuinfo_arch(): once
@CpuInfoFast.@arch is removed, the assignment expression that calls
sysemu_target_to_cpuinfo_arch() from qmp_query_cpus_fast() will have to
disappear; in turn the static function left without callers will also
break the build, thus it'll have to go.)
Cc: "Daniel P. Berrange" <berrange@redhat.com> Cc: Eric Blake <eblake@redhat.com> Cc: Markus Armbruster <armbru@redhat.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20180427192852.15013-6-lersek@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
qapi: discriminate CpuInfoFast on SysEmuTarget, not CpuInfoArch
Add a new field @target (of type @SysEmuTarget) to the output of the
@query-cpus-fast command, which provides more information about the
emulation target than the field @arch (of type @CpuInfoArch). Make @target
the new discriminator for the @CpuInfoFast return structure. Keep @arch
for compatibility.
Cc: "Daniel P. Berrange" <berrange@redhat.com> Cc: Eric Blake <eblake@redhat.com> Cc: Markus Armbruster <armbru@redhat.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
Message-Id: <20180427192852.15013-5-lersek@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
We'll soon need an enumeration type that lists all the softmmu targets
that QEMU (the project) supports. Introduce @SysEmuTarget to
"common.json".
The enum constant @x86_64 doesn't match the QAPI convention of preferring
hyphen ("-") over underscore ("_"). This is intentional; the @SysEmuTarget
constants are supposed to produce QEMU executable names when stringified
and appended to the "qemu-system-" prefix. Put differently, the
replacement text of the TARGET_NAME preprocessor macro must be possible to
look up in the list of (stringified) enum constants.
Like other enum types, @SysEmuTarget too can be used for discriminator
fields in unions. For the @i386 constant, a C-language union member called
"i386" would be generated. On mingw build hosts, "i386" is a macro
however. Add "i386" to "polluted_words" at once.
Cc: "Daniel P. Berrange" <berrange@redhat.com> Cc: Eric Blake <eblake@redhat.com> Cc: Markus Armbruster <armbru@redhat.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20180427192852.15013-3-lersek@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
* Commit ca230ff33f89 added the @arch field to @CpuInfoFast, but it failed
to set the new field in qmp_query_cpus_fast(), when TARGET_S390X was not
defined. The updated @query-cpus-fast example in "qapi-schema.json"
showed "arch":"x86" only because qmp_query_cpus_fast() calls g_malloc0()
to allocate @CpuInfoFast, and the CPU_INFO_ARCH_X86 enum constant is
generated with value 0.
All @arch values other than @s390 implied the @CpuInfoOther sub-struct
for @CpuInfoFast -- at the time of writing the patch --, thus no fields
other than @arch needed to be set when TARGET_S390X was not defined. Set
@arch now, by copying the corresponding assignments from
qmp_query_cpus().
* Commit 25fa194b7b11 added the @riscv enum constant to @CpuInfoArch (used
in both @CpuInfo and @CpuInfoFast -- the return types of the @query-cpus
and @query-cpus-fast commands, respectively), and assigned, in both
return structures, the @CpuInfoRISCV sub-structure to the new enum
value.
However, qmp_query_cpus_fast() would not populate either the @arch field
or the @CpuInfoRISCV sub-structure, when TARGET_RISCV was defined; only
qmp_query_cpus() would.
Assign @CpuInfoOther to the @riscv enum constant in @CpuInfoFast, and
populate only the @arch field in qmp_query_cpus_fast(). Getting CPU
state without interrupting KVM is an exceptional thing that only S390X
does currently. Quoting Cornelia Huck <cohuck@redhat.com>, "s390x is
exceptional in that it has state in QEMU that is actually interesting
for upper layers and can be retrieved without performance penalty". See
also
<https://www.redhat.com/archives/libvir-list/2018-February/msg00121.html>.
Cc: Cornelia Huck <cohuck@redhat.com> Cc: Eric Blake <eblake@redhat.com> Cc: Markus Armbruster <armbru@redhat.com> Cc: Viktor VM Mihajlovski <mihajlov@linux.vnet.ibm.com> Cc: qemu-stable@nongnu.org Fixes: ca230ff33f89bf7102cbfbc2328716da6750aaed Fixes: 25fa194b7b11901561532e435beb83d046899f7a Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20180427192852.15013-2-lersek@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
For convenience and clarity, make it possible to call qobject_ref() at
the time when the reference is associated with a variable, or
argument, by making qobject_ref() return the same pointer as given.
Use that to simplify the callers.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
Message-Id: <20180419150145.24795-5-marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com>
[Useless change to qobject_ref_impl() dropped, commit message improved
slightly] Signed-off-by: Markus Armbruster <armbru@redhat.com>
Now that we can safely call QOBJECT() on QObject * as well as its
subtypes, we can have macros qobject_ref() / qobject_unref() that work
everywhere instead of having to use QINCREF() / QDECREF() for QObject
and qobject_incref() / qobject_decref() for its subtypes.
The replacement is mechanical, except I broke a long line, and added a
cast in monitor_qmp_cleanup_req_queue_locked(). Unlike
qobject_decref(), qobject_unref() doesn't accept void *.
Note that the new macros evaluate their argument exactly once, thus no
need to shout them.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
Message-Id: <20180419150145.24795-4-marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com>
[Rebased, semantic conflict resolved, commit message improved] Signed-off-by: Markus Armbruster <armbru@redhat.com>
By moving the base fields to a QObjectBase_, QObject can be a type
which also has a 'base' field. This allows writing a generic QOBJECT()
macro that will work with any QObject type, including QObject
itself. The container_of() macro ensures that the object to cast has a
QObjectBase_ base field, giving some type safety guarantees. QObject
must have no members but QObjectBase_ base, or else QOBJECT() breaks.
QObjectBase_ is not a typedef and uses a trailing underscore to make
it obvious it is not for normal use and to avoid potential abuse.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
Message-Id: <20180419150145.24795-3-marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
All QObject types have the base QObject as their first field. This
allows the simplification of qobject_to().
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
Message-Id: <20180419150145.24795-2-marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com>
[Commit message paragraph on type casts dropped, to avoid giving the
impression type casting would be okay] Signed-off-by: Markus Armbruster <armbru@redhat.com>
Greg Kurz [Thu, 3 May 2018 21:16:59 +0000 (23:16 +0200)]
spapr: don't advertise radix GTSE if max-compat-cpu < power9
On a POWER9 host, if a guest runs in pre POWER9 compat mode, it necessarily
uses the hash MMU mode. In this case, we shouldn't advertise radix GTSE in
the ibm,arch-vec-5-platform-support DT property as the current code does.
The first reason is that it doesn't make sense, and the second one is that
causes the CAS-negotiated options subsection to be migrated. This breaks
backward migration to QEMU 2.7 and older versions on POWER8 hosts:
qemu-system-ppc64: error while loading state for instance 0x0 of device
'spapr'
qemu-system-ppc64: load of migration failed: No such file or directory
This patch hence initialize CPUs a bit earlier so that we can check the
requested compat mode, and don't set OV5_MMU_RADIX_GTSE for power8 and
older.
Signed-off-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Greg Kurz [Thu, 3 May 2018 21:16:48 +0000 (23:16 +0200)]
spapr: don't migrate "spapr_option_vector_ov5_cas" to pre 2.8 machines
a324d6f16697 "spapr: Support ibm,dynamic-memory-v2 property" added
a new feature in the set of CAS-negotiatable options. This causes
the CAS-negotiated options subsection to be migrated, even for old
machine types that don't know about it, and breaks backward migration
to QEMU 2.7 and older versions:
qemu-system-ppc64: error while loading state for instance 0x0 of device
'spapr'
qemu-system-ppc64: load of migration failed: No such file or directory
Since this feature only affects boot time behaviour, it should be
filtered out when we decide to migrate CAS-negotiated options, like
we already do with OV5_FORM1_AFFINITY and OV5_DRCONF_MEMORY.
Signed-off-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Greg Kurz [Thu, 3 May 2018 21:16:29 +0000 (23:16 +0200)]
target/ppc: always set PPC_MEM_TLBIE in pre 2.8 migration hack
The pseries-2.7 and older machine types require CPUPPCState::insns_flags
to be strictly equal between source and destination. This checking is
abusive and breaks migration of KVM guests when the host CPU models
are different, even if they are compatible enough to allow the guest
to run transparently. This buggy behaviour was fixed for pseries-2.8
and we added some hacks to allow backward migration of older machine
types. These hacks assume that the CPU belongs to the POWER8 family,
which was true for most KVM based setup we cared about at the time.
But now POWER9 systems are coming, and backward migration of pre 2.8
guests running in POWER8 architected mode from a POWER9 host to a
POWER8 host is broken:
qemu-system-ppc64: error while loading state for instance 0x0 of device
'cpu'
qemu-system-ppc64: load of migration failed: Invalid argument
This happens because POWER9 doesn't set PPC_MEM_TLBIE in insns_flags,
while POWER8 does. Let's force PPC_MEM_TLBIE in the migration hack to
fix the issue. This is an acceptable hack because these old machine
types only support CPU models that do set PPC_MEM_TLBIE.
Signed-off-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
mac_newworld: move wiring of macio IRQs to macio_newworld_realize()
Since the macio device has a link to the PIC device, we can now wire up the
IRQs directly via qdev GPIOs rather than having to use an intermediate array.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Commit 4e46dcdbd3 "PPC: Newworld: Add uninorth token register" added a TODO
which was to convert the uninorth registers hack to a proper device. Move
these registers to a new uninorth device, removing the old hacks from
mac_newworld.c.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
David Gibson [Thu, 5 Apr 2018 06:27:18 +0000 (16:27 +1000)]
spapr: Clean up handling of LPCR power-saving exit bits
To prevent spurious wakeups on cpus that are supposed to be disabled, we
need to clear the LPCR bits which control certain wakeup events.
spapr_cpu_reset() has separate cases here for boot and non-boot (initially
inactive) cpus. rtas_start_cpu() then turns the LPCR bits on when the
non-boot cpus are activated.
But explicit checks against first_cpu are not how we usually do things:
instead spapr_cpu_reset() generally sets things up for non-boot (inactive)
cpus, then spapr_machine_reset() and/or rtas_start_cpu() override as
necessary.
So, do that instead. Because the LPCR activation is identical for boot
cpus and non-boot cpus just activated with rtas_start_cpu() we can put the
code common in spapr_cpu_set_entry_state().
Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Tested-by: Cédric Le Goater <clg@kaod.org>
David Gibson [Thu, 5 Apr 2018 06:02:51 +0000 (16:02 +1000)]
spapr: Move PAPR mode cpu setup fully to spapr code
cpu_ppc_set_papr() does several things:
1) it sets up the virtual hypervisor interface
2) it prevents the cpu from ever entering hypervisor mode
3) it tells KVM that we're emulating a cpu in PAPR mode
and 4) it configures the LPCR and AMOR (hypervisor privileged registers)
so that TCG will behave correctly for PAPR guests, without
attempting to emulate the cpu in hypervisor mode
(1) & (2) make sense for any virtual hypervisor (if another one ever
exists).
(3) belongs more properly in the machine type specific to a PAPR guest, so
move it to spapr_cpu_init(). While we're at it, remove an ugly test on
kvm_enabled() by making kvmppc_set_papr() a safe no-op on non-KVM.
(4) also belongs more properly in the machine type specific code. (4) is
done by mangling the default values of the SPRs, so that they will be set
correctly at reset time. Manipulating usually-static parameters of the cpu
model like this is kind of ugly, especially since the values used really
have more to do with the platform than the cpu.
The spapr code already has places for PAPR specific initializations of
register state in spapr_cpu_reset(), so move this handling there.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Tested-by: Cédric Le Goater <clg@kaod.org>
David Gibson [Tue, 1 May 2018 06:08:50 +0000 (16:08 +1000)]
target/ppc: Delay initialization of LPCR_UPRT for secondary cpus
In cpu_ppc_set_papr() the UPRT and GTSE bits of the LPCR default value are
initialized based on on ppc64_radix_guest(). Which seems reasonable,
except that ppc64_radix_guest() is based on spapr->patb_entry which is
only set up in spapr_machine_reset, called _after_ cpu_ppc_set_papr() for
boot cpus. Well, and the fact that modifying the SPR default value for an
instance rather than a class is kind of yucky.
The initialization here is really only necessary or valid for
hotplugged cpus; the base cpu initialization already sets a value
that's good enough for the boot cpus until the guest uses an hcall to
configure it's preferred MMU mode.
So, move this initialization to the rtas_start_cpu() path, at which point
ppc64_radix_guest() will have a sensible value, to make sure secondary cpus
come up in an MMU mode matching the existing cpus.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Tested-by: Cédric Le Goater <clg@kaod.org>
David Gibson [Tue, 1 May 2018 05:14:52 +0000 (15:14 +1000)]
spapr: Clean up LPCR updates from hypercalls
There are several places in spapr_hcall.c where we need to update the LPCR
value on all CPUs. We do this with the set_spr() helper. That's not
really correct because this directly sets the SPR value, without going
through the ppc_store_lpcr() helper which may need to update state based
on the LPCR change.
In fact, set_spr() is only ever used for the LPCR, so replace it with an
explicit LPCR updated which uses the right low-level helper. While we're
there, move the CPU_FOREACH() which was in every one of the callers into
the new helper: set_all_lpcrs().
Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Tested-by: Cédric Le Goater <clg@kaod.org>
David Gibson [Tue, 1 May 2018 06:22:49 +0000 (16:22 +1000)]
spapr: Make a helper to set up cpu entry point state
Under PAPR, only the boot CPU is active when the system starts. Other cpus
must be explicitly activated using an RTAS call. The entry state for the
boot and secondary cpus isn't identical, but it has some things in common.
We're going to add a bit more common setup later, too, so to simplify
make a helper which sets up the common entry state for both boot and
secondary cpu threads.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Cédric Le Goater <clg@kaod.org> Tested-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org>
David Gibson [Tue, 1 May 2018 06:05:09 +0000 (16:05 +1000)]
spapr: Remove unhelpful helpers from rtas_start_cpu()
rtas_start_cpu() calls spapr_cpu_update_tb_offset() and
spapr_cpu_set_endianness() to initialize certain things in the new cpu's
state. This is the only caller of those helpers, and they're each only
a few lines long, so we might as well just fold them into the caller.
In addition, those helpers initialize state on the new cpu to match that of
the first cpu. That will generally work, but might be at least logically
incorrect if the first cpu has been set offline by the guest. So, instead
base the state on that of the cpu invoking the RTAS call, which is
obviously active already.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Tested-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org>
David Gibson [Tue, 1 May 2018 05:43:58 +0000 (15:43 +1000)]
spapr: Clean up rtas_start_cpu() & rtas_stop_self()
This makes several minor cleanups to these functions:
* Follow usual convention of an early exit on error, rather than having
most of the body in an if
* Clearer naming of cpu and cpu_. Now callcpu is the cpu from which the
RTAS call is invoked, newcpu is the cpu which we're starting
* Use cpu_synchronize_state() instead of kvm_cpu_synchronize_state()
directly
* Remove pointless comment describing what cpu_synchronize_state() does
* Use ppc_store_lpcr() instead of directly writing the register field
Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Tested-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org>
David Gibson [Thu, 5 Apr 2018 06:43:59 +0000 (16:43 +1000)]
target/ppc: Add ppc_store_lpcr() helper
There are some fields in the cpu state which need to be updated when the
LPCR register is changed, which is done by ppc_hash64_update_rmls() and
ppc_hash64_update_vrma(). Code which alters env->spr[SPR_LPCR] needs to
call them afterwards to make sure the state is up to date.
That's easy to get wrong. The normal way of dealing with sitautions like
that is to use a helper which both updates the basic register value and the
derived state.
So, do that.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Tested-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org>
David Gibson [Thu, 3 May 2018 06:52:40 +0000 (16:52 +1000)]
spapr: Remove support for explicitly allocated RMAs
Current POWER cpus allow for a VRMA, a special mapping which describes a
guest's view of memory when in real mode (MMU off, from the guest's point
of view). Older cpus didn't have that which meant that to support a guest
a special host-contiguous region of memory was needed to give the guest its
Real Mode Area (RMA).
KVM used to provide special calls to allocate a contiguous RMA for those
cases. This was useful in the early days of KVM on Power to allow it to be
tested on PowerPC 970 chips as used in Macintosh G5 machines. Now, those
machines are so old as to be almost irrelevant.
The normal qemu deprecation process would require this to be marked
deprecated then removed in 2 releases. However, this can only be used
with corresponding support in the host kernel - which was dropped
years ago (in c17b98cf "KVM: PPC: Book3S HV: Remove code for PPC970
processors" of 2014-12-03 to be precise). Therefore it should be ok
to drop this immediately.
Just to be clear this only affects *KVM HV* guests with PowerPC 970,
and those already require an ancient host kernel. TCG and KVM PR
guests with PowerPC 970 should still work.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Acked-by: Thomas Huth <thuth@redhat.com>
The Partition Table Control Register (PTCR) is a hypervisor privileged
SPR. It contains the host real address of the Partition Table and its
size.
Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
target/ppc: return a nil HPT base address on sPAPR machines
commit e57ca75ce3b2 ("target/ppc: Manage external HPT via virtual
hypervisor") exported a set of methods to manipulate the HPT from the
core hash MMU. But SPR_SDR1 is still used under some circumstances to
get the base address of the HPT, which is incorrect for the sPAPR
machines.
Only the logging should be impacted.
Signed-off-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
# gpg: Signature made Thu 03 May 2018 18:53:00 BST
# gpg: using RSA key 36D4C0F0CF2FE46D
# gpg: Good signature from "Marcel Apfelbaum <marcel@redhat.com>"
# 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: B1C6 3A57 F92E 08F2 640F 31F5 36D4 C0F0 CF2F E46D
* remotes/marcel/tags/rdma-pull-request:
MAINTAINERS: update Marcel Apfelbaum email
hw/rdma: Fix possible out of bounds access to port GID index
hw/rdma: Delete duplicate definition of MAX_RM_TBL_NAME
hw/rdma: Fix possible out of bounds access to regs array
hw/rdma: Fix possible out of bounds access to GID table
hw/rdma: Delete port's pkey table
hw/rdma: Fix possible usage of a NULL pointer
hw/rdma: Fix possible munmap call on a NULL pointer
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Laurent Vivier [Wed, 2 May 2018 21:57:30 +0000 (23:57 +0200)]
linux-user: remove useless padding in flock64 structure
Since commit 8efb2ed5ec ("linux-user: Correct signedness of
target_flock l_start and l_len fields"), flock64 structure uses
abi_llong for l_start and l_len in place of "unsigned long long"
this should force them to be aligned accordingly to the target
rules. So we can remove the padding field and the QEMU_PACKED
attribute.
I have compared the result of the following program before and
after the change:
for file in build/all/*-linux-user/qemu-* ; do
echo $file
gdb -batch -nx -x flock64_dump $file 2> /dev/null
done
The sizeof() changes because we remove the QEMU_PACKED.
The new size is 32 (except for i386 and m68k) and this is
the real size of "struct flock64" on the target architecture.
The following architectures differ:
aarch64_be, aarch64, alpha, armeb, arm, cris, hppa, nios2, or1k,
riscv32, riscv64, s390x.
For a subset of these architectures, I have checked with the following
program the new structure is the correct one:
For ARM, the target_flock64 becomes the EABI definition, so we need to
define the OABI one in place of the EABI one and use it when it is
needed.
I have also fixed the alignment value for sh4 (to align llong on 4 bytes)
(see c2e3dee6e0 "linux-user: Define target alignment size")
[We should check alignment properties for cris, nios2 and or1k]
Signed-off-by: Laurent Vivier <laurent@vivier.eu> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20180502215730.28162-1-laurent@vivier.eu>
linux-user: ARM-FDPIC: Add support for signals for FDPIC targets
The FDPIC restorer needs to deal with a function descriptor, hence we
have to extend 'retcode' such that it can hold the instructions needed
to perform this.
The restorer sequence uses the same thumbness as the exception
handler (mainly to support Thumb-only architectures).
Co-Authored-By: Mickaël Guêné <mickael.guene@st.com> Signed-off-by: Christophe Lyon <christophe.lyon@st.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20180430080404.7323-5-christophe.lyon@st.com>
[lv: moved the change to linux-user/arm/signal.c] Signed-off-by: Laurent Vivier <laurent@vivier.eu>
We want to avoid code disabled by default, because it ends up less
tested. This patch removes all instances of #ifdef CONFIG_USE_FDPIC,
most of which can be safely kept. For the ones that should be
conditionally executed, we define elf_is_fdpic(). Without this patch,
defining CONFIG_USE_FDPIC would prevent QEMU from building precisely
because elf_is_fdpic is not defined.
Cornelia Huck [Thu, 3 May 2018 14:32:41 +0000 (16:32 +0200)]
Merge tag 'tags/s390x-2018-05-02' into staging
s390-ccw firmware updates:
- Improvements to the boot menu (can now handle non-sequential entries)
- s390-netboot now resets the machine before jumping into the OS kernel
- s390-netboot now supports indirect loading via .INS files
- some other minor fixes and clean-ups
# gpg: Signature made Wed 02 May 2018 04:15:21 PM CEST
# gpg: using RSA key 2ED9D774FE702DB5
# gpg: Good signature from "Thomas Huth <th.huth@gmx.de>" [full]
# gpg: aka "Thomas Huth <thuth@redhat.com>" [undefined]
# gpg: aka "Thomas Huth <huth@tuxfamily.org>" [undefined]
# gpg: aka "Thomas Huth <th.huth@posteo.de>" [unknown]
* tag 'tags/s390x-2018-05-02':
pc-bios/s390: Update firmware images
s390-ccw: force diag 308 subcode to unsigned long
pc-bios/s390-ccw/net: Add support for .INS config files
pc-bios/s390-ccw/net: Use diag308 to reset machine before jumping to the OS
pc-bios/s390-ccw/net: Split up net_load() into init, load and release parts
pc-bios/s390-ccw: fix non-sequential boot entries (enum)
pc-bios/s390-ccw: fix non-sequential boot entries (eckd)
pc-bios/s390-ccw: fix loadparm initialization and int conversion
pc-bios/s390-ccw: rename MAX_TABLE_ENTRIES to MAX_BOOT_ENTRIES
pc-bios/s390-ccw: size_t should be unsigned
Thomas Huth [Wed, 2 May 2018 13:42:57 +0000 (15:42 +0200)]
pc-bios/s390: Update firmware images
s390-ccw.img contains fixes for the boot menu, and s390-netboot.img
contains the support for .INS files and the patch for resetting the
machine with diag308.
Cornelia Huck [Wed, 2 May 2018 12:52:21 +0000 (14:52 +0200)]
s390-ccw: force diag 308 subcode to unsigned long
We currently pass an integer as the subcode parameter. However,
the upper bits of the register containing the subcode need to
be 0, which is not guaranteed unless we explicitly specify the
subcode to be an unsigned long value.
Fixes: d046c51dad3 ("pc-bios/s390-ccw: Get device address via diag 308/6") Cc: qemu-stable@nongnu.org Signed-off-by: Cornelia Huck <cohuck@redhat.com> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Tested-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
Thomas Huth [Wed, 18 Apr 2018 12:02:37 +0000 (14:02 +0200)]
pc-bios/s390-ccw/net: Add support for .INS config files
The .INS config files can normally be found on CD-ROM ISO images,
so by supporting these files, it is now possible to boot directly
when the TFTP server is set up with the contents of such an CD-ROM
image.
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
Thomas Huth [Fri, 20 Apr 2018 09:30:42 +0000 (11:30 +0200)]
pc-bios/s390-ccw/net: Use diag308 to reset machine before jumping to the OS
The netboot firmware so far simply jumped directly into the OS kernel
after the download has been completed. This, however, bears the risk
that the virtio-net device still might be active in the background and
incoming packets are still placed into the buffers - which could destroy
memory of the now-running Linux kernel in case it did not take over the
device fast enough. Also the SCLP console is not put into a well-defined
state here. We should hand over the system in a clean state when jumping
into the kernel, so let's use the same mechanism as it's done in the
main s390-ccw firmware and reset the machine with diag308 into a clean
state before jumping into the OS kernel code. To be able to share the
code with the main s390-ccw firmware, the related functions are now
extracted from bootmap.c into a new file called jump2ipl.c.
Since we now also set the boot device schid at address 184 for the network
boot device, this patch also slightly changes the way how we detect the
entry points for non-ELF binary images: The code now looks for the "S390EP"
magic first and then jumps to 0x10000 in case it has been found. This is
necessary for booting from network devices, since the normal kernel code
(where the PSW at ddress 0 points to) tries to do a block load from the
boot device. This of course fails for a virtio-net device and causes the
kernel to abort with a panic-PSW silently.
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
Thomas Huth [Tue, 17 Apr 2018 05:36:10 +0000 (07:36 +0200)]
pc-bios/s390-ccw/net: Split up net_load() into init, load and release parts
When we want to support pxelinux-style network booting later, we've got
to do several TFTP transfers - and we do not want to apply for a new IP
address via DHCP each time. So split up net_load into three parts:
1. net_init(), which initializes virtio-net, gets an IP address via DHCP
and prints out the related information.
2. The tftp_load call is now moved directly into the main() function
3. A new net_release() function which should tear down the network stack
before we are done in the firmware.
This will make it easier to extend the code in the next patches.
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
zIPL boot menu entries can be non-sequential. Let's account
for this issue for the s390 enumerated boot menu. Since we
can no longer print a range of available entries to the
user, we have to present a list of each available entry.
An example of this menu:
s390-ccw Enumerated Boot Menu.
[0] default
[1]
[2]
[7]
[8]
[9]
[11]
[12]
Please choose:
Signed-off-by: Collin Walling <walling@linux.ibm.com> Reported-by: Vasily Gorbik <gor@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Janosch Frank <frankja@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
zIPL boot menu entries can be non-sequential. Let's account
for this issue for the s390 zIPL boot menu. Since this boot
menu is actually an imitation and is not completely capable
of everything the real zIPL menu can do, let's also print a
different banner to the user.
Signed-off-by: Collin Walling <walling@linux.ibm.com> Reported-by: Vasily Gorbik <gor@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Janosch Frank <frankja@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
pc-bios/s390-ccw: fix loadparm initialization and int conversion
Rename the loadparm char array in main.c to loadparm_str and
increased the size by one byte to account for a null termination
when converting the loadparm string to an int via atoui. We
also allow the boot menu to be enabled when loadparm is set to
an empty string or a series of spaces.
Signed-off-by: Collin Walling <walling@linux.ibm.com> Reported-by: Vasily Gorbik <gor@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Janosch Frank <frankja@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
pc-bios/s390-ccw: rename MAX_TABLE_ENTRIES to MAX_BOOT_ENTRIES
The MAX_TABLE_ENTRIES constant has a name that is too generic. As we
want to declare a limit for boot menu entries, let's rename it to a more
fitting MAX_BOOT_ENTRIES and set its value to 31 (30 boot entries and
1 default entry). Also we move it from bootmap.h to s390-ccw.h to make
it available for menu.c in a later patch.
Signed-off-by: Collin Walling <walling@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Janosch Frank <frankja@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
Thomas Huth [Fri, 13 Apr 2018 14:22:13 +0000 (16:22 +0200)]
pc-bios/s390-ccw: size_t should be unsigned
"size_t" should be an unsigned type according to the C standard.
Thus we should also use this convention in the s390-ccw firmware to avoid
confusion. I checked the sources, and apart from one spot in libc.c, the
code should all be fine with this change.
Buglink: https://bugs.launchpad.net/qemu/+bug/1753437 Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: Halil Pasic <pasic@linux.vnet.ibm.com> Reviewed-by: Collin Walling <walling@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
tcg: workaround branch instruction overflow in tcg_out_qemu_ld/st
ppc64 uses a BC instruction to call the tcg_out_qemu_ld/st
slow path. BC instruction uses a relative address encoded
on 14 bits.
The slow path functions are added at the end of the generated
instructions buffer, in the reverse order of the callers.
So more we have slow path functions more the distance between
the caller (BC) and the function increases.
This patch changes the behavior to generate the functions in
the same order of the callers.
Henry Wertz [Tue, 17 Apr 2018 22:06:23 +0000 (12:06 -1000)]
tcg/arm: Fix memory barrier encoding
I found with qemu 2.11.x or newer that I would get an illegal instruction
error running some Intel binaries on my ARM chromebook. On investigation,
I found it was quitting on memory barriers.
After patch it gives:
0x604050cc: f57ff05b dmb ish
In short, I found INSN_DMB_ISH (memory barrier for ARMv7) appeared to be
correct based on online docs, but due to some endian-related shenanigans it
had to be byte-swapped to suit qemu; it appears INSN_DMB_MCR (memory
barrier for ARMv6) also should be byte swapped (and this patch does so).
I have not checked for correctness of aarch64's barrier instruction.
Cc: qemu-stable@nongnu.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Henry Wertz <hwertz10@gmail.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Peter Maydell [Mon, 30 Apr 2018 15:12:00 +0000 (16:12 +0100)]
Merge remote-tracking branch 'remotes/edgar/tags/edgar/xilinx-next-2018-04-30.for-upstream' into staging
edgar/xilinx-next-2018-01.for-upstream
# gpg: Signature made Mon 30 Apr 2018 15:52:35 BST
# gpg: using RSA key 29C596780F6BCA83
# gpg: Good signature from "Edgar E. Iglesias (Xilinx key) <edgar.iglesias@xilinx.com>"
# gpg: aka "Edgar E. Iglesias <edgar.iglesias@gmail.com>"
# Primary key fingerprint: AC44 FEDC 14F7 F1EB EDBF 4151 29C5 9678 0F6B CA83
* remotes/edgar/tags/edgar/xilinx-next-2018-04-30.for-upstream:
target-microblaze: mmu: Make the TLBX MISS bit read-only
target-microblaze: mmu: Make TLBSX write-only
target-microblaze: Don't clobber the IMM reg for ld/st reversed
target-microblaze: Fix trap checks for FPU insns
target-microblaze: Respect MSR.PVR as read-only
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
target-microblaze: mmu: Make the TLBX MISS bit read-only
Make the TLBX MISS bit read-only.
Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
Make TLBSX write-only and guest-error log reads from it.
Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
Fix trap checks for FPU insns when extended FPU insns are enabled.
Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
Pavel Dovgalyuk [Wed, 18 Apr 2018 06:41:53 +0000 (09:41 +0300)]
m68k: fix subx mem, mem instruction
This patch fixes decrement of the pointers for subx mem, mem instructions.
Without the patch pointers are decremented by OS_* constant value instead of
retrieving the corresponding data size and using it as a decrement.
* remotes/vivier2/tags/linux-user-for-2.13-pull-request: (42 commits)
linux-user: Add ARM get_tls syscall support
linux-user: move xtensa cpu loop to xtensa directory
linux-user: move hppa cpu loop to hppa directory
linux-user: move riscv cpu loop to riscv directory
linux-user: move tilegx cpu loop to tilegx directory
linux-user: move s390x cpu loop to s390x directory
linux-user: move alpha cpu loop to alpha directory
linux-user: move m68k cpu loop to m68k directory
linux-user: move microblaze cpu loop to microblaze directory
linux-user: move cris cpu loop to cris directory
linux-user: move sh4 cpu loop to sh4 directory
linux-user: move openrisc cpu loop to openrisc directory
linux-user: move nios2 cpu loop to nios2 directory
linux-user: move mips/mips64 cpu loop to mips directory
linux-user: move ppc/ppc64 cpu loop to ppc directory
linux-user: move sparc/sparc64 cpu loop to sparc directory
linux-user: move arm cpu loop to arm directory
linux-user: move aarch64 cpu loop to aarch64 directory
linux-user: move i386/x86_64 cpu loop to i386 directory
linux-user: create a dummy per arch cpu_loop.c
...
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Thomas Huth [Thu, 26 Apr 2018 14:59:54 +0000 (16:59 +0200)]
hw/s390x: Allow to configure the consoles with the "-serial" parameter
The consoles ("sclpconsole" and "sclplmconsole") can only be configured
with "-device" and "-chardev" so far. Other machines use the convenience
option "-serial" to configure the default consoles, even for virtual
consoles like spapr-vty on the pseries machine. So let's support this
option on s390x, too. This way we can easily enable the serial console
here again with "-nodefaults", for example:
The -serial parameter can also be used if you only want to see the QEMU
monitor on stdio without using -nodefaults, but not the console output.
That's something that is pretty impossible with the current code today:
While we're at it, this patch also maps the second -serial option to the
"sclplmconsole", so that there is now an easy way to configure this second
console on s390x, too, for example:
Additionally, the new code is also smaller than the old one and we have
less s390x-specific code in vl.c :-)
I've also checked that migration still works as expected by migrating
a guest with console output back and forth between a qemu-system-s390x
that has this patch and an instance without this patch.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-Id: <1524754794-28005-1-git-send-email-thuth@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
Greg Kurz [Mon, 9 Apr 2018 10:15:10 +0000 (12:15 +0200)]
vfio-ccw: introduce vfio_ccw_get_device()
A recent patch fixed leaks of the dynamically allocated vcdev->vdev.name
field in vfio_ccw_realize(), but we now have three freeing sites for it.
This is unfortunate and seems to indicate something is wrong with its
life cycle.
The root issue is that vcdev->vdev.name is set before vfio_get_device()
is called, which theoretically prevents to call vfio_put_device() to
do the freeing. Well actually, we could call it anyway because
vfio_put_base_device() is a nop if the device isn't attached, but this
would be confusing.
This patch hence moves all the logic of attaching the device, including
the "already attached" check, to a separate vfio_ccw_get_device() function,
counterpart of vfio_put_device(). While here, vfio_put_device() is renamed
to vfio_ccw_put_device() for consistency.
Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <152326891065.266543.9487977590811413472.stgit@bahia.lan> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
linux-user: move riscv cpu loop to riscv directory
No code change, only move code from main.c to
riscv/cpu_loop.c.
Signed-off-by: Laurent Vivier <laurent@vivier.eu> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Michael Clark <mjc@sifive.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20180411185651.21351-18-laurent@vivier.eu>
projects / mirror_qemu.git / log