kvm_s390_mem_op() can fail in two ways: when !cap_mem_op, it returns
-ENOSYS, and when kvm_vcpu_ioctl() fails, it returns -errno set by
ioctl().  Its caller s390_cpu_virt_mem_rw() recovers from both
failures.

kvm_s390_mem_op() prints "KVM_S390_MEM_OP failed" with error_printf()
in the latter failure mode.  Since this is obviously a warning, use
warn_report().

Perhaps the reporting should be left to the caller.  It could warn on
failure other than -ENOSYS.

Cc: Thomas Huth <thuth@redhat.com>
Cc: qemu-s390x@nongnu.org
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NThomas Huth <thuth@redhat.com>
Reviewed-by: NCornelia Huck <cohuck@redhat.com>
Message-Id: <20190417190641.26814-9-armbru@redhat.com>

Fix a TCG crash due to attempting an atomic increment
operation without having set up the address first.
This is a similar case to that dealt with in commit
e84fcd7f, and we fix it in the same way.

Fixes: https://bugs.launchpad.net/qemu/+bug/1807675Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Acked-by: NPaolo Bonzini <pbonzini@redhat.com>
Message-id: 20190328104750.25046-1-peter.maydell@linaro.org

I've been hitting several QEMU crashes while running a fedora29 ppc64le
guest under TCG. Each time, this would occur several minutes after the
guest reached login:

Fedora 29 (Twenty Nine)
Kernel 4.20.6-200.fc29.ppc64le on an ppc64le (hvc0)

Web console: https://localhost:9090/

localhost login:
tcg/tcg.c:3211: tcg fatal error

This happens because a bug crept up in the gen_stxsdx() helper when it
was converted to use VSR register accessors by commit 8b3b2d75
"target/ppc: introduce get_cpu_vsr{l,h}() and set_cpu_vsr{l,h}() helpers
for VSR register access".

The code creates a temporary, passes it directly to gen_qemu_st64_i64()
and then to set_cpu_vrsh()... which looks like this was mistakenly
coded as a load instead of a store.

Reverse the logic: read the VSR to the temporary first and then store
it to memory.

Fixes: 8b3b2d75Signed-off-by: NGreg Kurz <groug@kaod.org>
Message-Id: <155371035249.2038502.12364252604337688538.stgit@bahia.lan>
Reviewed-by: NMark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>

Signed-off-by: NGreg Kurz <groug@kaod.org>
Message-Id: <155359567174.1794128.3183997593369465355.stgit@bahia.lan>
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>

We use PPC_SEGMENT_64B in various places to guard code that is specific
to 64-bit server processors compliant with arch 2.x. Consolidate the
logic in a helper macro with an explicit name.
Signed-off-by: NGreg Kurz <groug@kaod.org>
Message-Id: <155327783157.1283071.3747129891004927299.stgit@bahia.lan>
Tested-by: NSuraj Jitindar Singh <sjitindarsingh@gmail.com>
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>

Even if all ISAs up to v3 indeed mention:

    If the "decrement and test CTR" option is specified (BO2=0), the
    instruction form is invalid.

The UMs of all existing 64-bit server class processors say:

    If BO[2] = 0, the contents of CTR (before any update) are used as the
    target address and for the test of the contents of CTR to resolve the
    branch. The contents of the CTR are then decremented and written back
    to the CTR.

The linux kernel has spectre v2 mitigation code that relies on a
BO[2] = 0 variant of bcctr, which is now activated by default on
spapr, even with TCG. This causes linux guests to panic with
the default machine type under TCG.

Since any CPU model can provide its own behaviour for invalid forms,
we could possibly introduce a new instruction flag to handle this.
In practice, since the behaviour is shared by all 64-bit server
processors starting with 970 up to POWER9, let's reuse the
PPC_SEGMENT_64B flag. Caveat: this may have to be fixed later if
POWER10 introduces a different behaviour.

The existing behaviour of throwing a program interrupt is kept for
all other CPU models.
Signed-off-by: NGreg Kurz <groug@kaod.org>
Message-Id: <155327782604.1283071.10640596307206921951.stgit@bahia.lan>
Tested-by: NSuraj Jitindar Singh <sjitindarsingh@gmail.com>
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>

