Commit graph

300 commits

Author SHA1 Message Date
Claudio Fontana ee73443c7d cpu: move cc->do_interrupt to tcg_ops
Backports 0545608056a6161e7020cd7b9368d9636fa80051
2021-03-04 17:10:14 -05:00
Eduardo Habkost bc86f4377c cpu: Move debug_excp_handler to tcg_ops
Backports e9ce43e97a19090ae8975ef168b95ba3d29be991
2021-03-04 17:05:57 -05:00
Eduardo Habkost 76a10fa8e0 cpu: Move tlb_fill to tcg_ops
Backports e124536f37377cff5d68925d4976ad604d0ebf3a
2021-03-04 17:01:55 -05:00
Eduardo Habkost 03cc62e39c cpu: Move cpu_exec_* to tcg_ops
Backports 48c1a3e303b5a2cca48679645ad3fbb914db741a
2021-03-04 16:56:55 -05:00
Eduardo Habkost eb38ac1809 cpu: Move synchronize_from_tb() to tcg_ops
Backports ec62595bab1873c48a34849de70011093177e769
2021-03-04 16:48:27 -05:00
Eduardo Habkost b9b711afe3 cpu: Introduce TCGCpuOperations struct
The TCG-specific CPU methods will be moved to a separate struct,
to make it easier to move accel-specific code outside generic CPU
code in the future. Start by moving tcg_initialize().

The new CPUClass.tcg_opts field may eventually become a pointer,
but keep it an embedded struct for now, to make code conversion
easier.

Backports e9e51b7154404efc9af8735ab87c658a9c434cfd
2021-03-04 16:38:25 -05:00
Peter Maydell 1a3abaa81a target/i386: Check privilege level for protected mode 'int N' task gate
When the 'int N' instruction is executed in protected mode, the
pseudocode in the architecture manual specifies that we need to check:

* vector number within IDT limits
* selected IDT descriptor is a valid type (interrupt, trap or task gate)
* if this was a software interrupt then gate DPL < CPL

The way we had structured the code meant that the privilege check for
software interrupts ended up not in the code path taken for task gate
handling, because all of the task gate handling code was in the 'case 5'
of the switch which was checking "is this descriptor a valid type".

Move the task gate handling code out of that switch (so that it is now
purely doing the "valid type?" check) and below the software interrupt
privilege check.

The effect of this missing check was that in a guest userspace binary
executing 'int 8' would cause a guest kernel panic rather than the
userspace binary being handed a SEGV.

This is essentially the same bug fixed in VirtualBox in 2012:
https://www.halfdog.net/Security/2012/VirtualBoxSoftwareInterrupt0x8GuestCrash/

Note that for QEMU this is not a security issue because it is only
present when using TCG.

Backports 3df1a3d070575419859cbbab1083fafa7ec2669a
2021-03-03 19:32:10 -05:00
Bin Meng c59e391194 target/i386: seg_helper: Correct segment selector nullification in the RET/IRET helper
Per the SDM, when returning to outer privilege level, for segment
registers (ES, FS, GS, and DS) if the check fails, the segment
selector becomes null, but QEMU clears the base/limit/flags as well
as nullifying the segment selector, which should be a spec violation.

Real hardware seems to be compliant with the spec, at least on one
Coffee Lake board I tested.

Backports c2ba0515f2df58a661fcb5d6485139877d92ab1b
2021-03-03 19:10:24 -05:00
Paolo Bonzini 1da5d669a7 target/i386: fix operand order for PDEP and PEXT
For PDEP and PEXT, the mask is provided in the memory (mod+r/m)
operand, and therefore is loaded in s->T0 by gen_ldst_modrm.
The source is provided in the second source operand (VEX.vvvv)
and therefore is loaded in s->T1. Fix the order in which
they are passed to the helpers.

Backports 75b208c28316095c4685e8596ceb9e3f656592e2
2021-03-03 19:09:21 -05:00
Chetan Pant 3e25486110 x86 tcg cpus: Fix Lesser GPL version number
There is no "version 2" of the "Lesser" General Public License.
It is either "GPL version 2.0" or "Lesser GPL version 2.1".
This patch replaces all occurrences of "Lesser GPL version 2" with
"Lesser GPL version 2.1" in comment section.

Backport d9ff33ada7f32ca59f99b270a2d0eb223b3c9c8f
2021-03-02 13:33:10 -05:00
Xiaoyao Li d9d68cc128 i386/cpu: Clear FEAT_XSAVE_COMP_{LO,HI} when XSAVE is not available
Per Intel SDM vol 1, 13.2, if CPUID.1:ECX.XSAVE[bit 26] is 0, the
processor provides no further enumeration through CPUID function 0DH.
QEMU does not do this for "-cpu host,-xsave".

