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.
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.
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.
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.
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) <[email protected]>"
# gpg: aka "Edgar E. Iglesias <[email protected]>"
# 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
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
...
Create a cpu_loop-common.h for future use by
these new files and use it in the existing
main.c
Introduce target_cpu_copy_regs():
declare the function in cpu_loop-common.h
and an empty function for each target,
to move all the cpu_loop prologues to this function.
Instead of calling setup_frame() conditionally to a list of known targets,
define TARGET_ARCH_HAS_SETUP_FRAME if the target provides the function
and call it only if the macro is defined.
Move declarations of setup_frame() and setup_rt_frame() to
linux-user/signal-common.h
Peter Maydell [Thu, 19 Apr 2018 12:57:40 +0000 (13:57 +0100)]
linux-user: Fix getdents emulation for 64 bit guest on 32 bit host
Currently we mishandle emulation of the getdents syscall for the
case of a 64 bit guest on a 32 bit host -- it defaults into
the 'host and guest same size' codepath and generates incorrect
structures in the guest buffer.
We can't easily handle the 64-on-32 case using the host getdents
syscall, because the guest struct dirent is bigger than the
host struct dirent, and we might find the host syscall has handed
us back more records than we can fit in the guest buffer after
conversion. Instead, always emulate 64-on-32 getdents with
the host getdents64. This avoids the buffer-overrun problem
because a dirent64 struct is always the same size on any host
and always larger than any architecture's dirent struct.
Alex Bennée [Wed, 25 Apr 2018 10:02:18 +0000 (11:02 +0100)]
linux-user: set minimum uname for RISC-V
As support for RISC-V was only merged into the mainline kernel at 4.15
it is unlikely that glibc will be happy with a reported kernel version
of 3.8.0. Indeed when I testing binaries created by the current Debian
Sid compiler the tests failed with:
FATAL: kernel too old
Bump the version to the minimum a RISC-V glibc would expect:
* remotes/kraxel/tags/usb-20180427-pull-request:
ccid-card: include libcacard.h only
Fix libusb-1.0.22 deprecated libusb_set_debug with libusb_set_option
ccid: Fix dwProtocols advertisement of T=0
Peter Maydell [Fri, 27 Apr 2018 09:49:23 +0000 (10:49 +0100)]
Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-2.13-20180427' into staging
ppc patch queue 2018-04-27
Here's the first batch of ppc patches for 2.13. This has a lot of
stuff that's accumulated during the 2.12 freeze. Highlights are:
* Many improvements for the Uninorth PCI host bridge for Mac
machine types
* Preliminary helpers improve handling of multiple backing
pagesizes (not strictly ppc related, but have acks and aimed to
allow future ppc changes)
* Cleanups to pseries cpu initialization
* Cleanups to hash64 MMU handling
* Assorted bugfixes and improvements
* remotes/dgibson/tags/ppc-for-2.13-20180427: (49 commits)
Clear mem_path if we fall back to anonymous RAM allocation
spapr: Set compatibility mode before the rest of spapr_cpu_reset()
target/ppc: Don't bother with MSR_EP in cpu_ppc_set_papr()
spapr: Support ibm,dynamic-memory-v2 property
ppc: e500: switch E500 based machines to full machine definition
spapr: Add ibm,max-associativity-domains property
target/ppc: Fold slb_nr into PPCHash64Options
target/ppc: Get rid of POWERPC_MMU_VER() macros
target/ppc: Remove unnecessary POWERPC_MMU_V3 flag from mmu_model
target/ppc: Fold ci_large_pages flag into PPCHash64Options
target/ppc: Move 1T segment and AMR options to PPCHash64Options
target/ppc: Make hash64_opts field mandatory for 64-bit hash MMUs
target/ppc: Split page size information into a separate allocation
target/ppc: Move page size setup to helper function
target/ppc: Remove fallback 64k pagesize information
target/ppc: Avoid taking "env" parameter to mmu-hash64 functions
target/ppc: Pass cpu instead of env to ppc_create_page_sizes_prop()
target/ppc: Simplify cpu valid check in ppc_cpu_realize
target/ppc: Standardize instance_init and realize function names
spapr: drop useless dynamic sysbus device sanity check
...
Tina Zhang [Fri, 27 Apr 2018 09:11:06 +0000 (17:11 +0800)]
ui: introduce vfio_display_reset
During guest OS reboot, guest framebuffer is invalid. It will cause
bugs, if the invalid guest framebuffer is still used by host.
This patch is to introduce vfio_display_reset which is invoked
during vfio display reset. This vfio_display_reset function is used
to release the invalid display resource, disable scanout mode and
replace the invalid surface with QemuConsole's DisplaySurafce.
This patch can fix the GPU hang issue caused by gd_egl_draw during
guest OS reboot.
Changes v3->v4:
- Move dma-buf based display check into the vfio_display_reset().
(Gerd)
Changes v2->v3:
- Limit vfio_display_reset to dma-buf based vfio display. (Gerd)
Changes v1->v2:
- Use dpy_gfx_update_full() update screen after reset. (Gerd)
- Remove dpy_gfx_switch_surface(). (Gerd)
When trying to build with latest libcacard-2.5.1, I hit the
following error:
In file included from hw/usb/ccid-card-passthru.c:12:0:
/usr/include/cacard/vscard_common.h:26:2: error: #warning "Only <libcacard.h> can be included directly" [-Werror=cpp]
#warning "Only <libcacard.h> can be included directly"
While it was fixed in libcacard upstream (so that individual
files can be included directly), it doesn't make much sense.
Let's switch to including the main libcacard.h and also require
at least libcacard-2.5.1 which introduced it. It's available
since late 2015.
CC hw/usb/host-libusb.o
/builds/xen/src/qemu-xen/hw/usb/host-libusb.c: In function 'usb_host_init':
/builds/xen/src/qemu-xen/hw/usb/host-libusb.c:250:5: error: 'libusb_set_debug' is deprecated: Use libusb_set_option instead [-Werror=deprecated-declarations]
libusb_set_debug(ctx, loglevel);
^~~~~~~~~~~~~~~~
In file included from /builds/xen/src/qemu-xen/hw/usb/host-libusb.c:40:0:
/usr/include/libusb-1.0/libusb.h:1300:18: note: declared here
void LIBUSB_CALL libusb_set_debug(libusb_context *ctx, int level);
^~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
make: *** [/builds/xen/src/qemu-xen/rules.mak:66: hw/usb/host-libusb.o] Error 1
make: Leaving directory '/builds/xen/src/xen/tools/qemu-xen-build'
Jason Andryuk [Fri, 20 Apr 2018 18:32:19 +0000 (14:32 -0400)]
ccid: Fix dwProtocols advertisement of T=0
Commit d7d218ef02d87c637d20d64da8f575d434ff6f78 attempted to change
dwProtocols to only advertise support for T=0 and not T=1. The change
was incorrect as it changed 0x00000003 to 0x00010000.
lsusb -v in a linux guest shows:
"dwProtocols 65536 (Invalid values detected)", though the
smart card could still be accessed. Windows 7 does not detect inserted
smart cards and logs the the following Error in the Event Logs:
Source: Smart Card Service
Event ID: 610
Smart Card Reader 'QEMU QEMU USB CCID 0' rejected IOCTL SET_PROTOCOL:
Incorrect function. If this error persists, your smart card or reader
may not be functioning correctly
David Gibson [Thu, 19 Apr 2018 07:19:11 +0000 (17:19 +1000)]
Clear mem_path if we fall back to anonymous RAM allocation
If the -mem-path option is set, we attempt to map the guest's RAM from a
file in the given path; it's usually used to back guest RAM with hugepages.
If we're unable to (e.g. not enough free hugepages) then we fall back to
allocating normal anonymous pages. This behaviour can be surprising, but a
comment in allocate_system_memory_nonnuma() suggests it's legacy behaviour
we can't change.
What really isn't ok, though, is that in this case we leave mem_path set.
That means functions which attempt to determine the pagesize of main RAM
can erroneously think it is hugepage based on the requested path, even
though it's not.
This is particular bad for the pseries machine type. KVM HV limitations
mean the guest can't use pagesizes larger than the host page size used to
back RAM. That means that such a fallback, rather than merely giving
poorer performance than expected will cause the guest to freeze up early in
boot as it attempts to use large page mappings that can't work.
This patch addresses the problem by clearing the mem_path variable when we
fall back to anonymous pages, meaning that subsequent attempts to
determine the RAM page size will get an accurate result.
David Gibson [Thu, 5 Apr 2018 05:49:23 +0000 (15:49 +1000)]
spapr: Set compatibility mode before the rest of spapr_cpu_reset()
Although the order doesn't really matter at the moment, it's possible
other initializastions could depend on the compatiblity mode, so make sure
we set it first in spapr_cpu_reset().
While we're at it drop the test against first_cpu. Setting the compat mode
to the value it already has is redundant, but harmless, so we might as well
make a small simplification to the code.
David Gibson [Fri, 13 Apr 2018 04:54:34 +0000 (14:54 +1000)]
target/ppc: Don't bother with MSR_EP in cpu_ppc_set_papr()
cpu_ppc_set_papr() removes the EP and HV bits from the MSR mask. While
removing the HV bit makes sense (a cpu in PAPR mode should never be
emulated in hypervisor mode), the EP bit is just bizarre. Although it's
true that a papr mode guest shouldn't be able to change the exception
prefix, the MSR[EP] bit doesn't even exist on the cpus supported for PAPR
mode, so it's pointless to do anything with it here.
Igor Mammedov [Wed, 18 Apr 2018 14:28:02 +0000 (16:28 +0200)]
ppc: e500: switch E500 based machines to full machine definition
Convert PPCE500Params to PCCE500MachineClass which it essentially is,
and introduce PCCE500MachineState to keep track of E500 specific
state instead of adding global variables or extra parameters to
functions when we need to keep data beyond machine init
(i.e. make it look like typical fully defined machine).
It's pretty shallow conversion instead of currently used trivial
DEFINE_MACHINE() macro. It adds extra 60LOC of boilerplate code
of full machine definition.
The patch on top[1] will use PCCE500MachineState to keep track of
platform_bus device and add E500Plate specific machine class
to use HOTPLUG_HANDLER for explicitly initializing dynamic
sysbus devices at the time they are added instead of delaying
it to machine done time by platform_bus_init_notify() which is
being removed.
Now recent kernels (i.e. since linux-stable commit a346137e9142
("powerpc/numa: Use ibm,max-associativity-domains to discover possible nodes")
support this property to mark initially memory-less NUMA nodes as "possible"
to allow further memory hot-add to them.
Advertise this property for pSeries machines to let guest kernels detect
maximum supported node configuration and benefit from kernel side change
when hot-add memory to specific, possibly empty before, NUMA node.
David Gibson [Thu, 29 Mar 2018 07:29:38 +0000 (18:29 +1100)]
target/ppc: Fold slb_nr into PPCHash64Options
The env->slb_nr field gives the size of the SLB (Segment Lookaside Buffer).
This is another static-after-initialization parameter of the specific
version of the 64-bit hash MMU in the CPU. So, this patch folds the field
into PPCHash64Options with the other hash MMU options.
This is a bit more complicated that the things previously put in there,
because slb_nr was foolishly included in the migration stream. So we need
some of the usual dance to handle backwards compatible migration.
David Gibson [Fri, 23 Mar 2018 05:48:43 +0000 (16:48 +1100)]
target/ppc: Get rid of POWERPC_MMU_VER() macros
These macros were introduced to deal with the fact that the mmu_model
field has bit flags mixed in with what's otherwise an enum of various mmu
types.
We've now eliminated all those flags except for one, and that one -
POWERPC_MMU_64 - is already included/compared in the MMU_VER macros. So,
we can get rid of those macros and just directly compare mmu_model values
in the places it was used.
David Gibson [Fri, 23 Mar 2018 05:42:45 +0000 (16:42 +1100)]
target/ppc: Remove unnecessary POWERPC_MMU_V3 flag from mmu_model
The only place we test this flag is in conjunction with
ppc64_use_proc_tbl(). That checks for the LPCR_UPRT bit, which we already
ensure can't be set except on a machine with a v3 MMU (i.e. POWER9).
David Gibson [Fri, 23 Mar 2018 03:32:48 +0000 (14:32 +1100)]
target/ppc: Fold ci_large_pages flag into PPCHash64Options
The ci_large_pages boolean in CPUPPCState is only relevant to 64-bit hash
MMU machines, indicating whether it's possible to map large (> 4kiB) pages
as cache-inhibitied (i.e. for IO, rather than memory). Fold it as another
flag into the PPCHash64Options structure.
David Gibson [Fri, 23 Mar 2018 03:11:07 +0000 (14:11 +1100)]
target/ppc: Move 1T segment and AMR options to PPCHash64Options
Currently env->mmu_model is a bit of an unholy mess of an enum of distinct
MMU types, with various flag bits as well. This makes which bits of the
field should be compared pretty confusing.
Make a start on cleaning that up by moving two of the flags bits -
POWERPC_MMU_1TSEG and POWERPC_MMU_AMR - which are specific to the 64-bit
hash MMU into a new flags field in PPCHash64Options structure.
David Gibson [Fri, 23 Mar 2018 02:59:20 +0000 (13:59 +1100)]
target/ppc: Make hash64_opts field mandatory for 64-bit hash MMUs
Currently some cpus set the hash64_opts field in the class structure, with
specific details of their variant of the 64-bit hash mmu. For the
remaining cpus with that mmu, ppc_hash64_realize() fills in defaults.
But there are only a couple of cpus that use those fallbacks, so just have
them to set the has64_opts field instead, simplifying the logic.
David Gibson [Fri, 23 Mar 2018 02:31:52 +0000 (13:31 +1100)]
target/ppc: Split page size information into a separate allocation
env->sps contains page size encoding information as an embedded structure.
Since this information is specific to 64-bit hash MMUs, split it out into
a separately allocated structure, to reduce the basic env size for other
cpus. Along the way we make a few other cleanups:
* Rename to PPCHash64Options which is more in line with qemu name
conventions, and reflects that we're going to merge some more hash64
mmu specific details in there in future. Also rename its
substructures to match qemu conventions.
* Move structure definitions to the mmu-hash64.[ch] files.
David Gibson [Fri, 23 Mar 2018 02:07:48 +0000 (13:07 +1100)]
target/ppc: Move page size setup to helper function
Initialization of the env->sps structure at the end of instance_init is
specific to the 64-bit hash MMU, so move the code into a helper function
in mmu-hash64.c.
We also create a corresponding function to be called at finalize time -
it's empty for now, but we'll need it shortly.
David Gibson [Fri, 23 Mar 2018 00:24:28 +0000 (11:24 +1100)]
target/ppc: Remove fallback 64k pagesize information
CPU definitions for cpus with the 64-bit hash MMU can include a table of
available pagesizes. If this isn't supplied ppc_cpu_instance_init() will
fill it in a fallback table based on the POWERPC_MMU_64K bit in mmu_model.
However, it turns out all the cpus which support 64K pages already include
an explicit table of page sizes, so there's no point to the fallback table
including 64k pages.
That removes the only place which tests POWERPC_MMU_64K, so we can remove
it. Which in turn allows some logic to be removed from
kvm_fixup_page_sizes().
David Gibson [Thu, 22 Mar 2018 05:49:28 +0000 (16:49 +1100)]
target/ppc: Avoid taking "env" parameter to mmu-hash64 functions
In most cases we prefer to pass a PowerPCCPU rather than the (embedded)
CPUPPCState.
For ppc_hash64_update_{rmls,vrma}() change to take "cpu" instead of "env".
For ppc_hash64_set_{dsi,isi}() remove the redundant "env" parameter.
In theory this makes more work for the functions, but since "cs", "cpu"
and "env" are related by at most constant offsets, the compiler should be
able to optimize out the difference at effectively zero cost.
helper_*() functions are left alone - since they're more closely tied to
the TCG generated code, passing "env" is still the standard there.
David Gibson [Fri, 23 Mar 2018 01:55:04 +0000 (12:55 +1100)]
target/ppc: Simplify cpu valid check in ppc_cpu_realize
The #if isn't necessary, because there's a suitable one inside
ppc_cpu_is_valid(). We've already filtered for suitable cpu models in the
functions that search and register them. So by the time we get to realize
having an invalid one indicates a code error, not a user error, so an
assert() is more appropriate than error_setg().
David Gibson [Wed, 21 Mar 2018 04:30:13 +0000 (15:30 +1100)]
target/ppc: Standardize instance_init and realize function names
Because of the various hooks called some variant on "init" - and the rather
greater number that used to exist, I'm always wondering when a function
called simply "*_init" or "*_initfn" will be called.
To make it easier on myself, and maybe others, rename the instance_init
hooks for ppc cpus to *_instance_init(). While we're at it rename the
realize time hooks to *_realize() (from *_realizefn()) which seems to be
the more common current convention.
Greg Kurz [Wed, 11 Apr 2018 15:01:20 +0000 (17:01 +0200)]
spapr: drop useless dynamic sysbus device sanity check
Since commit 7da79a167aa11, the machine class init function registers
dynamic sysbus device types it supports. Passing an unsupported device
type on the command line causes QEMU to exit with an error message
just after machine init.
It is hence not needed to do the same sanity check at machine reset.
Leave change @node type from uint32_t to to int from reverted commit
because node < 0 is always false.
Note that implementing capability or some trick to detect if guest
kernel does not support hot-add to memory: this returns previous
behavour where memory added to first non-empty node.
David Gibson [Tue, 3 Apr 2018 05:05:45 +0000 (15:05 +1000)]
Add host_memory_backend_pagesize() helper
There are a couple places (one generic, one target specific) where we need
to get the host page size associated with a particular memory backend. I
have some upcoming code which will add another place which wants this. So,
for convenience, add a helper function to calculate this.
host_memory_backend_pagesize() returns the host pagesize for a given
HostMemoryBackend object.
David Gibson [Tue, 3 Apr 2018 04:55:11 +0000 (14:55 +1000)]
Make qemu_mempath_getpagesize() accept NULL
qemu_mempath_getpagesize() gets the effective (host side) page size for
a block of memory backed by an mmap()ed file on the host. It requires
the mem_path parameter to be non-NULL.
This ends up meaning all the callers need a different case for handling
anonymous memory (for memory-backend-ram or default memory with -mem-path
is not specified).
We can make all those callers a little simpler by having
qemu_mempath_getpagesize() accept NULL, and treat that as the anonymous
memory case.