Signed-off-by: NGreg Kurz <groug@kaod.org>
Message-Id: <155327782047.1283071.10234727692461848972.stgit@bahia.lan>
Tested-by: NSuraj Jitindar Singh <sjitindarsingh@gmail.com>
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>

Fixes: https://bugs.launchpad.net/bugs/1821430Signed-off-by: NRichard Henderson <richard.henderson@linaro.org>
Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: NAlex Bennée <alex.bennee@linaro.org>
Message-id: 20190325161338.6536-1-richard.henderson@linaro.org
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

base register is no rs1 not rs2 for fsw.
Signed-off-by: NKito Cheng <kito.cheng@gmail.com>
Reviewed-by: NPalmer Dabbelt <palmer@sifive.com>
Signed-off-by: NPalmer Dabbelt <palmer@sifive.com>

These functions are not used outside helper.c
Signed-off-by: NAndrew Jones <drjones@redhat.com>
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
Message-id: 20190322162333.17159-4-drjones@redhat.com
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

cortex-a7 and cortex-a15 have pmus (PMUv2) and they advertise
them in ID_DFR0. Let's allow them to function. This also enables
the pmu cpu property to work with these cpu types, i.e. we can
now do '-cpu cortex-a15,pmu=off' to remove the pmu.
Signed-off-by: NAndrew Jones <drjones@redhat.com>
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
Message-id: 20190322162333.17159-3-drjones@redhat.com
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

Fix a QEMU NULL derefence that occurs when the guest attempts to
enable PMU counters with a non-v8 cpu model or a v8 cpu model
which has not configured a PMU.

Fixes: 4e7beb0c ("target/arm: Add a timer to predict PMU counter overflow")
Signed-off-by: NAndrew Jones <drjones@redhat.com>
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
Message-id: 20190322162333.17159-2-drjones@redhat.com
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

The second word has been loaded from the unincremented
address since the first commit.

Fixes: 44ac14b0Reported-by: NAlex Bennée <alex.bennee@linaro.org>
Signed-off-by: NRichard Henderson <richard.henderson@linaro.org>
Reviewed-by: NAlex Bennée <alex.bennee@linaro.org>
Tested-by: NAlex Bennée <alex.bennee@linaro.org>
Message-id: 20190322234302.12770-1-richard.henderson@linaro.org
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

Don't announce that exit simcall has been invoked: this is just noise.
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
Signed-off-by: NMax Filippov <jcmvbkbc@gmail.com>

We spell out sub/dir/ in sub/dir/trace-events' comments pointing to
source files.  That's because when trace-events got split up, the
comments were moved verbatim.

Delete the sub/dir/ part from these comments.  Gets rid of several
misspellings.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NPhilippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20190314180929.27722-3-armbru@redhat.com
Message-Id: <20190314180929.27722-3-armbru@redhat.com>
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>

While running the GCC test suite against 4.0.0-rc0, Kito found a
regression introduced by the decodetree conversion that caused divuw and
remuw to sign-extend their inputs.  The ISA manual says they are
supposed to be zero extended:

    DIVW and DIVUW instructions are only valid for RV64, and divide the
    lower 32 bits of rs1 by the lower 32 bits of rs2, treating them as
    signed and unsigned integers respectively, placing the 32-bit
    quotient in rd, sign-extended to 64 bits. REMW and REMUW
    instructions are only valid for RV64, and provide the corresponding
    signed and unsigned remainder operations respectively.  Both REMW
    and REMUW always sign-extend the 32-bit result to 64 bits, including
    on a divide by zero.

Here's Kito's reduced test case from the GCC test suite

    unsigned calc_mp(unsigned mod)
    {
         unsigned a,b,c;
         c=-1;
         a=c/mod;
         b=0-a*mod;
         if (b > mod) { a += 1; b-=mod; }
         return b;
    }

    int main(int argc, char *argv[])
    {
         unsigned x = 1234;
         unsigned y = calc_mp(x);

         if ((sizeof (y) == 4 && y != 680)
      || (sizeof (y) == 2 && y != 134))
    abort ();
         exit (0);
    }

I haven't done any other testing on this, but it does fix the test case.
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
Signed-off-by: NPalmer Dabbelt <palmer@sifive.com>

