David Gibson [Wed, 6 Mar 2019 03:15:26 +0000 (14:15 +1100)]
spapr: Force SPAPR_MEMORY_BLOCK_SIZE to be a hwaddr (64-bit)
SPAPR_MEMORY_BLOCK_SIZE is logically a difference in memory addresses, and
hence of type hwaddr which is 64-bit. Previously it wasn't marked as such
which means that it could be treated as 32-bit. That will work in some
circumstances but if multiplied by another 32-bit value it could lead to
a 32-bit overflow and an incorrect result.
One specific instance of this in spapr_lmb_dt_populate() was spotted by
Coverity (CID 1399145).
target/ppc/spapr: Clear partition table entry when allocating hash table
If we allocate a hash page table then we know that the guest won't be
using process tables, so set the partition table entry maintained for
the guest to zero. If this isn't done, then the guest radix bit will
remain set in the entry. This means that when the guest calls
H_REGISTER_PROCESS_TABLE there will be a mismatch between then flags
and the value in spapr->patb_entry, and the call will fail. The guest
will then panic:
Failed to register process table (rc=-4)
kernel BUG at arch/powerpc/platforms/pseries/lpar.c:959
The result being that it isn't possible to boot a hash guest on a P9
system.
Also fix a bug in the flags parsing in h_register_process_table() which
was introduced by the same patch, and simplify the handling to make it
less likely that errors will be introduced in the future. The effect
would have been setting the host radix bit LPCR_HR for a hash guest
using process tables, which currently isn't supported and so couldn't
have been triggered.
Alexander Graf [Mon, 4 Mar 2019 10:39:30 +0000 (11:39 +0100)]
PPC: E500: Update u-boot to v2019.01
Quite a while has passed since we last updated U-Boot for e500. This patch
bumps it to the last released version 2019.01 to make sure users don't feel
like they're using out of date software.
Fabiano Rosas [Thu, 28 Feb 2019 22:57:58 +0000 (19:57 -0300)]
target/ppc: Refactor kvm_handle_debug
There are four scenarios being handled in this function:
- single stepping
- hardware breakpoints
- software breakpoints
- fallback (no debug supported)
A future patch will add code to handle specific single step and
software breakpoints cases so let's split each scenario into its own
function now to avoid hurting readability.
target/ppc/spapr: Enable mitigations by default for pseries-4.0 machine type
There are currently 3 mitigations the availability of which is controlled
by the spapr-caps mechanism, cap-cfpc, cap-sbbc, and cap-ibs. Enable these
mitigations by default for the pseries-4.0 machine type.
By now machine firmware should have been upgraded to allow these
settings.
target/ppc/tcg: make spapr_caps apply cap-[cfpc/sbbc/ibs] non-fatal for tcg
The spapr_caps cap-cfpc, cap-sbbc and cap-ibs are used to control the
availability of certain mitigations to the guest. These haven't been
implemented under TCG, it is unlikely they ever will be, and it is unclear
as to whether they even need to be.
As such, make failure to apply these capabilities under TCG non-fatal.
Instead we print a warning message to the user but still allow the guest
to continue.
Introduce a new spapr_cap SPAPR_CAP_CCF_ASSIST to be used to indicate
the requirement for a hw-assisted version of the count cache flush
workaround.
The count cache flush workaround is a software workaround which can be
used to flush the count cache on context switch. Some revisions of
hardware may have a hardware accelerated flush, in which case the
software flush can be shortened. This cap is used to set the
availability of such hardware acceleration for the count cache flush
routine.
The availability of such hardware acceleration is indicated by the
H_CPU_CHAR_BCCTR_FLUSH_ASSIST flag being set in the characteristics
returned from the KVM_PPC_GET_CPU_CHAR ioctl.
target/ppc/spapr: Add workaround option to SPAPR_CAP_IBS
The spapr_cap SPAPR_CAP_IBS is used to indicate the level of capability
for mitigations for indirect branch speculation. Currently the available
values are broken (default), fixed-ibs (fixed by serialising indirect
branches) and fixed-ccd (fixed by diabling the count cache).
Introduce a new value for this capability denoted workaround, meaning that
software can work around the issue by flushing the count cache on
context switch. This option is available if the hypervisor sets the
H_CPU_BEHAV_FLUSH_COUNT_CACHE flag in the cpu behaviours returned from
the KVM_PPC_GET_CPU_CHAR ioctl.
target/ppc/spapr: Enable the large decrementer for pseries-4.0
Enable the large decrementer by default for the pseries-4.0 machine type.
It is disabled again by default_caps_with_cpu() for pre-POWER9 cpus
since they don't support the large decrementer.
target/ppc: Implement large decrementer support for KVM
Implement support to allow KVM guests to take advantage of the large
decrementer introduced on POWER9 cpus.
To determine if the host can support the requested large decrementer
size, we check it matches that specified in the ibm,dec-bits device-tree
property. We also need to enable it in KVM by setting the LPCR_LD bit in
the LPCR. Note that to do this we need to try and set the bit, then read
it back to check the host allowed us to set it, if so we can use it but
if we were unable to set it the host cannot support it and we must not
use the large decrementer.
target/ppc: Implement large decrementer support for TCG
Prior to POWER9 the decrementer was a 32-bit register which decremented
with each tick of the timebase. From POWER9 onwards the decrementer can
be set to operate in a mode called large decrementer where it acts as a
n-bit decrementing register which is visible as a 64-bit register, that
is the value of the decrementer is sign extended to 64 bits (where n is
implementation dependant).
The mode in which the decrementer operates is controlled by the LPCR_LD
bit in the logical paritition control register (LPCR).
>From POWER9 onwards the HDEC (hypervisor decrementer) was enlarged to
h-bits, also sign extended to 64 bits (where h is implementation
dependant). Note this isn't configurable and is always enabled.
On POWER9 the large decrementer and hdec are both 56 bits, as
represented by the lrg_decr_bits cpu class property. Since they are the
same size we only add one property for now, which could be extended in
the case they ever differ in the future.
We also add the lrg_decr_bits property for POWER5+/7/8 since it is used
to determine the size of the hdec, which is only generated on the
POWER5+ processor and later. On these processors it is 32 bits.
Greg Kurz [Fri, 1 Mar 2019 19:32:31 +0000 (20:32 +0100)]
Revert "spapr: support memory unplug for qtest"
Commit b8165118f52c broke CPU hotplug tests for old machine types:
$ QTEST_QEMU_BINARY=ppc64-softmmu/qemu-system-ppc64 ./tests/cpu-plug-test -m=slow
/ppc64/cpu-plug/pseries-3.1/device-add/2x3x1&maxcpus=6: OK
/ppc64/cpu-plug/pseries-2.12-sxxm/device-add/2x3x1&maxcpus=6: OK
/ppc64/cpu-plug/pseries-3.0/device-add/2x3x1&maxcpus=6: OK
/ppc64/cpu-plug/pseries-2.10/device-add/2x3x1&maxcpus=6: OK
/ppc64/cpu-plug/pseries-2.11/device-add/2x3x1&maxcpus=6: OK
/ppc64/cpu-plug/pseries-2.12/device-add/2x3x1&maxcpus=6: OK
/ppc64/cpu-plug/pseries-2.9/device-add/2x3x1&maxcpus=6: OK
/ppc64/cpu-plug/pseries-2.7/device-add/2x3x1&maxcpus=6: **
ERROR:/home/thuth/devel/qemu/hw/ppc/spapr_events.c:313:rtas_event_log_to_source: assertion failed: (source->enabled)
Broken pipe
/home/thuth/devel/qemu/tests/libqtest.c:143: kill_qemu() detected QEMU death from signal 6 (Aborted) (core dumped)
Aborted (core dumped)
The approach of faking the availability of OV5_HP_EVT causes the
code to assume the hotplug event source is enabled, which is wrong
for older machines.
Greg Kurz [Fri, 1 Mar 2019 19:32:37 +0000 (20:32 +0100)]
spapr: Simulate CAS for qtest
The RTAS event hotplug code for machine types 2.8 and newer depends on
the CAS negotiated ov5 in order to work properly. However, there's no
CAS when running under qtest. There has been a tentative to trick the
code by faking the OV5_HP_EVT bit, but it turned out to break other
assumptions in the code and the change got reverted.
Go for a more general approach and simulate a CAS when running under
qtest. For simplicity, this pseudo CAS simple simulates the case where
the guest supports the same features as the machine. It is done at
reset time, just before we reset the DRCs, which could potentially
exercise the unplug code.
This allows to test unplug on spapr with both older and newer machine
types.
The "systempagesize" name suggests that it is the host system page size
while it is the smallest page size of memory backing the guest RAM so
let's rename it to stop confusion. This should cause no behavioral change.
The current code assumes that we can address more bits on a PCI bus
for DMA than we really can but there is no way knowing the actual limit.
This makes a better guess for the number of levels and if the kernel
fails to allocate that, this increases the level numbers till succeeded
or reached the 64bit limit.
This adds levels to the trace point.
This may cause the kernel to warn about failed allocation:
[65122.837458] Failed to allocate a TCE memory, level shift=28
which might happen if MAX_ORDER is not large enough as it can vary:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/Kconfig?h=v5.0-rc2#n727
* remotes/bonzini/tags/for-upstream: (31 commits)
qemugdb: fix licensing
chardev: add support for authorization for TLS clients
qom: cpu: destroy work_mutex in cpu_common_finalize
exec.c: refactor function flatview_add_to_dispatch()
lsi: 810/895A are always little endian
lsi: return dfifo value
lsi: use SCSI phase names instead of numbers in trace
lsi: use enum type for s->msg_action
lsi: use enum type for s->waiting
lsi: use ldn_le_p()/stn_le_p()
scsi-disk: Fix crash if request is invaild or disk is no medium
configure: Disable W^X on OpenBSD
oslib-posix: Ignore fcntl("/dev/null", F_SETFL, O_NONBLOCK) failure
accel: Allow to build QEMU without TCG or KVM support
build: clean trace/generated-helpers.c
build: remove unnecessary assignments from Makefile.target
build: get rid of target-obj-y
update copyright notice
lsi: check if SIGP bit is already set in Wait reselect
lsi: implement basic SBCL functionality
...
Peter Maydell [Mon, 11 Mar 2019 17:16:38 +0000 (17:16 +0000)]
Merge remote-tracking branch 'remotes/amarkovic/tags/mips-queue-mar-11-2019' into staging
MIPS queue for March 11th, 2019
# gpg: Signature made Mon 11 Mar 2019 14:16:09 GMT
# gpg: using RSA key D4972A8967F75A65
# gpg: Good signature from "Aleksandar Markovic <[email protected]>" [unknown]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 8526 FBF1 5DA3 811F 4A01 DD75 D497 2A89 67F7 5A65
* remotes/amarkovic/tags/mips-queue-mar-11-2019:
target/mips: Add tests for a variety of MSA integer subtract instructions
target/mips: Add tests for a variety of MSA integer multiply instructions
target/mips: Add tests for a variety of MSA integer dot product instructions
target/mips: Add tests for a variety of MSA integer divide instructions
target/mips: Add tests for a variety of MSA integer average instructions
tests/tcg: target/mips: Rename two header files for consistency
tests/tcg: target/mips: Correct preambles of test source files
chardev: add support for authorization for TLS clients
Currently any client which can complete the TLS handshake is able to use
a chardev server. The server admin can turn on the 'verify-peer' option
for the x509 creds to require the client to provide a x509
certificate. This means the client will have to acquire a certificate
from the CA before they are permitted to use the chardev server. This is
still a fairly low bar.
This adds a 'tls-authz=OBJECT-ID' option to the socket chardev backend
which takes the ID of a previously added 'QAuthZ' object instance. This
will be used to validate the client's x509 distinguished name. Clients
failing the check will not be permitted to use the chardev server.
For example to setup authorization that only allows connection from a
client whose x509 certificate distinguished name contains 'CN=fred', you
would use:
Li Qiang [Wed, 2 Jan 2019 07:41:14 +0000 (23:41 -0800)]
qom: cpu: destroy work_mutex in cpu_common_finalize
Commit 376692b9dc6(cpus: protect work list with work_mutex)
initialize a work_mutex in cpu_common_initfn, however forget
to destroy it. This will cause resource leak when hotunplug cpu
or hotplug cpu fails.
Wei Yang [Mon, 11 Mar 2019 05:42:52 +0000 (13:42 +0800)]
exec.c: refactor function flatview_add_to_dispatch()
flatview_add_to_dispatch() registers page based on the condition of
*section*, which may looks like this:
|s|PPPPPPP|s|
where s stands for subpage and P for page.
The procedure of this function could be described as:
- register first subpage
- register page
- register last subpage
This means the procedure could be simplified into these three steps
instead of a loop iteration.
This patch refactors the function into three corresponding steps and
adds some comment to clarify it.
Signed-off-by: Wei Yang <[email protected]>
Message-Id: <20190311054252[email protected]>
[Paolo: move exit before adjustment of remain.offset_within_*,
otherwise int128_get64 fails when a region is 2^64 bytes long] Signed-off-by: Paolo Bonzini <[email protected]>
Zhengui Li [Thu, 7 Mar 2019 09:12:46 +0000 (17:12 +0800)]
scsi-disk: Fix crash if request is invaild or disk is no medium
Qemu will crash with the assertion error that "assert(r->req.aiocb !=
NULL)" in scsi_read_complete if request is invaild or disk is no medium.
The error is below:
qemu-kvm: hw/scsi/scsi_disk.c:299: scsi_read_complete: Assertion
`r->req.aiocb != NULL' failed.
This patch add a funtion scsi_read_complete_noio to fix it.
Since OpenBSD 6.0 [1], W^X is enforced by default [2].
TCG requires WX access. Disable W^X if it is available.
This fixes:
# lm32-softmmu/qemu-system-lm32
Could not allocate dynamic translator buffer
# sysctl kern.wxabort=1
kern.wxabort: 0 -> 1
# lm32-softmmu/qemu-system-lm32
mmap: Not supported
Abort trap (core dumped)
# gdb -q lm32-softmmu/qemu-system-lm32 qemu-system-lm32.core
(gdb) bt
#0 0x000017e3c156c50a in _thread_sys___syscall () at {standard input}:5
#1 0x000017e3c15e5d7a in *_libc_mmap (addr=Variable "addr" is not available.) at /usr/src/lib/libc/sys/mmap.c:47
#2 0x000017e17d9abc8b in alloc_code_gen_buffer () at /usr/src/qemu/accel/tcg/translate-all.c:1064
#3 0x000017e17d9abd04 in code_gen_alloc (tb_size=0) at /usr/src/qemu/accel/tcg/translate-all.c:1112
#4 0x000017e17d9abe81 in tcg_exec_init (tb_size=0) at /usr/src/qemu/accel/tcg/translate-all.c:1149
#5 0x000017e17d9897e9 in tcg_init (ms=0x17e45e456800) at /usr/src/qemu/accel/tcg/tcg-all.c:66
#6 0x000017e17d9891b8 in accel_init_machine (acc=0x17e3c3f50800, ms=0x17e45e456800) at /usr/src/qemu/accel/accel.c:63
#7 0x000017e17d989312 in configure_accelerator (ms=0x17e45e456800, progname=0x7f7fffff07b0 "lm32-softmmu/qemu-system-lm32") at /usr/src/qemu/accel/accel.c:111
#8 0x000017e17d9d8616 in main (argc=1, argv=0x7f7fffff06b8, envp=0x7f7fffff06c8) at vl.c:4325
Previous to OpenBSD 6.3 [1], fcntl(F_SETFL) is not permitted on
memory devices.
Trying this call sets errno to ENODEV ("not a memory device"):
19 ENODEV Operation not supported by device.
An attempt was made to apply an inappropriate function to a device,
for example, trying to read a write-only device such as a printer.
Do not assert fcntl failures in this specific case (errno set to ENODEV)
on OpenBSD. This fixes:
$ lm32-softmmu/qemu-system-lm32
assertion "f != -1" failed: file "util/oslib-posix.c", line 247, function "qemu_set_nonblock"
Abort trap (core dumped)
[1] The fix seems https://github.com/openbsd/src/commit/c2a35b387f9d3c
"fcntl(F_SETFL) invokes the FIONBIO and FIOASYNC ioctls internally, so
the memory devices (/dev/null, /dev/zero, etc) need to permit them."
Anthony PERARD [Wed, 16 Jan 2019 17:35:27 +0000 (17:35 +0000)]
accel: Allow to build QEMU without TCG or KVM support
Instead of deny build of QEMU without a default accelerator, simply
report an error when the user haven't passed -accel or -machine accel=
and TCG and KVM isn't builtin.
./configure already check that at least one accelerator is available.
Paolo Bonzini [Fri, 15 Feb 2019 09:15:22 +0000 (10:15 +0100)]
build: remove unnecessary assignments from Makefile.target
It is only necessary to clear block-obj-y because Makefile.objs
uses "+=" instead of "="; fix that and remove the assignment.
The other variables need not be cleared at all.
Sven Schnelle [Sun, 17 Feb 2019 11:37:17 +0000 (12:37 +0100)]
lsi: check if SIGP bit is already set in Wait reselect
If SIGP is set, the 'Wait for Reselection' command should jump
immediately to the address stored in the second DWORD of the
instruction. This fixes spurious hangs in the HP-UX 11.11
installer when the SIGP bit gets set by the kernel before the
'Wait for Reselection' command is executed by SCRIPTS.
Sven Schnelle [Fri, 15 Feb 2019 19:40:21 +0000 (20:40 +0100)]
lsi: implement basic SBCL functionality
HP-UX checks this register after sending data to the target. If there's no valid
information present, it assumes the client disconnected because the kernel sent
to much data. Implement at least some of the SBCL functionality that is possible
without having a real SCSI bus.
Greg Kurz [Thu, 28 Feb 2019 17:59:42 +0000 (18:59 +0100)]
virtio-scsi: Fix build with gcc 9
Build fails with gcc 9:
CC ppc64-softmmu/hw/scsi/virtio-scsi.o
hw/scsi/virtio-scsi.c: In function ‘virtio_scsi_do_tmf’:
hw/scsi/virtio-scsi.c:265:39: error: taking address of packed member of ‘struct virtio_scsi_ctrl_tmf_req’ may result in an unaligned pointer value [-Werror=address-of-packed-member]
265 | virtio_tswap32s(VIRTIO_DEVICE(s), &req->req.tmf.subtype);
| ^~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
All the fields in struct virtio_scsi_ctrl_tmf_req are naturally aligned,
so we could in theory drop QEMU_PACKED. Unfortunately, the header file
is imported from linux which already has the packed attribute. Trying to
fix that in the update-linux-headers.sh script is likely to produce
ugliness. Turn the call to virtio_tswap32s() into an assignment instead.
Paolo Bonzini [Thu, 28 Feb 2019 09:23:18 +0000 (10:23 +0100)]
target-i386: add kvm stubs to user-mode emulators
The CPUID code will call kvm_arch_get_supported_cpuid() and, even though
it is undef kvm_enabled() so it never runs for user-mode emulators,
sometimes clang will not optimize it out at -O0.
That could be considered a compiler bug, however at -O0 we give it
a pass and just add the stubs.
The configure script checks multiple times whether it works in a git
repository and it does this by "test -e "${source_path}/.git" in 4 cases
but in one case where it tries to enable werror "-d" is used there which
fails on git worktrees as .git is a file then and not a directory.
This changes the test to "-e" as other occurrences.
Before this patch, if elf2dmp failed to find NT kernel PE magic in
allowed virtual address range, then it assumes NULL as NT kernel
address and cause segfault.
This patch fix the problem described above by checking NT kernel address
before futher processing.
Some Linux specific code is missing guards, leading to
build failure on OSX:
$ sudo brew install libiscsi
$ ./configure && make
[...]
CC block/iscsi.o
qemu/block/iscsi.c:338:24: error: 'iscsi_aiocb_info' defined but not used [-Werror=unused-const-variable=]
static const AIOCBInfo iscsi_aiocb_info = {
^~~~~~~~~~~~~~~~
qemu/block/iscsi.c:168:1: error: 'iscsi_schedule_bh' defined but not used [-Werror=unused-function]
iscsi_schedule_bh(IscsiAIOCB *acb)
^~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
hw/i386/pc: run the multiboot loader before the PVH loader
Some multiboot images could be in the ELF format. In the current
implementation QEMU fails because we try to load these images
as a PVH image.
In order to fix this issue, we should try multiboot first (we
already check the multiboot magic header before to load it).
If it is not a multiboot image, we can try the PVH loader.
Peter Maydell [Fri, 8 Mar 2019 13:57:44 +0000 (13:57 +0000)]
Makefile: Don't install non-sphinx files in sphinx docs install
If we're doing an out-of-tree build of Sphinx, then we
copy some extra spurious files to the install directory
as part of 'make install':
qemu-ga-qapi.texi
qemu-ga-ref.7
qemu-ga-ref.7.pod
qemu-ga-ref.html
qemu-ga-ref.txt
qemu-qmp-qapi.texi
qemu-qmp-ref.7
qemu-qmp-ref.7.pod
qemu-qmp-ref.html
qemu-qmp-ref.txt
because these have been built into build/docs/interop along
with the Sphinx interop documents. Filter them out of the
set of files we install when we're installing the Sphinx-built
manual files. (They are installed into their correct locations
as part of the main install-doc target already.)
Peter Maydell [Fri, 8 Mar 2019 13:57:43 +0000 (13:57 +0000)]
Makefile: Fix 'make distclean'
We forgot the '-r' option on the rm command to clean up the
Sphinx .doctrees working directory, which meant that
"make distclean" fails:
rm: cannot remove '.doctrees': Is a directory
Peter Maydell [Fri, 8 Mar 2019 13:57:42 +0000 (13:57 +0000)]
Makefile: Fix Sphinx documentation builds for in-tree builds
The Sphinx build-sphinx tool does not permit building a manual
into the same directory as its source files. This meant that
commit 5f71eac06e15b9a3fa1134d446f broke QEMU in-source-tree
builds, which would fail with:
Error: source directory and destination directory are same.
Fix this by making in-tree builds build the Sphinx manuals
into a subdirectory of docs/.
Combine all variant in a single handler. As source and destination
have different element sizes, we can't use gvec expansion. Expand
manually. Also watch out for overlapping source and destination
registers. Use a safe evaluation order depending on the operation.
Instead of checking e.g. the first access on every touched page, we should
check the actual access, otherwise we might get false positives when Low
Address Protection (LAP) is active. As probe_write() can only deal with
accesses to one page, we have to loop.
Use i64 for the length, although not needed - easier to reuse
TCG temps we already have in the translation functions where this will
be used. Also allow it to be used from other helpers.
This is a big one. Luckily we only have a limited set of such nasty
instructions.
We'll implement all variants with helpers, except when sources and
the destination don't overlap for VECTOR PACK. Provide different helpers
when the cc is to be modified. We'll return the cc then via env->cc_op.
We cannot use gvec expansion as source and destination elements are
have different element numbers. So we'll expand using a fancy loop.
Also, we have to take care of overlapping source and destination
registers, therefore use a safe evaluation irder depending on the
operation.
s390x/tcg: Implement VECTOR LOAD VR ELEMENT FROM GR
Very similar to VECTOR LOAD GR FROM VR ELEMENT, just the opposite
direction. Also provide a fast path in case we don't care about the
register content.
s390x/tcg: Implement VECTOR LOAD TO BLOCK BOUNDARY
Very similar to LOAD COUNT TO BLOCK BOUNDARY, but instead of only
calculating, the actual vector is loaded. Use a temporary vector to
not modify the real vector on exceptions. Initialize that one to zero,
to not leak any data. Provide a fast path if we're loading a full
vector.
As we don't have gvec ool handlers for single vectors, just calculate
the vector address manually.
We can reuse the helper later on for VECTOR LOAD WITH LENGTH. In fact,
we are going to name it "vll" right from the beginning, because that's
a better match.
Try to load the last element first. Access to the first element will
be checked afterwards. This way, we can guarantee that the vector is
not modified before we checked for all possible exceptions. (16 vectors
cannot cross more than two pages)
s390x/tcg: Implement VECTOR LOAD GR FROM VR ELEMENT
To avoid an helper, we have to do the actual calculation of the element
address (offset in cpu_env + cpu_env) manually. Factor that out into
get_vec_element_ptr_i64(). The same logic will be reused for "VECTOR
LOAD VR ELEMENT FROM GR".
Let's start with a more involved one, but it is the first in the list
of vector support instructions (introduced with the vector facility).
Good thing is, we need a lot of basic infrastructure for this. Reading
and writing vector elements as well as checking element validity.
All vector instruction related translation functions will reside in
translate_vx.inc.c, to be included in translate.c - similar to how
other architectures handle it.
While at it, directly add some documentation (which contains parts about
things added in follow-up patches, but splitting this up does not make
too much sense). Also add ES_* defines heavily used later.
s390x/tcg: Utilities for vector instruction helpers
We'll have to read/write vector elements quite frequently from helpers.
The tricky bit is properly taking care of endianess. Handle it similar
to aarch64.
s390x/tcg: Check vector register instructions at central point
Check them at a central point. We'll use a new instruction flag to
flag all vector instructions (IF_VEC) and handle it very similar to
AFP, whereby we use another unused position in the PSW mask to store
the state of vector register enablement per translation block.
These are the new instruction formats related to vector instructions as
up to the z14 (a.k.a. latest PoP).
As v2 appeares (like x2 in VRX) with d2/b2 in VRV, we have to assign it a
higher field number to avoid collisions.
Properly take care of the MSB (to be able to address 32 registers) for
each vector register field stored in the RXB field (Bit 36 - 30 for all
vector instructions). As we have 32 bit vector registers and the
"v" fields are only 4 bit in size, the 5th bit is stored in the RXB.
We use a new type to indicate that the MSB has to be fetched from the
RXB.
Thomas Huth [Tue, 5 Mar 2019 08:46:21 +0000 (09:46 +0100)]
target/s390x: Remove non-architected entries from struct LowCore
There are some fields in our struct LowCore which apparently have
been copied from a very old version of the Linux kernel. These
fields are not architected in the "Principles of Operation", and
only used on these memory locations in Linux kernels older than
2.6.29. Newer Linux kernels moved the entries to different locations
or are not using them at all anymore. Thus we should never access
these fields from the QEMU side, so they should be removed.
While we're at it, also add a QEMU_BUILD_BUG_ON() statement to
assert that struct LowCore has the right size.
The various ACL related commands are obsolete now that the QAuthZ
framework for authorization is fully integrated throughout QEMU network
services. These only ever worked with VNC and were never used by libvirt.
Mark it as deprecated with no direct replacement to be provided.
Authorization is now provided by using 'object_add' together with
the 'tls-authz' or 'sasl-authz' parameters to the VNC server, and
equivalent for other network services.
vnc: allow specifying a custom authorization object name
The VNC server has historically had support for ACLs to check both the
SASL username and the TLS x509 distinguished name. The VNC server was
responsible for creating the initial ACL, and the client app was then
responsible for populating it with rules using the HMP 'acl_add' command.
This is not satisfactory for a variety of reasons. There is no way to
populate the ACLs from the command line, users are forced to use the
HMP. With multiple network services all supporting TLS and ACLs now, it
is desirable to be able to define a single ACL that is referenced by all
services.
To address these limitations, two new options are added to the VNC
server CLI. The 'tls-authz' option takes the ID of a QAuthZ object to
use for checking TLS x509 distinguished names, and the 'sasl-authz'
option takes the ID of another object to use for checking SASL usernames.
In this example, we setup two authorization rules. The first allows any
client with a certificate issued by the 'RedHat' organization in the
'London' locality. The second ACL allows clients with either the
'[email protected]' or '[email protected]' kerberos usernames. Both checks
must pass for the user to be allowed.
Gerd Hoffmann [Tue, 5 Mar 2019 13:09:30 +0000 (14:09 +0100)]
vnc: fix update stalls
vnc aborts display update jobs on video mode switches and page flips.
That can cause vnc update stalls in case an unfinished vnc job gets
aborted. The vnc client will never receive the requested update then.
Fix that by copying the state from job_update back to update in that
case.
Reports complain about stalls with two or more clients being connected
at the same time, on some but not all connections. I suspect it can
also happen with a single connection, multiple connections only make
this more much likely to happen.
projects / qemu.git / log