Backports 19ca8285fcd61a8f60f2f44f789a561e0958e8e6
2021-03-01 19:04:03 -05:00
Laszlo Ersek 40c04c73b0 target/i386: floatx80: avoid compound literals in static initializers
Quoting ISO C99 6.7.8p4, "All the expressions in an initializer for an
object that has static storage duration shall be constant expressions or
string literals".

The compound literal produced by the make_floatx80() macro is not such a
constant expression, per 6.6p7-9. (An implementation may accept it,
according to 6.6p10, but is not required to.)

Therefore using "floatx80_zero" and make_floatx80() for initializing
"f2xm1_table" and "fpatan_table" is not portable. And gcc-4.8 in RHEL-7.6
actually chokes on them:

> target/i386/fpu_helper.c:871:5: error: initializer element is not constant
> { make_floatx80(0xbfff, 0x8000000000000000ULL),
> ^

We've had the make_floatx80_init() macro for this purpose since commit
3bf7e40ab914 ("softfloat: fix for C99", 2012-03-17), so let's use that
macro again.

Fixes: eca30647fc0 ("target/i386: reimplement f2xm1 using floatx80 operations")
Fixes: ff57bb7b632 ("target/i386: reimplement fpatan using floatx80 operations")

Backports commit 163b3d1af2552845a60967979aca8d78a6b1b088 from qemu
2021-02-25 23:38:54 -05:00
Richard Henderson 6390789a09 target/i386: Save cc_op before loop insns
We forgot to update cc_op before these branch insns,
which lead to losing track of the current eflags.

Buglink: https://bugs.launchpad.net/qemu/+bug/1888165

Backports commit 3cb3a7720b01830abd5fbb81819dbb9271bf7821 from qemu
2021-02-25 23:36:43 -05:00
Chenyi Qiang e5d9e0ed53 target/i386: add fast short REP MOV support
For CPUs support fast short REP MOV[CPUID.(EAX=7,ECX=0):EDX(bit4)], e.g
Icelake and Tigerlake, expose it to the guest VM.

Backports commit 5cb287d2bd578dfe4897458793b4fce35bc4f744 from qemu
2021-02-25 23:31:42 -05:00
Paolo Bonzini 5b794349d3 target/i386: implement undocumented 'smsw r32' behavior
In 32-bit mode, the higher 16 bits of the destination
register are undefined. In practice CR0[31:0] is stored,
just like in 64-bit mode, so just remove the "if" that
currently differentiates the behavior.

Backports commit c0c8445255b2b5b440c355431c8b01b7b7b7c8cf from qemu
2021-02-25 23:23:51 -05:00
Joseph Myers cf54c51869 target/i386: fix IEEE SSE floating-point exception raising
The SSE instruction implementations all fail to raise the expected
IEEE floating-point exceptions because they do nothing to convert the
exception state from the softfloat machinery into the exception flags
in MXCSR.

Fix this by adding such conversions. Unlike for x87, emulated SSE
floating-point operations might be optimized using hardware floating
point on the host, and so a different approach is taken that is
compatible with such optimizations. The required invariant is that
all exceptions set in env->sse_status (other than "denormal operand",
for which the SSE semantics are different from those in the softfloat
code) are ones that are set in the MXCSR; the emulated MXCSR is
updated lazily when code reads MXCSR, while when code sets MXCSR, the
exceptions in env->sse_status are set accordingly.

A few instructions do not raise all the exceptions that would be
raised by the softfloat code, and those instructions are made to save
and restore the softfloat exception state accordingly.

Nothing is done about "denormal operand"; setting that (only for the
case when input denormals are *not* flushed to zero, the opposite of
the logic in the softfloat code for such an exception) will require
custom code for relevant instructions, or else architecture-specific
conditionals in the softfloat code for when to set such an exception
together with custom code for various SSE conversion and rounding
instructions that do not set that exception.

Nothing is done about trapping exceptions (for which there is minimal
and largely broken support in QEMU's emulation in the x87 case and no
support at all in the SSE case).

Backports commit 418b0f93d12a1589d5031405de857844f32e9ccc from qemu
2021-02-25 23:21:32 -05:00
Joseph Myers fd5b0dd456 target/i386: set SSE FTZ in correct floating-point state
The code to set floating-point state when MXCSR changes calls
set_flush_to_zero on &env->fp_status, so affecting the x87
floating-point state rather than the SSE state. Fix to call it for
&env->sse_status instead.

Backports commit 3ddc0eca2229846bfecc3485648a6cb85a466dc7 from qemu
2021-02-25 23:15:53 -05:00
Joseph Myers c01b7432a1 target/i386: reimplement fpatan using floatx80 operations
The x87 fpatan emulation is currently based around conversion to
double. This is inherently unsuitable for a good emulation of any
floatx80 operation. Reimplement using the soft-float operations, as
for other such instructions.

Backports commit ff57bb7b63267dabd60f88354c8c29ea5e1eb3ec from qemu
2021-02-25 13:48:32 -05:00
Joseph Myers ddb2f1d4dd target/i386: reimplement fyl2x using floatx80 operations
The x87 fyl2x emulation is currently based around conversion to
double. This is inherently unsuitable for a good emulation of any
floatx80 operation. Reimplement using the soft-float operations,
building on top of the reimplementation of fyl2xp1 and factoring out
code to be shared between the two instructions.

The included test assumes that the result in round-to-nearest mode
should always be one of the two closest floating-point numbers to the
mathematically exact result (including that it should be exact, in the
exact cases which cover more cases than for fyl2xp1).

Backports commit 1f18a1e6ab8368a4eab2d22894d3b2ae75250cd3 from qemu
2021-02-25 13:46:29 -05:00
Joseph Myers ac2f3fa0f2 target/i386: reimplement fyl2xp1 using floatx80 operations
The x87 fyl2xp1 emulation is currently based around conversion to
double. This is inherently unsuitable for a good emulation of any
floatx80 operation, even before considering that it is a particularly
naive implementation using double (adding 1 then using log rather than
attempting a better emulation using log1p).

Reimplement using the soft-float operations, as was done for f2xm1; as
in that case, m68k has related operations but not exactly this one and
it seemed safest to implement directly rather than reusing the m68k
code to avoid accumulation of errors.

A test is included with many randomly generated inputs. The
assumption of the test is that the result in round-to-nearest mode
should always be one of the two closest floating-point numbers to the
mathematical value of y * log2(x + 1); the implementation aims to do
somewhat better than that (about 70 correct bits before rounding). I
haven't investigated how accurate hardware is.

Intel manuals describe a narrower range of valid arguments to this
instruction than AMD manuals. The implementation accepts the wider
range (it's needed anyway for the core code to be reusable in a
subsequent patch reimplementing fyl2x), but the test only has inputs
in the narrower range so that it's valid on hardware that may reject
or produce poor results for inputs outside that range.

Code in the previous implementation that sets C2 for some out-of-range
arguments is not carried forward to the new implementation; C2 is
undefined for this instruction and I suspect that code was just
cut-and-pasted from the trigonometric instructions (fcos, fptan, fsin,
fsincos) where C2 *is* defined to be set for out-of-range arguments.

Backports commit 5eebc49d2d0aa5fc7e90eeac97533051bb7b72fa from qemu
2021-02-25 13:43:46 -05:00
Joseph Myers 0a790f9937 target/i386: reimplement fprem, fprem1 using floatx80 operations
The x87 fprem and fprem1 emulation is currently based around
conversion to double, which is inherently unsuitable for a good
emulation of any floatx80 operation. Reimplement using the soft-float
floatx80 remainder operations.

Backports commit 5ef396e2ba865f34a4766dbd60c739fb4bcb4fcc from qemu
2021-02-25 13:41:54 -05:00
Joseph Myers 2aee4714ab target/i386: reimplement f2xm1 using floatx80 operations
The x87 f2xm1 emulation is currently based around conversion to
double. This is inherently unsuitable for a good emulation of any
floatx80 operation, even before considering that it is a particularly
naive implementation using double (computing with pow and then
subtracting 1 rather than attempting a better emulation using expm1).

Reimplement using the soft-float operations, including additions and
multiplications with higher precision where appropriate to limit
accumulation of errors. I considered reusing some of the m68k code
for transcendental operations, but the instructions don't generally
correspond exactly to x87 operations (for example, m68k has 2^x and
e^x - 1, but not 2^x - 1); to avoid possible accumulation of errors
from applying multiple such operations each rounding to floatx80
precision, I wrote a direct implementation of 2^x - 1 instead. It
would be possible in principle to make the implementation more
efficient by doing the intermediate operations directly with
significands, signs and exponents and not packing / unpacking floatx80
format for each operation, but that would make it significantly more
complicated and it's not clear that's worthwhile; the m68k emulation
doesn't try to do that.

A test is included with many randomly generated inputs. The
assumption of the test is that the result in round-to-nearest mode
should always be one of the two closest floating-point numbers to the
mathematical value of 2^x - 1; the implementation aims to do somewhat
better than that (about 70 correct bits before rounding). I haven't
investigated how accurate hardware is.

Backports commit eca30647fc078f4d9ed1b455bd67960f99dbeb7a from qemu
2021-02-25 13:31:13 -05:00
Thomas Huth 6053203c1c target/i386: Remove obsolete TODO file
The last real change to this file is from 2012, so it is very likely
that this file is completely out-of-date and ignored today. Let's
simply remove it to avoid confusion if someone finds it by accident.

Backports commit 3575b0aea983ad57804c9af739ed8ff7bc168393 from qemu
2020-06-15 13:22:56 -04:00
Joseph Myers 18b0ae9ebd target/i386: correct fix for pcmpxstrx substring search
This corrects a bug introduced in my previous fix for SSE4.2 pcmpestri
/ pcmpestrm / pcmpistri / pcmpistrm substring search, commit
ae35eea7e4a9f21dd147406dfbcd0c4c6aaf2a60.

That commit fixed a bug that showed up in four GCC tests with one libc
implementation. The tests in question generate random inputs to the
intrinsics and compare results to a C implementation, but they only
test 1024 possible random inputs, and when the tests use the cases of
those instructions that work with word rather than byte inputs, it's
easy to have problematic cases that show up much less frequently than
that. Thus, testing with a different libc implementation, and so a
different random number generator, showed up a problem with the
previous patch.

When investigating the previous test failures, I found the description
of these instructions in the Intel manuals (starting from computing a
16x16 or 8x8 set of comparison results) confusing and hard to match up
with the more optimized implementation in QEMU, and referred to AMD
manuals which described the instructions in a different way. Those
AMD descriptions are very explicit that the whole of the string being
searched for must be found in the other operand, not running off the
end of that operand; they say "If the prototype and the SUT are equal
in length, the two strings must be identical for the comparison to be
TRUE.". However, that statement is incorrect.

In my previous commit message, I noted:

The operation in this case is a search for a string (argument d to
the helper) in another string (argument s to the helper); if a copy
of d at a particular position would run off the end of s, the
resulting output bit should be 0 whether or not the strings match in
the region where they overlap, but the QEMU implementation was
wrongly comparing only up to the point where s ends and counting it
as a match if an initial segment of d matched a terminal segment of
s. Here, "run off the end of s" means that some byte of d would
overlap some byte outside of s; thus, if d has zero length, it is
considered to match everywhere, including after the end of s.

The description "some byte of d would overlap some byte outside of s"
is accurate only when understood to refer to overlapping some byte
*within the 16-byte operand* but at or after the zero terminator; it
is valid to run over the end of s if the end of s is the end of the
16-byte operand. So the fix in the previous patch for the case of d
being empty was correct, but the other part of that patch was not
correct (as it never allowed partial matches even at the end of the
16-byte operand). Nor was the code before the previous patch correct
for the case of d nonempty, as it would always have allowed partial
matches at the end of s.

Fix with a partial revert of my previous change, combined with
inserting a check for the special case of s having maximum length to
determine where it is necessary to check for matches.

In the added test, test 1 is for the case of empty strings, which
failed before my 2017 patch, test 2 is for the bug introduced by my
2017 patch and test 3 deals with the case where a match of an initial
segment at the end of the string is not valid when the string ends
before the end of the 16-byte operand (that is, the case that would be
broken by a simple revert of the non-empty-string part of my 2017
patch).

Backports commit bc921b2711c4e2e8ab99a3045f6c0f134a93b535 from qemu
2020-06-15 13:20:48 -04:00
Joseph Myers e79024e0cf target/i386: fix IEEE x87 floating-point exception raising
Most x87 instruction implementations fail to raise the expected IEEE
floating-point exceptions because they do nothing to convert the
exception state from the softfloat machinery into the exception flags
in the x87 status word. There is special-case handling of division to
raise the divide-by-zero exception, but that handling is itself buggy:
it raises the exception in inappropriate cases (inf / 0 and nan / 0,
which should not raise any exceptions, and 0 / 0, which should raise
"invalid" instead).

Fix this by converting the floating-point exceptions raised during an
operation by the softfloat machinery into exceptions in the x87 status
word (passing through the existing fpu_set_exception function for
handling related to trapping exceptions). There are special cases
where some functions convert to integer internally but exceptions from
that conversion are not always correct exceptions for the instruction
to raise.

There might be scope for some simplification if the softfloat
exception state either could always be assumed to be in sync with the
state in the status word, or could always be ignored at the start of
each instruction and just set to 0 then; I haven't looked into that in
detail, and it might run into interactions with the various ways the
emulation does not yet handle trapping exceptions properly. I think
the approach taken here, of saving the softfloat state, setting
exceptions there to 0 and then merging the old exceptions back in
after carrying out the operation, is conservatively safe

Backports commit 975af797f1e04e4d1b1a12f1731141d3770fdbce from qemu
2020-06-15 13:19:27 -04:00
Joseph Myers cb50df6aae target/i386: fix fisttpl, fisttpll handling of out-of-range values
The fist / fistt family of instructions should all store the most
negative integer in the destination format when the rounded /
truncated integer result is out of range or the input is an invalid
encoding, infinity or NaN. The fisttpl and fisttpll implementations
(32-bit and 64-bit results, truncate towards zero) failed to do this,
producing the most positive integer in some cases instead. Fix this
by copying the code used to handle this issue for fistpl and fistpll,
adjusted to use the _round_to_zero functions for the actual
conversion (but without any other changes to that code).

Backports commit c8af85b10c818709755f5dc8061c69920611fd4c from qemu
2020-06-15 13:10:23 -04:00
Joseph Myers ceaa77e576 target/i386: fix fbstp handling of out-of-range values
The fbstp implementation fails to check for out-of-range and invalid
values, instead just taking the result of conversion to int64_t and
storing its sign and low 18 decimal digits. Fix this by checking for
an out-of-range result (invalid conversions always result in INT64_MAX
or INT64_MIN from the softfloat code, which are large enough to be
considered as out-of-range by this code) and storing the packed BCD
indefinite encoding in that case.

Backports commit 374ff4d0a3c2cce2bc6e4ba8a77eaba55c165252 from qemu
2020-06-15 13:09:23 -04:00
Joseph Myers 477a0af161 target/i386: fix fbstp handling of negative zero
The fbstp implementation stores +0 when the rounded result should be
-0 because it compares an integer value with 0 to determine the sign.
Fix this by checking the sign bit of the operand instead.

Backports commit 18c53e1e73197a24f9f4b66b1276eb9868db5bf0 from qemu
2020-06-15 13:08:38 -04:00
Joseph Myers c796ee5e13 target/i386: fix fxam handling of invalid encodings
The fxam implementation does not check for invalid encodings, instead
treating them like NaN or normal numbers depending on the exponent.
Fix it to check that the high bit of the significand is set before
treating an encoding as NaN or normal, thus resulting in correct
handling (all of C0, C2 and C3 cleared) for invalid encodings.

Backports commit 34b9cc076ff423023a779a04a9f7cd7c17372cbf from qemu
2020-06-15 13:07:54 -04:00
Joseph Myers 5a01ea31eb target/i386: fix floating-point load-constant rounding
The implementations of the fldl2t, fldl2e, fldpi, fldlg2 and fldln2
instructions load fixed constants independent of the rounding mode.
Fix them to load a value correctly rounded for the current rounding
mode (but always rounded to 64-bit precision independent of the
precision control, and without setting "inexact") as specified.

Backports commit 80b4008c805ebcfd4c0d302ac31c1689e34571e0 from qemu
2020-06-15 13:07:06 -04:00
Joseph Myers 95368d250b target/i386: fix fscale handling of rounding precision
The fscale implementation uses floatx80_scalbn for the final scaling
operation. floatx80_scalbn ends up rounding the result using the
dynamic rounding precision configured for the FPU. But only a limited
set of x87 floating-point instructions are supposed to respect the
dynamic rounding precision, and fscale is not in that set. Fix the
implementation to save and restore the rounding precision around the
call to floatx80_scalbn.

Backports commit c535d68755576bfa33be7aef7bd294a601f776e0 from qemu
2020-06-15 13:05:31 -04:00
Joseph Myers ad83656acc target/i386: fix fscale handling of infinite exponents
The fscale implementation passes infinite exponents through to generic
code that rounds the exponent to a 32-bit integer before using
floatx80_scalbn. In round-to-nearest mode, and ignoring exceptions,
this works in many cases. But it fails to handle the special cases of
scaling 0 by a +Inf exponent or an infinity by a -Inf exponent, which
should produce a NaN, and because it produces an inexact result for
finite nonzero numbers being scaled, the result is sometimes incorrect
in other rounding modes. Add appropriate handling of infinite
exponents to produce a NaN or an appropriately signed exact zero or
infinity as a result

Backports commit c1c5fb8f9067c830e36830c2b82c0ec146c03d7b from qemu
2020-06-15 13:04:46 -04:00
Joseph Myers bbbf25fdd9 target/i386: fix fscale handling of invalid exponent encodings
The fscale implementation does not check for invalid encodings in the
exponent operand, thus treating them like INT_MIN (the value returned
for invalid encodings by floatx80_to_int32_round_to_zero). Fix it to
treat them similarly to signaling NaN exponents, thus generating a
quiet NaN result.

Backports commit b40eec96b26028b68c3594fbf34b6d6f029df26a from qemu
2020-06-15 13:03:54 -04:00
Joseph Myers d96c218664 target/i386: fix fscale handling of signaling NaN
The implementation of the fscale instruction returns a NaN exponent
unchanged. Fix it to return a quiet NaN when the provided exponent is
a signaling NaN.

Backports commit 0d48b436327955c69e2eb53f88aba9aa1e0dbaa0 from qemu
2020-06-15 13:03:16 -04:00
Joseph Myers 18fc17ca25 target/i386: implement special cases for fxtract
The implementation of the fxtract instruction treats all nonzero
operands as normal numbers, so yielding incorrect results for invalid
formats, infinities, NaNs and subnormal and pseudo-denormal operands.
Implement appropriate handling of all those cases.

Backports commit c415f2c58296d86e9abb7e4a133111acf7031da3 from qemu
2020-06-15 13:02:33 -04:00
Liran Alon 7373942623 i386/cpu: Store LAPIC bus frequency in CPU structure
No functional change.
This information will be used by following patches.

Backports commit 73b994f6d74ec00a1d78daf4145096ff9f0e2982 from qemu
2020-06-15 13:00:58 -04:00
Janne Grunau 6f41687234 target/i386: fix phadd* with identical destination and source register
Detected by asm test suite failures in dav1d
(https://code.videolan.org/videolan/dav1d). Can be reproduced by
`qemu-x86_64 -cpu core2duo ./tests/checkasm --test=mc_8bpc 1659890620`.

Backports commit 2dfbea1a872727fb747ca6adf2390e09956cdc6e from qemu
2020-06-15 12:59:49 -04:00
Philippe Mathieu-Daudé 34930da196 target/i386: Fix OUTL debug output
Fix OUTL instructions incorrectly displayed as OUTW.

Backports commit ce8540fde2cb535923a52a012f57b418eea85e1b from qemu
2020-06-15 12:56:33 -04:00
Richard Henderson d960523cbd softfloat: Name compare relation enum
Give the previously unnamed enum a typedef name. Use it in the
prototypes of compare functions. Use it to hold the results
of the compare functions.

Backports commit 71bfd65c5fcd72f8af2735905415c7ce4220f6dc from qemu
2020-05-21 18:08:52 -04:00
Philippe Mathieu-Daudé 6d9233a542 various: Remove suspicious '\' character outside of #define in C code
Fixes the following coccinelle warnings:

$ spatch --sp-file --verbose-parsing ... \
scripts/coccinelle/remove_local_err.cocci
...
SUSPICIOUS: a \ character appears outside of a #define at ./target/ppc/translate_init.inc.c:5213
SUSPICIOUS: a \ character appears outside of a #define at ./target/ppc/translate_init.inc.c:5261
SUSPICIOUS: a \ character appears outside of a #define at ./target/microblaze/cpu.c:166
SUSPICIOUS: a \ character appears outside of a #define at ./target/microblaze/cpu.c:167
SUSPICIOUS: a \ character appears outside of a #define at ./target/microblaze/cpu.c:169
SUSPICIOUS: a \ character appears outside of a #define at ./target/microblaze/cpu.c:170
SUSPICIOUS: a \ character appears outside of a #define at ./target/microblaze/cpu.c:171
SUSPICIOUS: a \ character appears outside of a #define at ./target/microblaze/cpu.c:172
SUSPICIOUS: a \ character appears outside of a #define at ./target/microblaze/cpu.c:173
SUSPICIOUS: a \ character appears outside of a #define at ./target/i386/cpu.c:5787
SUSPICIOUS: a \ character appears outside of a #define at ./target/i386/cpu.c:5789
SUSPICIOUS: a \ character appears outside of a #define at ./target/i386/cpu.c:5800
SUSPICIOUS: a \ character appears outside of a #define at ./target/i386/cpu.c:5801
SUSPICIOUS: a \ character appears outside of a #define at ./target/i386/cpu.c:5802
SUSPICIOUS: a \ character appears outside of a #define at ./target/i386/cpu.c:5804
SUSPICIOUS: a \ character appears outside of a #define at ./target/i386/cpu.c:5805
SUSPICIOUS: a \ character appears outside of a #define at ./target/i386/cpu.c:5806
SUSPICIOUS: a \ character appears outside of a #define at ./target/i386/cpu.c:6329
SUSPICIOUS: a \ character appears outside of a #define at ./hw/sd/sdhci.c:1133
SUSPICIOUS: a \ character appears outside of a #define at ./hw/scsi/scsi-disk.c:3081
SUSPICIOUS: a \ character appears outside of a #define at ./hw/net/virtio-net.c:1529
SUSPICIOUS: a \ character appears outside of a #define at ./hw/riscv/sifive_u.c:468
SUSPICIOUS: a \ character appears outside of a #define at ./dump/dump.c:1895
SUSPICIOUS: a \ character appears outside of a #define at ./block/vhdx.c:2209
SUSPICIOUS: a \ character appears outside of a #define at ./block/vhdx.c:2215
SUSPICIOUS: a \ character appears outside of a #define at ./block/vhdx.c:2221
SUSPICIOUS: a \ character appears outside of a #define at ./block/vhdx.c:2222
SUSPICIOUS: a \ character appears outside of a #define at ./block/replication.c:172
SUSPICIOUS: a \ character appears outside of a #define at ./block/replication.c:173

Backports commit 78ee6bd04821847036a805cb4bdd46464e1d3098 from qemu
2020-04-30 07:31:45 -04:00
Richard Henderson 5ac51ff092 target/i386: Renumber EXCP_SYSCALL
We are not short of numbers for EXCP_*. There is no need to confuse things
by having EXCP_VMEXIT and EXCP_SYSCALL overlap, even though the former is
only used for system mode and the latter is only used for user mode.

Backports commit 628460891dd46c25e33eec01757ac655679ea198 from qemu
2020-04-30 06:56:25 -04:00
Moger, Babu 8c5f623ac3 i386: Add 2nd Generation AMD EPYC processors
Adds the support for 2nd Gen AMD EPYC Processors. The model display
name will be EPYC-Rome.

Adds the following new feature bits on top of the feature bits from the
first generation EPYC models.
perfctr-core : core performance counter extensions support. Enables the VM to
use extended performance counter support. It enables six
programmable counters instead of four counters.
clzero : instruction zeroes out the 64 byte cache line specified in RAX.
xsaveerptr : XSAVE, XSAVE, FXSAVEOPT, XSAVEC, XSAVES always save error
pointers and FXRSTOR, XRSTOR, XRSTORS always restore error
pointers.
wbnoinvd : Write back and do not invalidate cache
ibpb : Indirect Branch Prediction Barrier
amd-stibp : Single Thread Indirect Branch Predictor
clwb : Cache Line Write Back and Retain
xsaves : XSAVES, XRSTORS and IA32_XSS support
rdpid : Read Processor ID instruction support
umip : User-Mode Instruction Prevention support

The Reference documents are available at
https://developer.amd.com/wp-content/resources/55803_0.54-PUB.pdf
https://www.amd.com/system/files/TechDocs/24594.pdf

Depends on following kernel commits:
40bc47b08b6e ("kvm: x86: Enumerate support for CLZERO instruction")
504ce1954fba ("KVM: x86: Expose XSAVEERPTR to the guest")
6d61e3c32248 ("kvm: x86: Expose RDPID in KVM_GET_SUPPORTED_CPUID")
52297436199d ("kvm: svm: Update svm_xsaves_supported")

Backports commit 143c30d4d346831a09e59e9af45afdca0331e819 from qem
2020-04-30 06:50:02 -04:00
Moger, Babu ced1be70e2 i386: Add missing cpu feature bits in EPYC model
Adds the following missing CPUID bits:
perfctr-core : core performance counter extensions support. Enables the VM
to use extended performance counter support. It enables six
programmable counters instead of 4 counters.
clzero : instruction zeroes out the 64 byte cache line specified in RAX.
xsaveerptr : XSAVE, XSAVE, FXSAVEOPT, XSAVEC, XSAVES always save error
pointers and FXRSTOR, XRSTOR, XRSTORS always restore error
pointers.
ibpb : Indirect Branch Prediction Barrie.
xsaves : XSAVES, XRSTORS and IA32_XSS supported.

Depends on following kernel commits:
40bc47b08b6e ("kvm: x86: Enumerate support for CLZERO instruction")
504ce1954fba ("KVM: x86: Expose XSAVEERPTR to the guest")
52297436199d ("kvm: svm: Update svm_xsaves_supported")

These new features will be added in EPYC-v3. The -cpu help output after the change.
x86 EPYC-v1 AMD EPYC Processor
x86 EPYC-v2 AMD EPYC Processor (with IBPB)
x86 EPYC-v3 AMD EPYC Processor

Backports commit a16e8dbc043720abcb37fc7dca313e720b4e0f0c from qemu
2020-04-30 06:47:26 -04:00
Tao Xu 7b2296a512 target/i386: Add Denverton-v2 (no MPX) CPU model
Because MPX is being removed from the linux kernel, remove MPX feature
from Denverton.

Backports commit ab0c942c868210e78ff88aef83efb4b4018068e1 from qemu
2020-04-30 06:45:13 -04:00
Paolo Bonzini 583cc7b8b1 target/i386: check for empty register in FXAM
The fxam instruction returns the wrong result after fdecstp or after
an underflow. Check fptags to handle this.

Backports commit 93c3593ad04f2610fd0a176dfa89a7e40b6afe1f from qemu
2020-03-21 19:43:24 -04:00
Kashyap Chamarthy 8392450626 target/i386: Add the 'model-id' for Skylake -v3 CPU models
This fixes a confusion in the help output. (Although, if you squint
long enough at the '-cpu help' output, you _do_ notice that
"Skylake-Client-noTSX-IBRS" is an alias of "Skylake-Client-v3";
similarly for Skylake-Server-v3.)

Without this patch:

$ qemu-system-x86 -cpu help
...
x86 Skylake-Client-v1 Intel Core Processor (Skylake)
x86 Skylake-Client-v2 Intel Core Processor (Skylake, IBRS)
x86 Skylake-Client-v3 Intel Core Processor (Skylake, IBRS)
...
x86 Skylake-Server-v1 Intel Xeon Processor (Skylake)
x86 Skylake-Server-v2 Intel Xeon Processor (Skylake, IBRS)
x86 Skylake-Server-v3 Intel Xeon Processor (Skylake, IBRS)
...

With this patch:

$ ./qemu-system-x86 -cpu help
...
x86 Skylake-Client-v1 Intel Core Processor (Skylake)
x86 Skylake-Client-v2 Intel Core Processor (Skylake, IBRS)
x86 Skylake-Client-v3 Intel Core Processor (Skylake, IBRS, no TSX)
...
x86 Skylake-Server-v1 Intel Xeon Processor (Skylake)
x86 Skylake-Server-v2 Intel Xeon Processor (Skylake, IBRS)
x86 Skylake-Server-v3 Intel Xeon Processor (Skylake, IBRS, no TSX)

Backports commit 673b0add9ea7f432f34c1c99eaa7c567012fc838 from qemu
2020-03-21 12:27:24 -04:00
Chen Huitao 221333ceaf check arguments, return error instead of raising exceptions. (#1125)
* check arguments, return error instaed of raising exceptions. close #1117.

* remove empty lines. remove thr underscore prefix in function name.

Backports commit 23a426625f1469bd2052eab7d014deb6b9820bf2 from unicorn.
2020-01-14 09:00:11 -05:00
Pan Nengyuan 134a026e6b arm/translate-a64: fix uninitialized variable warning
Fixes:
target/arm/translate-a64.c: In function 'disas_crypto_three_reg_sha512':
target/arm/translate-a64.c:13625:9: error: 'genfn' may be used uninitialized in this function [-Werror=maybe-uninitialized]
genfn(tcg_rd_ptr, tcg_rn_ptr, tcg_rm_ptr);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
qemu/target/arm/translate-a64.c:13609:8: error: 'feature' may be used uninitialized in this function [-Werror=maybe-uninitialized]
if (!feature) {

Backports commit c7a5e7910517e2711215a9e869a733ffde696091 from qemu
2020-01-14 08:46:42 -05:00
Xiaoyao Li 31ab6fbd2c target/i386: Add missed features to Cooperlake CPU model
It lacks VMX features and two security feature bits (disclosed recently) in
MSR_IA32_ARCH_CAPABILITIES in current Cooperlake CPU model, so add them.

Fixes: 22a866b6166d ("i386: Add new CPU model Cooperlake")

Backports commit 2dea9d9ca4ea7e9afe83d0b4153b21a16987e866 from qemu
2020-01-14 08:43:26 -05:00
Xiaoyao Li 5e0b249dc0 target/i386: Add new bit definitions of MSR_IA32_ARCH_CAPABILITIES
The bit 6, 7 and 8 of MSR_IA32_ARCH_CAPABILITIES are recently disclosed
for some security issues. Add the definitions for them to be used by named
CPU models.

Backports commit 6c997b4adb300788d61d72e2b8bc67c03a584956 from qemu
2020-01-14 08:30:17 -05:00