break_dependency incorrectly handles the case of dependency on an opcode
that references the same register multiple times. E.g. the following
instruction is translated incorrectly:

  { or a2, a3, a3 ; or a3, a2, a2 }

This happens because resource indices of both dependency graph nodes are
incremented, and a copy for the second instance of the same register in
the ending node is not done.
Only increment resource index of the ending node of the dependency.
Add test.
Signed-off-by: NMax Filippov <jcmvbkbc@gmail.com>

Currently, the Cascadelake-Server, Icelake-Client, and
Icelake-Server are always generating the following warning:

  qemu-system-x86_64: warning: \
    host doesn't support requested feature: CPUID.07H:ECX [bit 4]

This happens because OSPKE was never returned by
GET_SUPPORTED_CPUID or x86_cpu_get_supported_feature_word().
OSPKE is a runtime flag automatically set by the KVM module or by
TCG code, was always cleared by x86_cpu_filter_features(), and
was not supposed to appear on the CPU model table.

Remove the OSPKE flag from the CPU model table entries, to avoid
the bogus warning and avoid returning invalid feature data on
query-cpu-* QMP commands.  As OSPKE was always cleared by
x86_cpu_filter_features(), this won't have any guest-visible
impact.

Include a test case that should detect the problem if we introduce
a similar bug again.

Fixes: c7a88b52 ("i386: Add new model of Cascadelake-Server")
Fixes: 8a11c62d ("i386: Add new CPU model Icelake-{Server,Client}")
Cc: Tao Xu <tao3.xu@intel.com>
Cc: Robert Hoo <robert.hu@linux.intel.com>
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Message-Id: <20190319200515.14999-1-ehabkost@redhat.com>
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>

Now that kvm_arch_get_supported_cpuid() will only return
arch_capabilities if QEMU is able to initialize the MSR properly,
we know that the feature is safely migratable.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Message-Id: <20190125220606.4864-3-ehabkost@redhat.com>
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>

KVM has two bugs in the handling of MSR_IA32_ARCH_CAPABILITIES:

1) Linux commit commit 1eaafe91a0df ("kvm: x86: IA32_ARCH_CAPABILITIES
   is always supported") makes GET_SUPPORTED_CPUID return
   arch_capabilities even if running on SVM.  This makes "-cpu
   host,migratable=off" incorrectly expose arch_capabilities on CPUID on
   AMD hosts (where the MSR is not emulated by KVM).

2) KVM_GET_MSR_INDEX_LIST does not return MSR_IA32_ARCH_CAPABILITIES if
   the MSR is not supported by the host CPU.  This makes QEMU not
   initialize the MSR properly at kvm_put_msrs() on those hosts.

Work around both bugs on the QEMU side, by checking if the MSR
was returned by KVM_GET_MSR_INDEX_LIST before returning the
feature flag on kvm_arch_get_supported_cpuid().

This has the unfortunate side effect of making arch_capabilities
unavailable on hosts without hardware support for the MSR until bug #2
is fixed on KVM, but I can't see another way to work around bug #1
without that side effect.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Message-Id: <20190125220606.4864-2-ehabkost@redhat.com>
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>

Signed-off-by: NAlistair Francis <alistair.francis@wdc.com>
Signed-off-by: NPalmer Dabbelt <palmer@sifive.com>

Cc: Palmer Dabbelt <palmer@sifive.com>
Cc: Alistair Francis <Alistair.Francis@wdc.com>
Signed-off-by: NMichael Clark <mjc@sifive.com>
Signed-off-by: NAlistair Francis <alistair.francis@wdc.com>
Signed-off-by: NPalmer Dabbelt <palmer@sifive.com>

Cc: Palmer Dabbelt <palmer@sifive.com>
Cc: Alistair Francis <Alistair.Francis@wdc.com>
Signed-off-by: NMichael Clark <mjc@sifive.com>
Signed-off-by: NAlistair Francis <alistair.francis@wdc.com>
Signed-off-by: NPalmer Dabbelt <palmer@sifive.com>

If vectored interrupts are enabled (bits[1:0]
of mtvec/stvec == 1) then use the following
logic for trap entry address calculation:

 pc = mtvec + cause * 4

In addition to adding support for vectored interrupts
this patch simplifies the interrupt delivery logic
by making sync/async cause decoding and encoding
steps distinct.

