Revision c4ed8c5610984e77a8bbf30e11b4a45a49a5c239 authored by Daniel Henrique Barboza on 14 March 2024, 17:57:00 UTC, committed by Michael Tokarev on 27 March 2024, 10:00:21 UTC
We're going to make changes that will required each helper to be responsible for the 'vstart' management, i.e. we will relieve the 'vstart < vl' assumption that helpers have today. Helpers are usually able to deal with vstart >= vl, i.e. doing nothing aside from setting vstart = 0 at the end, but the tail update functions will update the tail regardless of vstart being valid or not. Unifying the tail update process in a single function that would handle the vstart >= vl case isn't trivial (see [1] for more info). This patch takes a blunt approach: do an early exit in every single vector helper if vstart >= vl, unless the helper is guarded with vstart_eq_zero in the translation. For those cases the helper is ready to deal with cases where vl might be zero, i.e. throwing exceptions based on it like vcpop_m() and first_m(). Helpers that weren't changed: - vcpop_m(), vfirst_m(), vmsetm(), GEN_VEXT_VIOTA_M(): these are guarded directly with vstart_eq_zero; - GEN_VEXT_VCOMPRESS_VM(): guarded with vcompress_vm_check() that checks vstart_eq_zero; - GEN_VEXT_RED(): guarded with either reduction_check() or reduction_widen_check(), both check vstart_eq_zero; - GEN_VEXT_FRED(): guarded with either freduction_check() or freduction_widen_check(), both check vstart_eq_zero. Another exception is vext_ldst_whole(), who operates on effective vector length regardless of the current settings in vtype and vl. [1] https://lore.kernel.org/qemu-riscv/1590234b-0291-432a-a0fa-c5a6876097bc@linux.alibaba.com/ Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240314175704.478276-7-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit df4252b2ecaf93b601109373a17427d1867046e8) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
1 parent 43ca6c1
qemu.sasl
# If you want to use VNC remotely without TLS, then you *must*
# pick a mechanism which provides session encryption as well
# as authentication.
#
# If you are only using TLS, then you can turn on any mechanisms
# you like for authentication, because TLS provides the encryption
#
# If you are only using UNIX sockets then encryption is not
# required at all.
#
# NB, previously DIGEST-MD5 was set as the default mechanism for
# QEMU VNC. Per RFC 6331 this is vulnerable to many serious security
# flaws as should no longer be used. Thus GSSAPI is now the default.
#
# To use GSSAPI requires that a QEMU service principal is
# added to the Kerberos server for each host running QEMU.
# This principal needs to be exported to the keytab file listed below
mech_list: gssapi
# If using TLS with VNC, or a UNIX socket only, it is possible to
# enable plugins which don't provide session encryption. The
# 'scram-sha-256' plugin allows plain username/password authentication
# to be performed
#
#mech_list: scram-sha-256
# You can also list many mechanisms at once, and the VNC server will
# negotiate which to use by considering the list enabled on the VNC
# client.
#mech_list: scram-sha-256 gssapi
# This file needs to be populated with the service principal that
# was created on the Kerberos v5 server. If switching to a non-gssapi
# mechanism this can be commented out.
keytab: /etc/qemu/krb5.tab
# If using scram-sha-256 for username/passwds, then this is the file
# containing the passwds. Use 'saslpasswd2 -a qemu [username]'
# to add entries, and 'sasldblistusers2 -f [sasldb_path]' to browse it.
# Note that this file stores passwords in clear text.
#sasldb_path: /etc/qemu/passwd.db
Computing file changes ...