With MT-TCG, we are now running translation in a racy way, thus
we need to mimic hardware when it comes to updating the R and
C bits, by doing byte stores.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20190411080004.8690-5-clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
With MT-TCG, we are now running translation in a racy way, thus
we need to mimic hardware when it comes to updating the R and
C bits, by doing byte stores.
The current "store_hpte" abstraction is ill suited for this, we
replace it with two separate callbacks for setting R and C.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20190411080004.8690-4-clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20190411080004.8690-3-clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
It appears that during kexec, we run for a while in hypervisor
real mode with LPCR:HR set and LPCR:UPRT clear, which trips
the assertion in ppc_radix64_handle_mmu_fault().
First this shouldn't be an assertion, it's a guest error.
Then we shouldn't be checking these things in hypervisor real
mode (or in virtual hypervisor guest real mode which is similar)
as the real HW won't use those LPCR bits in those cases anyway,
so technically it's ok to have this discrepancy.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20190411080004.8690-2-clg@kaod.org>
[dwg: Fix for 32-bit builds]
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <155445152490.302073.17033451726459859333.stgit@bahia.lan>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <155445151931.302073.18436485925081597460.stgit@bahia.lan>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
LSI mapping in spapr currently open-codes standard PCI swizzling. It thus
duplicates the code of pci_swizzle_map_irq_fn().
Expose the swizzling formula so that it can be used with a slot number
when building the device tree. Simply drop pci_spapr_map_irq() and call
pci_swizzle_map_irq_fn() instead.
Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <155448184841.8446.13959787238854054119.stgit@bahia.lan>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
According to the changelog of 298a971024, SpaprPhbState::dtbusname was
introduced to "make it easier to relate the guest and qemu views of memory
to each other", hence its name.
Use it when creating the PHB node to avoid code duplication.
Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <155448184292.8446.8225650773162648595.stgit@bahia.lan>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
spapr_ics_create() is only called once. Merge it in spapr_irq_init_xics()
and simplify a bit the error handling by using 'error_fatal' .
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20190321144914.19934-13-clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Removing RTAS handlers will become necessary when the new pseries
machine supporting multiple interrupt mode is introduced.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20190321144914.19934-9-clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
In commit 47973a2dbf we split the last generic chipset out of
the PC board, but missed to remove the i8042 keyboard controller.
This omission was later fixed in commit 7cb00357c1, but here we
forgot to remove the "i8042.h" include. Do it now.
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20190316201528.9140-1-philmd@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
NVIDIA V100 GPUs have on-board RAM which is mapped into the host memory
space and accessible as normal RAM via an NVLink bus. The VFIO-PCI driver
implements special regions for such GPUs and emulates an NVLink bridge.
NVLink2-enabled POWER9 CPUs also provide address translation services
which includes an ATS shootdown (ATSD) register exported via the NVLink
bridge device.
This adds a quirk to VFIO to map the GPU memory and create an MR;
the new MR is stored in a PCI device as a QOM link. The sPAPR PCI uses
this to get the MR and map it to the system address space.
Another quirk does the same for ATSD.
This adds additional steps to sPAPR PHB setup:
1. Search for specific GPUs and NPUs, collect findings in
sPAPRPHBState::nvgpus, manage system address space mappings;
2. Add device-specific properties such as "ibm,npu", "ibm,gpu",
"memory-block", "link-speed" to advertise the NVLink2 function to
the guest;
3. Add "mmio-atsd" to vPHB to advertise the ATSD capability;
4. Add new memory blocks (with extra "linux,memory-usable" to prevent
the guest OS from accessing the new memory until it is onlined) and
npuphb# nodes representing an NPU unit for every vPHB as the GPU driver
uses it for link discovery.
This allocates space for GPU RAM and ATSD like we do for MMIOs by
adding 2 new parameters to the phb_placement() hook. Older machine types
set these to zero.
This puts new memory nodes in a separate NUMA node to as the GPU RAM
needs to be configured equally distant from any other node in the system.
Unlike the host setup which assigns numa ids from 255 downwards, this
adds new NUMA nodes after the user configures nodes or from 1 if none
were configured.
This adds requirement similar to EEH - one IOMMU group per vPHB.
The reason for this is that ATSD registers belong to a physical NPU
so they cannot invalidate translations on GPUs attached to another NPU.
It is guaranteed by the host platform as it does not mix NVLink bridges
or GPUs from different NPU in the same IOMMU group. If more than one
IOMMU group is detected on a vPHB, this disables ATSD support for that
vPHB and prints a warning.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
[aw: for vfio portions]
Acked-by: Alex Williamson <alex.williamson@redhat.com>
Message-Id: <20190312082103.130561-1-aik@ozlabs.ru>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
build and capture platform firmware binaries from that release. The
binaries are meant to be used by both end-users and by the "BIOS tables"
unit tests in qtest ("make check").
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABCAAGBQJcvgXYAAoJENOdpx4NSWz6tZMP/jHBTOmKfQhBOupSHl5QUN4/
3NFzyIjZht2Pdn5ckAI7VbWzYqNFnI8C/Ffvs+WGc9+uUj930zR1UaWGWZ+Cpr/Z
DQlKBfGL1BTfyPGZFlJ6alDHV9Ka9RsSyIADsQkAoYsaR5Q+hOrT8YmMsCf6/94I
3wnQQZpIOUTG1PuwQiezvrb4dwdXbSQpMNeirza2ftcDya3ctu7bIfuBj9dCD6xb
dcIMKDBLO047c97ILVQC5rvonk3BZmGi9iY6Wp7uiUoZc4lcVIvqBHYPpOaJj3Ws
x2c+OyVriTMdYEtS7eqWkwu6yhf4ts5L5AdNtE1p3hlPAdJiZ1j5T/y70MD15cQO
UGztNoSekeZRGngLZzOsE9ZfMbGMwYnFgx6MPjJHun2rrYSoHtiaQR5OeV2PIGth
Wk/MRub901B8qqbPCeatdSiIyyzBav/NjA49hUA0HJ4QarbEN+BviALGMZf7wXLL
YRvFCqDfvOEzFjqFTDhv/BwmcbgT68pAjE3vUKplyKisVb4o01aYZ6CNQAYWLnKc
ndVHyapbhe5ZF7JY29D0oWfmu0UYRxyfTyS9AY+D0J+FoJgi927uC9jZk3qpze5i
lljnH5C7iF974YeLB75xsdPfnsARSSC8kehCFFBVWqAa/ZsLR0PEZCUnwyf+QTvk
pej6tCtrEFTwhPcfbvnc
=k5c2
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/lersek/tags/edk2-pull-2019-04-22' into staging
Advance the roms/edk2 submodule to the "edk2-stable201903" release, and
build and capture platform firmware binaries from that release. The
binaries are meant to be used by both end-users and by the "BIOS tables"
unit tests in qtest ("make check").
# gpg: Signature made Mon 22 Apr 2019 19:20:08 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-04-22:
MAINTAINERS: add the "EDK2 Firmware" subsystem
Makefile: install the edk2 firmware images and their descriptors
tests: add missing dependency to build QTEST_QEMU_BINARY, round 2
pc-bios: document the edk2 firmware images; add firmware descriptors
pc-bios: add edk2 firmware binaries and variable store templates
roms: build edk2 firmware binaries and variable store templates
roms/Makefile: replace the $(EDK2_EFIROM) target with "edk2-basetools"
roms/edk2-funcs.sh: add the qemu_edk2_get_thread_count() function
roms/edk2: advance to tag edk2-stable201903
tests/uefi-test-tools/build.sh: work around TianoCore#1607
roms/edk2-funcs.sh: require gcc-4.8+ for building i386 and x86_64
roms: lift "edk2-funcs.sh" from "tests/uefi-test-tools/build.sh"
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJcuODJAAoJEDhwtADrkYZT/lkP/3qJSysT3ZD5Aa9PvEQmor+e
1N8Q37EbCug0Jl3tSmUGw6g5R8qZdX8UJEJRaGbtPE6sbjGpedalhu/3O8jKWVDg
Vv+nrB4M6UAyk2LsjiA1p9eDc8flnGKvbGBjpOEEn7FlSfkWgz2l/6oFV8bm3r8h
TxpnlD50yBRxzr8aC6lXc80kKJhnXWCh4m2yq06qZgnilQS8OBnTMZoqr9L4wir4
O/4OfmZfdDPYgMZb8vnxk4JEyVk2yAbjezR6uB1gcR5Pdv05v6UtunQrJAQDwaW+
q0OVOTj9njArlIdu/jTfhFOlQRv7ti9vMlmQ9QxiicfbL4aX0v2chZHsif6PH+0f
kB1yLP+MDQMMS5MiFecCxIHpR7IrwfkC9AfOLp8xw+dRvb4ePJNDKD5a2+UymxbM
wEtnVAUXC1cCdV87jSTXEShTp2glPJc0rxIpPYX5ESjJyoTdVnEwQRaD1WkVTzgD
GciF6UtPZJNBEvTta+GeyPAmPnsuibpHmyIPeL5HrpgEV68b4Ds6BRVwbsrq0U6g
fbbVGZSej6OrMCVHXY1NmrBaNFz9/5RKvi9m+Bmhx5W2K8lU9cxmdrKNKYuGsEly
Ju6+SR6oi15P4ntM2lkywbaA+m8FV04eRh4xRcbWV9ac9M6V6phFvM4ECl3RaA0h
25TGutCc9N1AXHUyTMGH
=kfAU
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/armbru/tags/pull-error-monitor-2019-04-18' into staging
Error reporting & monitor patches for 2019-04-18
# gpg: Signature made Thu 18 Apr 2019 21:40:41 BST
# gpg: using RSA key 3870B400EB918653
# gpg: Good signature from "Markus Armbruster <armbru@redhat.com>" [full]
# gpg: aka "Markus Armbruster <armbru@pond.sub.org>" [full]
# Primary key fingerprint: 354B C8B3 D7EB 2A6B 6867 4E5F 3870 B400 EB91 8653
* remotes/armbru/tags/pull-error-monitor-2019-04-18: (36 commits)
include: Move fprintf_function to disas/
disas: Rename include/disas/bfd.h back to include/disas/dis-asm.h
monitor: Clean up how monitor_disas() funnels output to monitor
qom/cpu: Simplify how CPUClass:cpu_dump_state() prints
qemu-print: New qemu_fprintf(), qemu_vfprintf()
qom/cpu: Simplify how CPUClass::dump_statistics() prints
target/i386: Simplify how x86_cpu_dump_local_apic_state() prints
target: Clean up how the dump_mmu() print
target: Simplify how the TARGET_cpu_list() print
memory: Clean up how mtree_info() prints
block/qapi: Clean up how we print to monitor or stdout
qsp: Simplify how qsp_report() prints
tcg: Simplify how dump_drift_info() prints
tcg: Simplify how dump_exec_info() prints
tcg: Simplify how dump_opcount_info() prints
trace: Simplify how st_print_trace_file_status() prints
include: Include fprintf-fn.h only where needed
monitor: Simplify how -device/device_add print help
char-pty: Print "char device redirected" message to stdout
char: Make -chardev help print to stdout
...
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The previous commits have eliminated fprintf_function outside
disassemblers, simplifying code and cleaning up the ugly type-punning
fprintf_function seems to attract. Move fprintf_function to
include/disas/dis-asm.h to reduce the temptation to abuse it.
I considered renaming it to fprintf_ftype (reverting that part of
commit 6e2d864edf, v0.14.0) to get us closer to binutils, but I
figure the fork is too distant to make this worthwhile.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Message-Id: <20190417191805.28198-18-armbru@redhat.com>
Commit dc99065b5f (v0.1.0) added dis-asm.h from binutils.
Commit 43d4145a98 (v0.1.5) inlined bfd.h into dis-asm.h to remove the
dependency on binutils.
Commit 76cad71136 (v1.4.0) moved dis-asm.h to include/disas/bfd.h.
The new name is confusing when you try to match against (pre GPLv3+)
binutils. Rename it back. Keep it in the same directory, of course.
Cc: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20190417191805.28198-17-armbru@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
INIT_DISASSEMBLE_INFO() takes an fprintf()-like callback and a FILE *
to pass to it. monitor_disas() passes monitor_fprintf() and the
current monitor cast to FILE *. monitor_fprintf() casts it right
back, and is otherwise identical to monitor_printf(). The
type-punning is ugly.
Pass qemu_fprintf() and NULL instead.
monitor_fprintf() is now unused; delete it.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Message-Id: <20190417191805.28198-16-armbru@redhat.com>
[Commit message typo corrected]
CPUClass method dump_statistics() takes an fprintf()-like callback and
a FILE * to pass to it. Most callers pass fprintf() and stderr.
log_cpu_state() passes fprintf() and qemu_log_file.
hmp_info_registers() passes monitor_fprintf() and the current monitor
cast to FILE *. monitor_fprintf() casts it right back, and is
otherwise identical to monitor_printf().
The callback gets passed around a lot, which is tiresome. The
type-punning around monitor_fprintf() is ugly.
Drop the callback, and call qemu_fprintf() instead. Also gets rid of
the type-punning, since qemu_fprintf() takes NULL instead of the
current monitor cast to FILE *.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Message-Id: <20190417191805.28198-15-armbru@redhat.com>
Code that doesn't want to know about current monitor vs. stdout
vs. stderr takes an fprintf_function callback and a FILE * argument to
pass to it. Actual arguments are either fprintf() and stdout or
stderr, or monitor_fprintf() and the current monitor cast to FILE *.
monitor_fprintf() casts it right back, and is otherwise identical to
monitor_printf(). The type-punning is ugly.
New qemu_fprintf() and qemu_vprintf() address this need without type
punning: they are like fprintf() and vfprintf(), except they print to
the current monitor when passed a null FILE *. The next commits will
put them to use.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Message-Id: <20190417191805.28198-14-armbru@redhat.com>
CPUClass method dump_statistics() takes an fprintf()-like callback and
a FILE * to pass to it.
Its only caller hmp_info_cpustats() (via cpu_dump_statistics()) passes
monitor_fprintf() and the current monitor cast to FILE *.
monitor_fprintf() casts it right back, and is otherwise identical to
monitor_printf(). The type-punning is ugly.
Drop the callback, and call qemu_printf() instead.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Message-Id: <20190417191805.28198-13-armbru@redhat.com>
x86_cpu_dump_local_apic_state() takes an fprintf()-like callback and a
FILE * to pass to it, and so do its helper functions.
Its only caller hmp_info_local_apic() passes monitor_fprintf() and the
current monitor cast to FILE *. monitor_fprintf() casts it right
back, and is otherwise identical to monitor_printf(). The
type-punning is ugly.
Drop the callback, and call qemu_printf() instead.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Message-Id: <20190417191805.28198-12-armbru@redhat.com>
The various dump_mmu() take an fprintf()-like callback and a FILE * to
pass to it, and so do their helper functions. Passing around callback
and argument is rather tiresome.
Most dump_mmu() are called only by the target's hmp_info_tlb(). These
all pass monitor_printf() cast to fprintf_function and the current
monitor cast to FILE *.
SPARC's dump_mmu() gets also called from target/sparc/ldst_helper.c a
few times #ifdef DEBUG_MMU. These calls pass fprintf() and stdout.
The type-punning is technically undefined behaviour, but works in
practice. Clean up: drop the callback, and call qemu_printf()
instead.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Message-Id: <20190417191805.28198-11-armbru@redhat.com>
The various TARGET_cpu_list() take an fprintf()-like callback and a
FILE * to pass to it. Their callers (vl.c's main() via list_cpus(),
bsd-user/main.c's main(), linux-user/main.c's main()) all pass
fprintf() and stdout. Thus, the flexibility provided by the (rather
tiresome) indirection isn't actually used.
Drop the callback, and call qemu_printf() instead.
Calling printf() would also work, but would make the code unsuitable
for monitor context without making it simpler.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20190417191805.28198-10-armbru@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
mtree_info() takes an fprintf()-like callback and a FILE * to pass to
it, and so do its helper functions. Passing around callback and
argument is rather tiresome.
Its only caller hmp_info_mtree() passes monitor_printf() cast to
fprintf_function and the current monitor cast to FILE *.
The type-punning is technically undefined behaviour, but works in
practice. Clean up: drop the callback, and call qemu_printf()
instead.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Message-Id: <20190417191805.28198-9-armbru@redhat.com>
bdrv_snapshot_dump(), bdrv_image_info_specific_dump(),
bdrv_image_info_dump() and their helpers take an fprintf()-like
callback and a FILE * to pass to it.
hmp.c passes monitor_printf() cast to fprintf_function and the current
monitor cast to FILE *.
qemu-img.c and qemu-io-cmds.c pass fprintf and stdout.
The type-punning is technically undefined behaviour, but works in
practice. Clean up: drop the callback, and call qemu_printf()
instead.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Message-Id: <20190417191805.28198-8-armbru@redhat.com>