The cause code and the sign bit indicating sync/async
is split at the beginning of the function and fixed
cause is renamed to cause. The MSB setting for async
traps is delayed until setting mcause/scause to allow
redundant variables to be eliminated. Some variables
are renamed for conciseness and moved so that decls
are at the start of the block.

Cc: Palmer Dabbelt <palmer@sifive.com>
Cc: Alistair Francis <Alistair.Francis@wdc.com>
Signed-off-by: NMichael Clark <mjc@sifive.com>
Signed-off-by: NAlistair Francis <alistair.francis@wdc.com>
Signed-off-by: NPalmer Dabbelt <palmer@sifive.com>

This effectively changes riscv_cpu_update_mip
from edge to level. i.e. cpu_interrupt or
cpu_reset_interrupt are called regardless of
the current interrupt level.

Fixes WFI doesn't return when a IPI is issued:

- https://github.com/riscv/riscv-qemu/issues/132

To test:

1) Apply RISC-V Linux CPU hotplug patch:

- http://lists.infradead.org/pipermail/linux-riscv/2018-May/000603.html

2) Enable CONFIG_CPU_HOTPLUG in linux .config

3) Try to offline and online cpus:

  echo 1 > /sys/devices/system/cpu/cpu2/online
  echo 0 > /sys/devices/system/cpu/cpu2/online
  echo 1 > /sys/devices/system/cpu/cpu2/online
Reported-by: NAtish Patra <atishp04@gmail.com>
Cc: Atish Patra <atishp04@gmail.com>
Cc: Alistair Francis <Alistair.Francis@wdc.com>
Signed-off-by: NMichael Clark <mjc@sifive.com>
Signed-off-by: NAlistair Francis <alistair.francis@wdc.com>
Signed-off-by: NPalmer Dabbelt <palmer@sifive.com>

This change checks elf_flags for EF_RISCV_RVE and if
present uses the RVE linux syscall ABI which uses t0
for the syscall number instead of a7.

Warn and exit if a non-RVE ABI binary is run on a
cpu with the RVE extension as it is incompatible.

Cc: Palmer Dabbelt <palmer@sifive.com>
Cc: Sagar Karandikar <sagark@eecs.berkeley.edu>
Cc: Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
Cc: Alistair Francis <Alistair.Francis@wdc.com>
Co-authored-by: NKito Cheng <kito.cheng@gmail.com>
Co-authored-by: NMichael Clark <mjc@sifive.com>
Signed-off-by: NMichael Clark <mjc@sifive.com>
Signed-off-by: NAlistair Francis <alistair.francis@wdc.com>
Signed-off-by: NPalmer Dabbelt <palmer@sifive.com>

We can't allow the supervisor to control SEIP as this would allow the
supervisor to clear a pending external interrupt which will result in
lost a interrupt in the case a PLIC is attached. The SEIP bit must be
hardware controlled when a PLIC is attached.

This logic was previously hard-coded so SEIP was always masked even
if no PLIC was attached. This patch adds riscv_cpu_claim_interrupts
so that the PLIC can register control of SEIP. In the case of models
without a PLIC (spike), the SEIP bit remains software controlled.

This interface allows for hardware control of supervisor timer and
software interrupts by other interrupt controller models.

Cc: Palmer Dabbelt <palmer@sifive.com>
Cc: Sagar Karandikar <sagark@eecs.berkeley.edu>
Cc: Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
Cc: Alistair Francis <Alistair.Francis@wdc.com>
Signed-off-by: NMichael Clark <mjc@sifive.com>
Signed-off-by: NAlistair Francis <alistair.francis@wdc.com>
Signed-off-by: NPalmer Dabbelt <palmer@sifive.com>

Signed-off-by: NAlistair Francis <alistair.francis@wdc.com>
Signed-off-by: NPalmer Dabbelt <palmer@sifive.com>

The gdb CSR xml file has registers in documentation order, not numerical
order, so we need a table to map the register numbers.  This also adds
fairly standard gdb hooks to access xml specified registers.

notice:
    The fpu xml from gdb 8.3 has unused register #, 65 and make first
    csr register # become 69. We register extra register on gdb to correct
    csr offset calculation
Signed-off-by: NJim Wilson <jimw@sifive.com>
Signed-off-by: NChih-Min Chao <chihmin.chao@sifive.com>
Reviewed-by: NAlistair Francis <alistair.francis@wdc.com>
Signed-off-by: NPalmer Dabbelt <palmer@sifive.com>

Add a debugger field to CPURISCVState.  Add riscv_csrrw_debug function
to set it.  Disable mode checks when debugger field true.
Signed-off-by: NJim Wilson <jimw@sifive.com>
Reviewed-by: NAlistair Francis <alistair.francis@wdc.com>
Message-Id: <20190212230903.9215-1-jimw@sifive.com>
Signed-off-by: NPalmer Dabbelt <palmer@sifive.com>

This adds some missing CSR_* register macros, and documents some as being
priv v1.9.1 specific.
Signed-off-by: NJim Wilson <jimw@sifive.com>
Reviewed-by: NAlistair Francis <alistair.francis@wdc.com>
Message-Id: <20190212230830.9160-1-jimw@sifive.com>
Signed-off-by: NPalmer Dabbelt <palmer@sifive.com>

The RAM device presents a memory region that should be handled
as an IO region and should not be pinned.

In the case of the vfio-pci, RAM device represents a MMIO BAR
and the memory region is not backed by pages hence
KVM_MEMORY_ENCRYPT_REG_REGION fails to lock the memory range.

Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1667249
Cc: Alex Williamson <alex.williamson@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NBrijesh Singh <brijesh.singh@amd.com>
Message-Id: <20190204222322.26766-3-brijesh.singh@amd.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

during the refactor to decodetree we removed the manual decoding that is
necessary for c.jal/c.addiw and removed the translation of c.flw/c.ld
and c.fsw/c.sd. This reintroduces the manual parsing and the
omited implementation.
Signed-off-by: NBastian Koppelmann <kbastian@mail.uni-paderborn.de>
Tested-by: NPalmer Dabbelt <palmer@sifive.com>
Reviewed-by: NAlistair Francis <alistair.francis@wdc.com>
Tested-by: NAlistair Francis <alistair.francis@wdc.com>
Signed-off-by: NPalmer Dabbelt <palmer@sifive.com>

Within a delay slot, we were squishing both DISAS_IAQ_N_STALE and
DISAS_IAQ_N_STALE_EXIT to DISAS_IAQ_N_UPDATED.  This lost the
required exit to the main loop, and could result in interrupts
never being delivered.
Tested-by: NSven Schnelle <svens@stackframe.org>
Reported-by: NSven Schnelle <svens@stackframe.org>
Signed-off-by: NRichard Henderson <richard.henderson@linaro.org>

These instructions do not trap when SVE is disabled in EL0,
causing them to be executed with wrong size information.
Signed-off-by: NAmir Charif <amir.charif@cea.fr>
Message-id: 1552579248-31025-1-git-send-email-amir.charif@cea.fr
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
[PMM: added 'target/arm' prefix to subject]
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

Some generic arch timer registers are Config-RW in the EL0,
which means the EL0 exception level can have write permission
if it is appropriately configured.

When VM access registers, QEMU firstly checks whether they have RW
permission, then check whether it is appropriately configured.
If they are defined to read only in EL0, even though they have been
appropriately configured, they still do not have write permission.
So need to add the write permission according to ARMV8 spec when
define it.
Signed-off-by: NDongjiu Geng <gengdongjiu@huawei.com>
Message-id: 1552395177-12608-1-git-send-email-gengdongjiu@huawei.com
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

decodetree handles all instructions now so the fallback is not necessary
anymore.
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
Signed-off-by: NBastian Koppelmann <kbastian@mail.uni-paderborn.de>
Signed-off-by: NPeer Adelt <peer.adelt@hni.uni-paderborn.de>

with all 16 bit insns moved to decodetree no path is falling back to
gen_system(), so we can remove it.
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
Signed-off-by: NBastian Koppelmann <kbastian@mail.uni-paderborn.de>
Signed-off-by: NPeer Adelt <peer.adelt@hni.uni-paderborn.de>

Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
Signed-off-by: NBastian Koppelmann <kbastian@mail.uni-paderborn.de>

Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
Signed-off-by: NBastian Koppelmann <kbastian@mail.uni-paderborn.de>
Signed-off-by: NPeer Adelt <peer.adelt@hni.uni-paderborn.de>