qemu.git
7 months agodisas: Cleanup plugin_disas
Richard Henderson [Thu, 10 Sep 2020 22:13:38 +0000 (15:13 -0700)] 
disas: Cleanup plugin_disas

Do not retain a GString in thread-local storage.  Allocate a
new one and free it on every invocation.  Do not g_strdup the
result; return the buffer from the GString.  Do not use
warn_report.

Using cs_disasm allocated memory via the &insn parameter, but
that was never freed.  Use cs_disasm_iter so that we use the
memory that we've already allocated, and so that we only try
to disassemble one insn, as desired.  Do not allocate 1k to
hold the bytes for a single instruction.

Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
7 months agodisas: Use qemu/bswap.h for bfd endian loads
Richard Henderson [Sun, 13 Sep 2020 21:33:57 +0000 (14:33 -0700)] 
disas: Use qemu/bswap.h for bfd endian loads

Use the routines we have already instead of open-coding.

Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
7 months agodisas: Clean up CPUDebug initialization
Richard Henderson [Thu, 10 Sep 2020 21:40:54 +0000 (14:40 -0700)] 
disas: Clean up CPUDebug initialization

Rename several functions, dropping "generic" and making "host"
vs "target" clearer.  Make a bunch of functions static that are
not used outside this file. Replace INIT_DISASSEMBLE_INFO with
a trio of functions.

Acked-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
7 months agodisas: Move host asm annotations to tb_gen_code
Richard Henderson [Thu, 10 Sep 2020 19:15:04 +0000 (12:15 -0700)] 
disas: Move host asm annotations to tb_gen_code

Instead of creating GStrings and passing them into log_disas,
just print the annotations directly in tb_gen_code.

Fix the annotations for the slow paths of the TB, after the
part implementing the final guest instruction.

Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
7 months agocapstone: Require version 4.0 from a system library
Richard Henderson [Mon, 21 Sep 2020 16:46:16 +0000 (09:46 -0700)] 
capstone: Require version 4.0 from a system library

We're about to use a portion of the 4.0 API.
Reject a system library version prior to that.

Tested-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
7 months agocapstone: Update to upstream "next" branch
Richard Henderson [Mon, 14 Sep 2020 23:02:02 +0000 (16:02 -0700)] 
capstone: Update to upstream "next" branch

This branch contains a number of improvements over master,
including making all of the disassembler data constant.

We are skipping past the 4.0 branchpoint, which changed
the location of the includes within the source directory.

Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
7 months agocapstone: Convert Makefile bits to meson bits
Richard Henderson [Sun, 13 Sep 2020 19:19:25 +0000 (12:19 -0700)] 
capstone: Convert Makefile bits to meson bits

There are better ways to do this, e.g. meson cmake subproject,
but that requires cmake 3.7 and some of our CI environments
only provide cmake 3.5.

Nor can we add a meson.build file to capstone/, because the git
submodule would then always report "untracked files".  Fixing that
would require creating our own branch on the qemu git mirror, at
which point we could just as easily create a native meson subproject.

Instead, build the library via the main meson.build.

This improves the current state of affairs in that we will re-link
the qemu executables against a changed libcapstone.a, which we wouldn't
do before-hand.  In addition, the use of the configuration header file
instead of command-line -DEFINES means that we will rebuild the
capstone objects with changes to meson.build.

Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
7 months agoMerge remote-tracking branch 'remotes/cohuck/tags/s390x-20201002' into staging
Peter Maydell [Fri, 2 Oct 2020 13:29:49 +0000 (14:29 +0100)] 
Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20201002' into staging

s390x update
- support extended sccb and diagnose 0x318
- implement additional instructions in tcg
- bug fixes

# gpg: Signature made Fri 02 Oct 2020 13:05:16 BST
# gpg:                using RSA key C3D0D66DC3624FF6A8C018CEDECF6B93C6F02FAF
# gpg:                issuer "cohuck@redhat.com"
# gpg: Good signature from "Cornelia Huck <conny@cornelia-huck.de>" [unknown]
# gpg:                 aka "Cornelia Huck <huckc@linux.vnet.ibm.com>" [full]
# gpg:                 aka "Cornelia Huck <cornelia.huck@de.ibm.com>" [full]
# gpg:                 aka "Cornelia Huck <cohuck@kernel.org>" [unknown]
# gpg:                 aka "Cornelia Huck <cohuck@redhat.com>" [unknown]
# Primary key fingerprint: C3D0 D66D C362 4FF6 A8C0  18CE DECF 6B93 C6F0 2FAF

* remotes/cohuck/tags/s390x-20201002:
  s390x/tcg: Implement CIPHER MESSAGE WITH AUTHENTICATION (KMA)
  s390x/tcg: We support Miscellaneous-Instruction-Extensions Facility 2
  s390x/tcg: Implement MULTIPLY SINGLE (MSC, MSGC, MSGRKC, MSRKC)
  s390x/tcg: Implement BRANCH INDIRECT ON CONDITION (BIC)
  s390x/tcg: Implement MULTIPLY HALFWORD (MGH)
  s390x/tcg: Implement MULTIPLY (MG, MGRK)
  s390x/tcg: Implement SUBTRACT HALFWORD (SGH)
  s390x/tcg: Implement ADD HALFWORD (AGH)
  s390x/cpumodel: S390_FEAT_MISC_INSTRUCTION_EXT -> S390_FEAT_MISC_INSTRUCTION_EXT2
  vfio-ccw: plug memory leak while getting region info
  s390x/tcg: Implement MONITOR CALL
  s390: guest support for diagnose 0x318
  s390/sclp: add extended-length sccb support for kvm guest
  s390/sclp: use cpu offset to locate cpu entries
  s390/sclp: check sccb len before filling in data
  s390/sclp: read sccb from mem based on provided length
  s390/sclp: rework sclp boundary checks
  s390/sclp: get machine once during read scp/cpu info
  hw/s390x/css: Remove double initialization

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
7 months agoMerge remote-tracking branch 'remotes/stsquad/tags/pull-testing-and-python-021020...
Peter Maydell [Fri, 2 Oct 2020 12:39:20 +0000 (13:39 +0100)] 
Merge remote-tracking branch 'remotes/stsquad/tags/pull-testing-and-python-021020-1' into staging

Python testing updates:

  - drop python 3.5 test from travis
  - replace Debian 9 containers with 10
  - increase cross build timeout
  - bump minimum python version in configure
  - move user plugins tests to gitlab
  - split deprecated builds into build and test

# gpg: Signature made Fri 02 Oct 2020 12:34:36 BST
# gpg:                using RSA key 6685AE99E75167BCAFC8DF35FBD0DB095A9E2A44
# gpg: Good signature from "Alex Bennée (Master Work Key) <alex.bennee@linaro.org>" [full]
# Primary key fingerprint: 6685 AE99 E751 67BC AFC8  DF35 FBD0 DB09 5A9E 2A44

* remotes/stsquad/tags/pull-testing-and-python-021020-1:
  gitlab: split deprecated job into build/check stages
  gitlab: move linux-user plugins test across to gitlab
  configure: Bump the minimum required Python version to 3.6
  gitlab-ci: Increase the timeout for the cross-compiler builds
  tests/docker: Remove old Debian 9 containers
  shippable.yml: Remove the Debian9-based MinGW cross-compiler tests
  tests/docker: Update the tricore container to debian 10
  gitlab-ci: Remove the Debian9-based containers and containers-layer3
  tests/docker: Use Fedora containers for MinGW cross-builds in the gitlab-CI
  travis.yml: Drop the Python 3.5 build
  travis.yml: Drop the superfluous Python 3.6 build
  travis.yml: Update Travis to use Bionic and Focal instead of Xenial
  travis.yml: Drop the default softmmu builds
  migration: Silence compiler warning in global_state_store_running()

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
7 months agos390x/tcg: Implement CIPHER MESSAGE WITH AUTHENTICATION (KMA)
David Hildenbrand [Mon, 28 Sep 2020 12:27:17 +0000 (14:27 +0200)] 
s390x/tcg: Implement CIPHER MESSAGE WITH AUTHENTICATION (KMA)

As with the other crypto functions, we only implement subcode 0 (query)
and no actual encryption/decryption. We now implement S390_FEAT_MSA_EXT_8.

Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20200928122717.30586-10-david@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
7 months agos390x/tcg: We support Miscellaneous-Instruction-Extensions Facility 2
David Hildenbrand [Mon, 28 Sep 2020 12:27:16 +0000 (14:27 +0200)] 
s390x/tcg: We support Miscellaneous-Instruction-Extensions Facility 2

We implement all relevant instructions.

Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20200928122717.30586-9-david@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
7 months agos390x/tcg: Implement MULTIPLY SINGLE (MSC, MSGC, MSGRKC, MSRKC)
David Hildenbrand [Mon, 28 Sep 2020 12:27:15 +0000 (14:27 +0200)] 
s390x/tcg: Implement MULTIPLY SINGLE (MSC, MSGC, MSGRKC, MSRKC)

We need new CC handling, determining the CC based on the intermediate
result (64bit for MSC and MSRKC, 128bit for MSGC and MSGRKC).

We want to store out2 ("low") after muls128 to r1, so add
"wout_out2_r1".

Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20200928122717.30586-8-david@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
7 months agos390x/tcg: Implement BRANCH INDIRECT ON CONDITION (BIC)
David Hildenbrand [Mon, 28 Sep 2020 12:27:14 +0000 (14:27 +0200)] 
s390x/tcg: Implement BRANCH INDIRECT ON CONDITION (BIC)

Just like BRANCH ON CONDITION - however the address is read from memory
(always 8 bytes are read), we have to wrap the address manually. The
address is read using current CPU DAT/address-space controls, just like
ordinary data.

Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20200928122717.30586-7-david@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
7 months agos390x/tcg: Implement MULTIPLY HALFWORD (MGH)
David Hildenbrand [Mon, 28 Sep 2020 12:27:13 +0000 (14:27 +0200)] 
s390x/tcg: Implement MULTIPLY HALFWORD (MGH)

Just like MULTIPLY HALFWORD IMMEDIATE (MGHI), only the second operand
(signed 16 bit) comes from memory.

Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20200928122717.30586-6-david@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
7 months agos390x/tcg: Implement MULTIPLY (MG, MGRK)
David Hildenbrand [Mon, 28 Sep 2020 12:27:12 +0000 (14:27 +0200)] 
s390x/tcg: Implement MULTIPLY (MG, MGRK)

Multiply two signed 64bit values and store the 128bit result in r1 (0-63)
and r1 + 1 (64-127).

Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20200928122717.30586-5-david@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
7 months agos390x/tcg: Implement SUBTRACT HALFWORD (SGH)
David Hildenbrand [Mon, 28 Sep 2020 12:27:11 +0000 (14:27 +0200)] 
s390x/tcg: Implement SUBTRACT HALFWORD (SGH)

Easy to wire up.

Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20200928122717.30586-4-david@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
7 months agos390x/tcg: Implement ADD HALFWORD (AGH)
David Hildenbrand [Mon, 28 Sep 2020 12:27:10 +0000 (14:27 +0200)] 
s390x/tcg: Implement ADD HALFWORD (AGH)

Easy, just like ADD HALFWORD IMMEDIATE (AGHI).

Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20200928122717.30586-3-david@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
7 months agos390x/cpumodel: S390_FEAT_MISC_INSTRUCTION_EXT -> S390_FEAT_MISC_INSTRUCTION_EXT2
David Hildenbrand [Mon, 28 Sep 2020 12:27:09 +0000 (14:27 +0200)] 
s390x/cpumodel: S390_FEAT_MISC_INSTRUCTION_EXT -> S390_FEAT_MISC_INSTRUCTION_EXT2

Let's avoid confusion with the "Miscellaneous-Instruction-Extensions
Facility 1"

Suggested-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>
Message-Id: <20200928122717.30586-2-david@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
7 months agovfio-ccw: plug memory leak while getting region info
Cornelia Huck [Mon, 28 Sep 2020 10:17:01 +0000 (12:17 +0200)] 
vfio-ccw: plug memory leak while getting region info

vfio_get_dev_region_info() unconditionally allocates memory
for a passed-in vfio_region_info structure (and does not re-use
an already allocated structure). Therefore, we have to free
the structure we pass to that function in vfio_ccw_get_region()
for every region we successfully obtained information for.

Fixes: 8fadea24de4e ("vfio-ccw: support async command subregion")
Fixes: 46ea3841edaf ("vfio-ccw: Add support for the schib region")
Fixes: f030532f2ad6 ("vfio-ccw: Add support for the CRW region and IRQ")
Reported-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Eric Farman <farman@linux.ibm.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20200928101701.13540-1-cohuck@redhat.com>

7 months agos390x/tcg: Implement MONITOR CALL
David Hildenbrand [Fri, 18 Sep 2020 08:51:22 +0000 (10:51 +0200)] 
s390x/tcg: Implement MONITOR CALL

Recent upstream Linux uses the MONITOR CALL instruction for things like
BUG_ON() and WARN_ON(). We currently inject an operation exception when
we hit a MONITOR CALL instruction - which is wrong, as the instruction
is not glued to specific CPU features.

Doing a simple WARN_ON_ONCE() currently results in a panic:
  [   18.162801] illegal operation: 0001 ilc:2 [#1] SMP
  [   18.162889] Modules linked in:
  [...]
  [   18.165476] Kernel panic - not syncing: Fatal exception: panic_on_oops

With a proper implementation, we now get:
  [   18.242754] ------------[ cut here ]------------
  [   18.242855] WARNING: CPU: 7 PID: 1 at init/main.c:1534 [...]
  [   18.242919] Modules linked in:
  [...]
  [   18.246262] ---[ end trace a420477d71dc97b4 ]---
  [   18.259014] Freeing unused kernel memory: 4220K

Reported-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20200918085122.26132-1-david@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
7 months agos390: guest support for diagnose 0x318
Collin Walling [Tue, 15 Sep 2020 19:44:16 +0000 (15:44 -0400)] 
s390: guest support for diagnose 0x318

DIAGNOSE 0x318 (diag318) is an s390 instruction that allows the storage
of diagnostic information that is collected by the firmware in the case
of hardware/firmware service events.

QEMU handles the instruction by storing the info in the CPU state. A
subsequent register sync will communicate the data to the hypervisor.

QEMU handles the migration via a VM State Description.

This feature depends on the Extended-Length SCCB (els) feature. If
els is not present, then a warning will be printed and the SCLP bit
that allows the Linux kernel to execute the instruction will not be
set.

Availability of this instruction is determined by byte 134 (aka fac134)
bit 0 of the SCLP Read Info block. This coincidentally expands into the
space used for CPU entries, which means VMs running with the diag318
capability may not be able to read information regarding all CPUs
unless the guest kernel supports an extended-length SCCB.

This feature is not supported in protected virtualization mode.

Signed-off-by: Collin Walling <walling@linux.ibm.com>
Acked-by: Janosch Frank <frankja@linux.ibm.com>
Acked-by: Thomas Huth <thuth@redhat.com>
Acked-by: David Hildenbrand <david@redhat.com>
Acked-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Message-Id: <20200915194416.107460-9-walling@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
7 months agos390/sclp: add extended-length sccb support for kvm guest
Collin Walling [Tue, 15 Sep 2020 19:44:14 +0000 (15:44 -0400)] 
s390/sclp: add extended-length sccb support for kvm guest

As more features and facilities are added to the Read SCP Info (RSCPI)
response, more space is required to store them. The space used to store
these new features intrudes on the space originally used to store CPU
entries. This means as more features and facilities are added to the
RSCPI response, less space can be used to store CPU entries.

With the Extended-Length SCCB (ELS) facility, a KVM guest can execute
the RSCPI command and determine if the SCCB is large enough to store a
complete reponse. If it is not large enough, then the required length
will be set in the SCCB header.

The caller of the SCLP command is responsible for creating a
large-enough SCCB to store a complete response. Proper checking should
be in place, and the caller should execute the command once-more with
the large-enough SCCB.

This facility also enables an extended SCCB for the Read CPU Info
(RCPUI) command.

When this facility is enabled, the boundary violation response cannot
be a result from the RSCPI, RSCPI Forced, or RCPUI commands.

In order to tolerate kernels that do not yet have full support for this
feature, a "fixed" offset to the start of the CPU Entries within the
Read SCP Info struct is set to allow for the original 248 max entries
when this feature is disabled.

Additionally, this is introduced as a CPU feature to protect the guest
from migrating to a machine that does not support storing an extended
SCCB. This could otherwise hinder the VM from being able to read all
available CPU entries after migration (such as during re-ipl).

Signed-off-by: Collin Walling <walling@linux.ibm.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Acked-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Message-Id: <20200915194416.107460-7-walling@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
7 months agos390/sclp: use cpu offset to locate cpu entries
Collin Walling [Tue, 15 Sep 2020 19:44:13 +0000 (15:44 -0400)] 
s390/sclp: use cpu offset to locate cpu entries

The start of the CPU entry region in the Read SCP Info response data is
denoted by the offset_cpu field. As such, QEMU needs to begin creating
entries at this address.

This is in preparation for when Read SCP Info inevitably introduces new
bytes that push the start of the CPUEntry field further away.

Read CPU Info is unlikely to ever change, so let's not bother
accounting for the offset there.

Signed-off-by: Collin Walling <walling@linux.ibm.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Message-Id: <20200915194416.107460-6-walling@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
7 months agos390/sclp: check sccb len before filling in data
Collin Walling [Tue, 15 Sep 2020 19:44:12 +0000 (15:44 -0400)] 
s390/sclp: check sccb len before filling in data

The SCCB must be checked for a sufficient length before it is filled
with any data. If the length is insufficient, then the SCLP command
is suppressed and the proper response code is set in the SCCB header.

While we're at it, let's cleanup the length check by placing the
calculation inside a macro.

Fixes: 832be0d8a3bb ("s390x: sclp: Report insufficient SCCB length")
Signed-off-by: Collin Walling <walling@linux.ibm.com>
Reviewed-by: Janosch Frank <frankja@linux.ibm.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Message-Id: <20200915194416.107460-5-walling@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
7 months agos390/sclp: read sccb from mem based on provided length
Collin Walling [Tue, 15 Sep 2020 19:44:11 +0000 (15:44 -0400)] 
s390/sclp: read sccb from mem based on provided length

The header contained within the SCCB passed to the SCLP service call
contains the actual length of the SCCB. Instead of allocating a static
4K size for the work sccb, let's allow for a variable size determined
by the value in the header. The proper checks are already in place to
ensure the SCCB length is sufficent to store a full response and that
the length does not cross any explicitly-set boundaries.

Signed-off-by: Collin Walling <walling@linux.ibm.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Message-Id: <20200915194416.107460-4-walling@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
7 months agos390/sclp: rework sclp boundary checks
Collin Walling [Tue, 15 Sep 2020 19:44:10 +0000 (15:44 -0400)] 
s390/sclp: rework sclp boundary checks

Rework the SCLP boundary check to account for different SCLP commands
(eventually) allowing different boundary sizes.

Signed-off-by: Collin Walling <walling@linux.ibm.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Acked-by: Janosch Frank <frankja@linux.ibm.com>
Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Message-Id: <20200915194416.107460-3-walling@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
7 months agos390/sclp: get machine once during read scp/cpu info
Collin Walling [Tue, 15 Sep 2020 19:44:09 +0000 (15:44 -0400)] 
s390/sclp: get machine once during read scp/cpu info

Functions within read scp/cpu info will need access to the machine
state. Let's make a call to retrieve the machine state once and
pass the appropriate data to the respective functions.

Signed-off-by: Collin Walling <walling@linux.ibm.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Janosch Frank <frankja@linux.ibm.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Message-Id: <20200915194416.107460-2-walling@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
7 months agohw/s390x/css: Remove double initialization
Philippe Mathieu-Daudé [Mon, 7 Sep 2020 02:40:20 +0000 (04:40 +0200)] 
hw/s390x/css: Remove double initialization

Fix eventual copy/paste mistake introduced in commit bc994b74ea
("s390x/css: Use static initialization for channel_subsys fields").

Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20200907024020.854465-1-philmd@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
7 months agogitlab: split deprecated job into build/check stages
Alex Bennée [Fri, 2 Oct 2020 09:15:38 +0000 (10:15 +0100)] 
gitlab: split deprecated job into build/check stages

While the job is pretty fast for only a few targets we still want to
catch breakage of the build. By splitting the test step we can
allow_failures for that while still ensuring we don't miss the build
breaking.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20201002091538.3017-1-alex.bennee@linaro.org>

7 months agogitlab: move linux-user plugins test across to gitlab
Alex Bennée [Fri, 2 Oct 2020 10:32:23 +0000 (11:32 +0100)] 
gitlab: move linux-user plugins test across to gitlab

Even with the recent split moving beefier plugins into contrib and
dropping them from the check-tcg tests we are still hitting time
limits. This possibly points to a slow down of --debug-tcg but seeing
as we are migrating stuff to gitlab we might as well move there and
bump the timeout.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20201002103223.24022-1-alex.bennee@linaro.org>

7 months agoconfigure: Bump the minimum required Python version to 3.6
Thomas Huth [Fri, 25 Sep 2020 15:40:27 +0000 (16:40 +0100)] 
configure: Bump the minimum required Python version to 3.6

All our supported build platforms have Python 3.6 or newer nowadays, and
there are some useful features in Python 3.6 which are not available in
3.5 yet (e.g. the type hint annotations which will allow us to statically
type the QAPI parser), so let's bump the minimum Python version to 3.6 now.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20200923162908.95372-1-thuth@redhat.com>
Message-Id: <20200925154027.12672-16-alex.bennee@linaro.org>

7 months agogitlab-ci: Increase the timeout for the cross-compiler builds
Thomas Huth [Fri, 25 Sep 2020 15:40:26 +0000 (16:40 +0100)] 
gitlab-ci: Increase the timeout for the cross-compiler builds

Some of the cross-compiler builds (the mips build and the win64 build
for example) are quite slow and sometimes hit the 1h time limit.
Increase the limit a little bit to make sure that we do not get failures
in the CI runs just because of some few minutes.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20200921174320.46062-7-thuth@redhat.com>
Message-Id: <20200925154027.12672-15-alex.bennee@linaro.org>

7 months agotests/docker: Remove old Debian 9 containers
Thomas Huth [Fri, 25 Sep 2020 15:40:25 +0000 (16:40 +0100)] 
tests/docker: Remove old Debian 9 containers

We do not support Debian 9 in QEMU anymore, and the Debian 9 containers
are now no longer used in the gitlab-CI. Time to remove them.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20200921174320.46062-6-thuth@redhat.com>
Message-Id: <20200925154027.12672-14-alex.bennee@linaro.org>

7 months agoshippable.yml: Remove the Debian9-based MinGW cross-compiler tests
Thomas Huth [Fri, 25 Sep 2020 15:40:24 +0000 (16:40 +0100)] 
shippable.yml: Remove the Debian9-based MinGW cross-compiler tests

We're not supporting Debian 9 anymore, and we are now testing
MinGW cross-compiler builds in the gitlab-CI, too, so we do not
really need these jobs in the shippable.yml anymore.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20200921174320.46062-5-thuth@redhat.com>
Message-Id: <20200925154027.12672-13-alex.bennee@linaro.org>

7 months agotests/docker: Update the tricore container to debian 10
Thomas Huth [Fri, 25 Sep 2020 15:40:23 +0000 (16:40 +0100)] 
tests/docker: Update the tricore container to debian 10

We do not support Debian 9 anymore, thus update the Tricore container
to Debian 10 now.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20200921174320.46062-4-thuth@redhat.com>
Message-Id: <20200925154027.12672-12-alex.bennee@linaro.org>

7 months agogitlab-ci: Remove the Debian9-based containers and containers-layer3
Thomas Huth [Fri, 25 Sep 2020 15:40:22 +0000 (16:40 +0100)] 
gitlab-ci: Remove the Debian9-based containers and containers-layer3

According to our support policy, Debian 9 is not supported by the
QEMU project anymore. Since we now switched the MinGW cross-compiler
builds to Fedora, we do not need these Debian9-based containers
in the gitlab-CI anymore, and can now also get rid of the "layer3"
container build stage this way.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20200921174320.46062-3-thuth@redhat.com>
Message-Id: <20200925154027.12672-11-alex.bennee@linaro.org>

7 months agotests/docker: Use Fedora containers for MinGW cross-builds in the gitlab-CI
Thomas Huth [Fri, 25 Sep 2020 15:40:21 +0000 (16:40 +0100)] 
tests/docker: Use Fedora containers for MinGW cross-builds in the gitlab-CI

According to our support policy, we do not support Debian 9 in QEMU
anymore, and we only support building the Windows binaries with a
very recent version of the MinGW toolchain. So we should not test
the MinGW cross-compilation with Debian 9 anymore, but switch to
something newer like Fedora. To do this, we need a separate Fedora
container for each build that provides the QEMU_CONFIGURE_OPTS
environment variable.
Unfortunately, the MinGW 64-bit compiler seems to be a little bit
slow, so we also have to disable some features like "capstone" in the
build here to make sure that the CI pipelines still finish within a
reasonable amount of time.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20200921174320.46062-2-thuth@redhat.com>
Message-Id: <20200925154027.12672-10-alex.bennee@linaro.org>

7 months agotravis.yml: Drop the Python 3.5 build
Thomas Huth [Fri, 25 Sep 2020 15:40:20 +0000 (16:40 +0100)] 
travis.yml: Drop the Python 3.5 build

We are soon going to remove the support for Python 3.5. So remove
the CI job now.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20200922070441.48844-1-thuth@redhat.com>
Message-Id: <20200925154027.12672-9-alex.bennee@linaro.org>

7 months agotravis.yml: Drop the superfluous Python 3.6 build
Thomas Huth [Fri, 25 Sep 2020 15:40:19 +0000 (16:40 +0100)] 
travis.yml: Drop the superfluous Python 3.6 build

Python 3.6 is already the default Python in the jobs that are based
on Ubuntu Bionic, so it does not make much sense to test this again
separately.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20200918103430.297167-7-thuth@redhat.com>
Message-Id: <20200925154027.12672-8-alex.bennee@linaro.org>

7 months agotravis.yml: Update Travis to use Bionic and Focal instead of Xenial
Thomas Huth [Fri, 25 Sep 2020 15:40:18 +0000 (16:40 +0100)] 
travis.yml: Update Travis to use Bionic and Focal instead of Xenial

According to our support policy, we do not support Xenial anymore.
Time to switch the bigger parts of the builds to Focal instead.
Some few jobs have to be updated to Bionic instead, since they are
currently still failing on Focal otherwise. Also "--disable-pie" is
causing linker problems with newer versions of Ubuntu ... so remove
that switch from the jobs now (we still test it in a gitlab CI job,
so we don't lose much test coverage here).

Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Tested-by: Cleber Rosa <crosa@redhat.com>
Reviewed-by: Cleber Rosa <crosa@redhat.com>
Message-Id: <20200918103430.297167-6-thuth@redhat.com>
Message-Id: <20200925154027.12672-7-alex.bennee@linaro.org>

7 months agotravis.yml: Drop the default softmmu builds
Thomas Huth [Fri, 25 Sep 2020 15:40:17 +0000 (16:40 +0100)] 
travis.yml: Drop the default softmmu builds

The total runtime of all Travis jobs is very long and we are testing
all softmmu targets in the gitlab-CI already - so we can speed up the
Travis testing a little bit by not testing the softmmu targets here
anymore.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Cleber Rosa <crosa@redhat.com>
Acked-by: Alex Bennée <alex.bennee@linaro.org>
Acked-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20200918103430.297167-5-thuth@redhat.com>
Message-Id: <20200925154027.12672-6-alex.bennee@linaro.org>

7 months agomigration: Silence compiler warning in global_state_store_running()
Thomas Huth [Fri, 25 Sep 2020 15:40:16 +0000 (16:40 +0100)] 
migration: Silence compiler warning in global_state_store_running()

GCC 9.3.0 on Ubuntu complains:

In file included from /usr/include/string.h:495,
                 from /home/travis/build/huth/qemu/include/qemu/osdep.h:87,
                 from ../migration/global_state.c:13:
In function ‘strncpy’,
    inlined from ‘global_state_store_running’ at ../migration/global_state.c:47:5:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: error:
 ‘__builtin_strncpy’ specified bound 100 equals destination size [-Werror=stringop-truncation]
  106 |   return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest));
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

... but we apparently really want to do a strncpy here - the size is already
checked with the assert() statement right in front of it. To silence the
warning, simply replace it with our strpadcpy() function.

Suggested-by: Philippe Mathieu-Daudé <philmd@redhat.com> (two years ago)
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20200918103430.297167-4-thuth@redhat.com>
Message-Id: <20200925154027.12672-5-alex.bennee@linaro.org>

7 months agoMerge remote-tracking branch 'remotes/jsnow-gitlab/tags/ide-pull-request' into staging
Peter Maydell [Thu, 1 Oct 2020 18:55:10 +0000 (19:55 +0100)] 
Merge remote-tracking branch 'remotes/jsnow-gitlab/tags/ide-pull-request' into staging

Pull request

# gpg: Signature made Thu 01 Oct 2020 18:41:05 BST
# gpg:                using RSA key F9B7ABDBBCACDF95BE76CBD07DEF8106AAFC390E
# gpg: Good signature from "John Snow (John Huston) <jsnow@redhat.com>" [full]
# Primary key fingerprint: FAEB 9711 A12C F475 812F  18F2 88A9 064D 1835 61EB
#      Subkey fingerprint: F9B7 ABDB BCAC DF95 BE76  CBD0 7DEF 8106 AAFC 390E

* remotes/jsnow-gitlab/tags/ide-pull-request:
  ide: cancel pending callbacks on SRST
  ide: clear interrupt on command write
  ide: remove magic constants from the device register
  ide: reorder set/get sector functions
  ide: model HOB correctly
  ide: don't tamper with the device register
  ide: rename cmd_write to ctrl_write
  hw/ide/ahci: Do not dma_memory_unmap(NULL)
  MAINTAINERS: Update my git address

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
7 months agoide: cancel pending callbacks on SRST
John Snow [Fri, 24 Jul 2020 05:23:00 +0000 (01:23 -0400)] 
ide: cancel pending callbacks on SRST

The SRST implementation did not keep up with the rest of IDE; it is
possible to perform a weak reset on an IDE device to remove the BSY/DRQ
bits, and then issue writes to the control/device registers which can
cause chaos with the state machine.

Fix that by actually performing a real reset.

Reported-by: Alexander Bulekov <alxndr@bu.edu>
Fixes: https://bugs.launchpad.net/qemu/+bug/1878253
Fixes: https://bugs.launchpad.net/qemu/+bug/1887303
Fixes: https://bugs.launchpad.net/qemu/+bug/1887309
Signed-off-by: John Snow <jsnow@redhat.com>
7 months agoide: clear interrupt on command write
John Snow [Fri, 24 Jul 2020 05:22:59 +0000 (01:22 -0400)] 
ide: clear interrupt on command write

Not known to fix any bug, but I couldn't help but notice that ATA
specifies that writing to this register should clear an interrupt.

ATA7: Section 5.3.3 (Command register - Effect)
ATA6: Section 7.4.4 (Command register - Effect)
ATA5: Section 7.4.4 (Command register - Effect)
ATA4: Section 7.4.4 (Command register - Effect)
ATA3: Section 5.2.2 (Command register)

Other editions: try searching for the phrase "Writing this register".

Signed-off-by: John Snow <jsnow@redhat.com>
7 months agoide: remove magic constants from the device register
John Snow [Fri, 24 Jul 2020 05:22:58 +0000 (01:22 -0400)] 
ide: remove magic constants from the device register

(In QEMU, we call this the "select" register.)

My memory isn't good enough to memorize what these magic runes
do. Label them to prevent mixups from happening in the future.

Side note: I assume it's safe to always set 0xA0 even though ATA2 claims
these bits are reserved, because ATA3 immediately reinstated that these
bits should be always on. ATA4 and subsequent specs only claim that the
fields are obsolete, so I assume it's safe to leave these set and that
it should work with the widest array of guests.

Signed-off-by: John Snow <jsnow@redhat.com>
7 months agoide: reorder set/get sector functions
John Snow [Fri, 24 Jul 2020 05:22:57 +0000 (01:22 -0400)] 
ide: reorder set/get sector functions

Reorder these just a pinch to make them more obvious at a glance what
the addressing mode is.

Signed-off-by: John Snow <jsnow@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
7 months agoide: model HOB correctly
John Snow [Fri, 24 Jul 2020 05:22:56 +0000 (01:22 -0400)] 
ide: model HOB correctly

I have been staring at this FIXME for years and I never knew what it
meant. I finally stumbled across it!

When writing to the command registers, the old value is shifted into a
HOB copy of the register and the new value is written into the primary
register. When reading registers, the value retrieved is dependent on
the HOB bit in the CONTROL register.

By setting bit 7 (0x80) in CONTROL, any register read will, if it has
one, yield the HOB value for that register instead.

Our code has a problem: We were using bit 7 of the DEVICE register to
model this. We use bus->cmd roughly as the control register already, as
it stores the value from ide_ctrl_write.

Lastly, all command register writes reset the HOB, so fix that, too.

Signed-off-by: John Snow <jsnow@redhat.com>
7 months agoide: don't tamper with the device register
John Snow [Fri, 24 Jul 2020 05:22:55 +0000 (01:22 -0400)] 
ide: don't tamper with the device register

In real ISA operation, register writes go out to an entire bus channel
and all listening devices receive the write. The devices do not toggle
the DEV bit based on their own configuration, nor does the HBA
intermediate or tamper with that value.

The reality of the matter is that DEV0/DEV1 accordingly will react to
command register writes based on whether or not the device was selected.

This does not fix a known bug, but it makes the code slightly simpler
and more obvious.

Signed-off-by: John Snow <jsnow@redhat.com>
7 months agoide: rename cmd_write to ctrl_write
John Snow [Fri, 24 Jul 2020 05:22:54 +0000 (01:22 -0400)] 
ide: rename cmd_write to ctrl_write

It's the Control register, part of the Control block -- Command is
misleading here. Rename all related functions and constants.

Signed-off-by: John Snow <jsnow@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
7 months agohw/ide/ahci: Do not dma_memory_unmap(NULL)
Philippe Mathieu-Daudé [Sat, 18 Jul 2020 07:28:54 +0000 (09:28 +0200)] 
hw/ide/ahci: Do not dma_memory_unmap(NULL)

libFuzzer triggered the following assertion:

  cat << EOF | qemu-system-i386 -M pc-q35-5.0 \
    -nographic -monitor none -serial none -qtest stdio
  outl 0xcf8 0x8000fa24
  outl 0xcfc 0xe1068000
  outl 0xcf8 0x8000fa04
  outw 0xcfc 0x7
  outl 0xcf8 0x8000fb20
  write 0xe1068304 0x1 0x21
  write 0xe1068318 0x1 0x21
  write 0xe1068384 0x1 0x21
  write 0xe1068398 0x2 0x21
  EOF
  qemu-system-i386: exec.c:3621: address_space_unmap: Assertion `mr != NULL' failed.
  Aborted (core dumped)

This is because we don't check the return value from dma_memory_map()
which can return NULL, then we call dma_memory_unmap(NULL) which is
illegal. Fix by only unmap if the value is not NULL (and the size is
not the expected one).

Cc: qemu-stable@nongnu.org
Reported-by: Alexander Bulekov <alxndr@bu.edu>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-id: 20200718072854.7001-1-f4bug@amsat.org
Fixes: f6ad2e32f8 ("ahci: add ahci emulation")
BugLink: https://bugs.launchpad.net/qemu/+bug/1884693
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: John Snow <jsnow@redhat.com>
Signed-off-by: John Snow <jsnow@redhat.com>
7 months agoMAINTAINERS: Update my git address
John Snow [Thu, 1 Oct 2020 16:24:01 +0000 (12:24 -0400)] 
MAINTAINERS: Update my git address

I am switching from github to gitlab.

Signed-off-by: John Snow <jsnow@redhat.com>
7 months agoMerge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20201001' into...
Peter Maydell [Thu, 1 Oct 2020 15:41:30 +0000 (16:41 +0100)] 
Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20201001' into staging

target-arm queue:
 * Make isar_feature_aa32_fp16_arith() handle M-profile
 * Fix SVE splice
 * Fix SVE LDR/STR
 * Remove ignore_memory_transaction_failures on the raspi2
 * raspi: Various cleanup/refactoring

# gpg: Signature made Thu 01 Oct 2020 15:46:47 BST
# gpg:                using RSA key E1A5C593CD419DE28E8315CF3C2525ED14360CDE
# gpg:                issuer "peter.maydell@linaro.org"
# gpg: Good signature from "Peter Maydell <peter.maydell@linaro.org>" [ultimate]
# gpg:                 aka "Peter Maydell <pmaydell@gmail.com>" [ultimate]
# gpg:                 aka "Peter Maydell <pmaydell@chiark.greenend.org.uk>" [ultimate]
# Primary key fingerprint: E1A5 C593 CD41 9DE2 8E83  15CF 3C25 25ED 1436 0CDE

* remotes/pmaydell/tags/pull-target-arm-20201001:
  hw/arm/raspi: Remove use of the 'version' value in the board code
  hw/arm/raspi: Use RaspiProcessorId to set the firmware load address
  hw/arm/raspi: Introduce RaspiProcessorId enum
  hw/arm/raspi: Use more specific machine names
  hw/arm/raspi: Avoid using TypeInfo::class_data pointer
  hw/arm/raspi: Move arm_boot_info structure to RaspiMachineState
  hw/arm/raspi: Load the firmware on the first core
  hw/arm/raspi: Display the board revision in the machine description
  hw/arm/raspi: Remove ignore_memory_transaction_failures on the raspi2
  hw/arm/bcm2835: Add more unimplemented peripherals
  hw/arm/raspi: Define various blocks base addresses
  target/arm: Fix SVE splice
  target/arm: Fix sve ldr/str
  target/arm: Make isar_feature_aa32_fp16_arith() handle M-profile
  target/arm: Add ID register values for Cortex-M0
  hw/intc/armv7m_nvic: Only show ID register values for Main Extension CPUs
  target/arm: Move id_pfr0, id_pfr1 into ARMISARegisters
  target/arm: Replace ARM_FEATURE_PXN with ID_MMFR0.VMSA check

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
7 months agohw/arm/raspi: Remove use of the 'version' value in the board code
Philippe Mathieu-Daudé [Thu, 24 Sep 2020 11:18:08 +0000 (13:18 +0200)] 
hw/arm/raspi: Remove use of the 'version' value in the board code

We expected the 'version' ID to match the board processor ID,
but this is not always true (for example boards with revision
id 0xa02042/0xa22042 are Raspberry Pi 2 with a BCM2837 SoC).
This was not important because we were not modelling them, but
since the recent refactor now allow to model these boards, it
is safer to check the processor id directly. Remove the version
check.

Suggested-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Luc Michel <luc.michel@greensocs.com>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-id: 20200924111808.77168-9-f4bug@amsat.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
7 months agohw/arm/raspi: Use RaspiProcessorId to set the firmware load address
Philippe Mathieu-Daudé [Thu, 24 Sep 2020 11:18:07 +0000 (13:18 +0200)] 
hw/arm/raspi: Use RaspiProcessorId to set the firmware load address

The firmware load address depends on the SoC ("processor id") used,
not on the version of the board.

Suggested-by: Luc Michel <luc.michel@greensocs.com>
Reviewed-by: Luc Michel <luc.michel@greensocs.com>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-id: 20200924111808.77168-8-f4bug@amsat.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
7 months agohw/arm/raspi: Introduce RaspiProcessorId enum
Philippe Mathieu-Daudé [Thu, 24 Sep 2020 11:18:06 +0000 (13:18 +0200)] 
hw/arm/raspi: Introduce RaspiProcessorId enum

As we only support a reduced set of the REV_CODE_PROCESSOR id
encoded in the board revision, define the PROCESSOR_ID values
as an enum. We can simplify the board_soc_type and cores_count
methods.

Reviewed-by: Luc Michel <luc.michel@greensocs.com>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-id: 20200924111808.77168-7-f4bug@amsat.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
7 months agohw/arm/raspi: Use more specific machine names
Philippe Mathieu-Daudé [Thu, 24 Sep 2020 11:18:05 +0000 (13:18 +0200)] 
hw/arm/raspi: Use more specific machine names

Now that we can instantiate different machines based on their
board_rev register value, we can have various raspi2 and raspi3.

In commit fc78a990ec103 we corrected the machine description.
Correct the machine names too. For backward compatibility, add
an alias to the previous generic name.

Reviewed-by: Luc Michel <luc.michel@greensocs.com>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-id: 20200924111808.77168-6-f4bug@amsat.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
7 months agohw/arm/raspi: Avoid using TypeInfo::class_data pointer
Philippe Mathieu-Daudé [Thu, 24 Sep 2020 11:18:04 +0000 (13:18 +0200)] 
hw/arm/raspi: Avoid using TypeInfo::class_data pointer

Using class_data pointer to create a MachineClass is not
the recommended way anymore. The correct way is to open-code
the MachineClass::fields in the class_init() method.

We can not use TYPE_RASPI_MACHINE::class_base_init() because
it is called *before* each machine class_init(), therefore the
board_rev field is not populated. We have to manually call
raspi_machine_class_common_init() for each machine.

This partly reverts commit a03bde3674e.

Suggested-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-id: 20200924111808.77168-5-f4bug@amsat.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
7 months agohw/arm/raspi: Move arm_boot_info structure to RaspiMachineState
Philippe Mathieu-Daudé [Thu, 24 Sep 2020 11:18:03 +0000 (13:18 +0200)] 
hw/arm/raspi: Move arm_boot_info structure to RaspiMachineState

The arm_boot_info structure belong to the machine,
move it to RaspiMachineState.

Reviewed-by: Luc Michel <luc.michel@greensocs.com>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-id: 20200924111808.77168-4-f4bug@amsat.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
7 months agohw/arm/raspi: Load the firmware on the first core
Philippe Mathieu-Daudé [Thu, 24 Sep 2020 11:18:02 +0000 (13:18 +0200)] 
hw/arm/raspi: Load the firmware on the first core

The 'first_cpu' is more a QEMU accelerator-related concept
than a variable the machine requires to use.
Since the machine is aware of its CPUs, directly use the
first one to load the firmware.

Reviewed-by: Luc Michel <luc.michel@greensocs.com>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-id: 20200924111808.77168-3-f4bug@amsat.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
7 months agohw/arm/raspi: Display the board revision in the machine description
Philippe Mathieu-Daudé [Thu, 24 Sep 2020 11:18:01 +0000 (13:18 +0200)] 
hw/arm/raspi: Display the board revision in the machine description

Display the board revision in the machine description.

Before:

  $ qemu-system-aarch64 -M help | fgrep raspi
  raspi2               Raspberry Pi 2B
  raspi3               Raspberry Pi 3B

After:

  raspi2               Raspberry Pi 2B (revision 1.1)
  raspi3               Raspberry Pi 3B (revision 1.2)

Reviewed-by: Luc Michel <luc.michel@greensocs.com>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-id: 20200924111808.77168-2-f4bug@amsat.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
7 months agohw/arm/raspi: Remove ignore_memory_transaction_failures on the raspi2
Philippe Mathieu-Daudé [Mon, 21 Sep 2020 03:47:29 +0000 (05:47 +0200)] 
hw/arm/raspi: Remove ignore_memory_transaction_failures on the raspi2

Commit 1c3db49d39 added the raspi3, which uses the same peripherals
than the raspi2 (but with different ARM cores). The raspi3 was
introduced without the ignore_memory_transaction_failures flag.
Almost 2 years later, the machine is usable running U-Boot and
Linux.
In commit 00cbd5bd74 we mapped a lot of unimplemented devices,
commit d442d95f added thermal block and commit 0e5bbd7406 the
system timer.
As we are happy with the raspi3, let's remove this flag on the
raspi2.

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Luc Michel <luc.michel@greensocs.com>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-id: 20200921034729.432931-4-f4bug@amsat.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
7 months agohw/arm/bcm2835: Add more unimplemented peripherals
Philippe Mathieu-Daudé [Mon, 21 Sep 2020 03:47:28 +0000 (05:47 +0200)] 
hw/arm/bcm2835: Add more unimplemented peripherals

The bcm2835-v3d is used since Linux 4.7, see commit
49ac67e0c39c ("ARM: bcm2835: Add VC4 to the device tree"),
and the bcm2835-txp since Linux 4.19, see commit
b7dd29b401f5 ("ARM: dts: bcm283x: Add Transposer block").

Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Luc Michel <luc.michel@greensocs.com>
Message-id: 20200921034729.432931-3-f4bug@amsat.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
7 months agohw/arm/raspi: Define various blocks base addresses
Philippe Mathieu-Daudé [Mon, 21 Sep 2020 03:47:27 +0000 (05:47 +0200)] 
hw/arm/raspi: Define various blocks base addresses

The Raspberry firmware is closed-source. While running it, it
accesses various I/O registers. Logging these accesses as UNIMP
(unimplemented) help to understand what the firmware is doing
(ideally we want it able to boot a Linux kernel).

Document various blocks we might use later.

Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Luc Michel <luc.michel@greensocs.com>
Message-id: 20200921034729.432931-2-f4bug@amsat.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
7 months agotarget/arm: Fix SVE splice
Richard Henderson [Fri, 18 Sep 2020 00:05:00 +0000 (17:05 -0700)] 
target/arm: Fix SVE splice

While converting to gen_gvec_ool_zzzp, we lost passing
a->esz as the data argument to the function.

Fixes: 36cbb7a8e71
Cc: qemu-stable@nongnu.org
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20200918000500.2690937-1-richard.henderson@linaro.org
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
7 months agotarget/arm: Fix sve ldr/str
Richard Henderson [Wed, 16 Sep 2020 01:41:02 +0000 (18:41 -0700)] 
target/arm: Fix sve ldr/str

The mte update missed a bit when producing clean addresses.

Fixes: b2aa8879b88
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20200916014102.2446323-1-richard.henderson@linaro.org
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
7 months agotarget/arm: Make isar_feature_aa32_fp16_arith() handle M-profile
Peter Maydell [Thu, 10 Sep 2020 17:38:55 +0000 (18:38 +0100)] 
target/arm: Make isar_feature_aa32_fp16_arith() handle M-profile

The M-profile definition of the MVFR1 ID register differs slightly
from the A-profile one, and in particular the check for "does the CPU
support fp16 arithmetic" is not the same.

We don't currently implement any M-profile CPUs with fp16 arithmetic,
so this is not yet a visible bug, but correcting the logic now
disarms this beartrap for when we eventually do.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20200910173855.4068-6-peter.maydell@linaro.org

7 months agotarget/arm: Add ID register values for Cortex-M0
Peter Maydell [Thu, 10 Sep 2020 17:38:54 +0000 (18:38 +0100)] 
target/arm: Add ID register values for Cortex-M0

Give the Cortex-M0 ID register values corresponding to its
implemented behaviour.  These will not be guest-visible but will be
used to govern the behaviour of QEMU's emulation.  We use the same
values that the Cortex-M3 does.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20200910173855.4068-5-peter.maydell@linaro.org

7 months agohw/intc/armv7m_nvic: Only show ID register values for Main Extension CPUs
Peter Maydell [Thu, 10 Sep 2020 17:38:53 +0000 (18:38 +0100)] 
hw/intc/armv7m_nvic: Only show ID register values for Main Extension CPUs

M-profile CPUs only implement the ID registers as guest-visible if
the CPU implements the Main Extension (all our current CPUs except
the Cortex-M0 do).

Currently we handle this by having the Cortex-M0 leave the ID
register values in the ARMCPU struct as zero, but this conflicts with
our design decision to make QEMU behaviour be keyed off ID register
fields wherever possible.

Explicitly code the ID registers in the NVIC to return 0 if the Main
Extension is not implemented, so we can make the M0 model set the
ARMCPU struct fields to obtain the correct behaviour without those
values becoming guest-visible.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20200910173855.4068-4-peter.maydell@linaro.org

7 months agotarget/arm: Move id_pfr0, id_pfr1 into ARMISARegisters
Peter Maydell [Thu, 10 Sep 2020 17:38:52 +0000 (18:38 +0100)] 
target/arm: Move id_pfr0, id_pfr1 into ARMISARegisters

Move the id_pfr0 and id_pfr1 fields into the ARMISARegisters
sub-struct. We're going to want id_pfr1 for an isar_features
check, and moving both at the same time avoids an odd
inconsistency.

Changes other than the ones to cpu.h and kvm64.c made
automatically with:
  perl -p -i -e 's/cpu->id_pfr/cpu->isar.id_pfr/' target/arm/*.c hw/intc/armv7m_nvic.c

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20200910173855.4068-3-peter.maydell@linaro.org

7 months agotarget/arm: Replace ARM_FEATURE_PXN with ID_MMFR0.VMSA check
Peter Maydell [Thu, 10 Sep 2020 17:38:51 +0000 (18:38 +0100)] 
target/arm: Replace ARM_FEATURE_PXN with ID_MMFR0.VMSA check

The ARM_FEATURE_PXN bit indicates whether the CPU supports the PXN
bit in short-descriptor translation table format descriptors.  This
is indicated by ID_MMFR0.VMSA being at least 0b0100.  Replace the
feature bit with an ID register check, in line with our preference
for ID register checks over feature bits.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20200910173855.4068-2-peter.maydell@linaro.org

7 months agoMerge remote-tracking branch 'remotes/kraxel/tags/microvm-20200930-pull-request'...
Peter Maydell [Thu, 1 Oct 2020 14:28:55 +0000 (15:28 +0100)] 
Merge remote-tracking branch 'remotes/kraxel/tags/microvm-20200930-pull-request' into staging

microvm: add pcie support.

# gpg: Signature made Wed 30 Sep 2020 18:48:41 BST
# gpg:                using RSA key 4CB6D8EED3E87138
# gpg: Good signature from "Gerd Hoffmann (work) <kraxel@redhat.com>" [full]
# gpg:                 aka "Gerd Hoffmann <gerd@kraxel.org>" [full]
# gpg:                 aka "Gerd Hoffmann (private) <kraxel@gmail.com>" [full]
# Primary key fingerprint: A032 8CFF B93A 17A7 9901  FE7D 4CB6 D8EE D3E8 7138

* remotes/kraxel/tags/microvm-20200930-pull-request:
  tests/acpi: update expected data files
  acpi/gpex: no reason to use a method for _CRS
  tests/acpi: add microvm pcie test
  tests/acpi: factor out common microvm test setup
  tests/acpi: add empty tests/data/acpi/microvm/DSDT.pcie file
  tests/acpi: allow updates for expected data files
  microvm/pcie: add 64bit mmio window
  microvm: add pcie support
  microvm: add irq table
  arm: use acpi_dsdt_add_gpex
  acpi: add acpi_dsdt_add_gpex
  move MemMapEntry

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
7 months agoMerge remote-tracking branch 'remotes/bonzini-gitlab/tags/for-upstream' into staging
Peter Maydell [Thu, 1 Oct 2020 11:23:19 +0000 (12:23 +0100)] 
Merge remote-tracking branch 'remotes/bonzini-gitlab/tags/for-upstream' into staging

* SCSI fix (Dmitry, Li Feng, Li Qiang)
* memory API fixes (Eduardo)
* removal of deprecated '-numa node', 'cpu-add', '-smp' (Igor)
* ACPI fix for VMBus (Jon)
* relocatable install (myself)
* always remove docker containers (myself)
* serial cleanups (Philippe)
* vmware cpuid leaf for tsc and apic frequency (Sunil)
* KVM_FEATURE_ASYNC_PF_INT support (Vitaly)
* i386 XSAVE bugfix (Xiaoyao)
* QOM developer documentation in docs/devel (Eduardo)
* new checkpatch tests (Dov)
* x86_64 syscall fix (Douglas)
* interrupt-based APF fix (Vitaly)
* always create kvmclock (Vitaly)
* fix bios-tables-test (Eduardo)
* KVM PV features cleanup (myself)
* CAN FD (Pavel)

meson:
* fixes (Marc-André, Max, Stefan, Alexander, myself)
* moved libmpathpersist, cocoa, malloc tests (myself)
* support for 0.56 introspected test dependencies (myself)

# gpg: Signature made Wed 30 Sep 2020 18:11:45 BST
# gpg:                using RSA key F13338574B662389866C7682BFFBD25F78C7AE83
# gpg:                issuer "pbonzini@redhat.com"
# gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>" [full]
# gpg:                 aka "Paolo Bonzini <pbonzini@redhat.com>" [full]
# Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4  E2F7 7E15 100C CD36 69B1
#      Subkey fingerprint: F133 3857 4B66 2389 866C  7682 BFFB D25F 78C7 AE83

* remotes/bonzini-gitlab/tags/for-upstream: (86 commits)
  hw/net/can: Correct Kconfig dependencies
  hw/net/can: Documentation for CTU CAN FD IP open hardware core emulation.
  hw/net/can: CTU CAN FD IP open hardware core emulation.
  hw/net/can/ctucafd: Add CTU CAN FD core register definitions.
  net/can: Add can_dlc2len and can_len2dlc for CAN FD.
  hw/net/can: sja1000 ignore CAN FD frames
  net/can: Initial host SocketCan support for CAN FD.
  target/i386: kvm: do not use kvm_check_extension to find paravirtual capabilities
  bios-tables-test: Remove kernel-irqchip=off option
  target/i386: always create kvmclock device
  target/i386: Fix VM migration when interrupt based APF is enabled
  helper_syscall x86_64: clear exception_is_int
  checkpatch: Detect '%#' or '%0#' in printf-style format strings
  typedefs: Restrict PCMachineState to 'hw/i386/pc.h'
  hw/xen: Split x86-specific declaration from generic hardware ones
  stubs: Split accelerator / hardware related stubs
  sysemu/xen: Add missing 'exec/cpu-common.h' header for ram_addr_t type
  hw/i386/xen: Rename X86/PC specific function as xen_hvm_init_pc()
  docs: Move object.h overview doc comment to qom.rst
  docs: Create docs/devel/qom.rst
  ...

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
7 months agohw/net/can: Correct Kconfig dependencies
Pavel Pisa [Mon, 14 Sep 2020 08:13:42 +0000 (10:13 +0200)] 
hw/net/can: Correct Kconfig dependencies

The original CAN_PCI config option enables multiple SJA1000 PCI boards
emulation build. These boards bridge SJA1000 into I/O or memory
address space of the host CPU and depend on SJA1000 emulation.

Signed-off-by: Pavel Pisa <pisa@cmp.felk.cvut.cz>
Message-Id: <dd332de687bfe52bbec37f5de1d861fb8e620d74.1600069689.git.pisa@cmp.felk.cvut.cz>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
7 months agohw/net/can: Documentation for CTU CAN FD IP open hardware core emulation.
Pavel Pisa [Mon, 14 Sep 2020 08:13:41 +0000 (10:13 +0200)] 
hw/net/can: Documentation for CTU CAN FD IP open hardware core emulation.

Updated MAINTAINERS for CAN bus related emulation as well.

Signed-off-by: Pavel Pisa <pisa@cmp.felk.cvut.cz>
Message-Id: <6d1b8db69efc4e5cfad702d2150e1960e8f63572.1600069689.git.pisa@cmp.felk.cvut.cz>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
7 months agohw/net/can: CTU CAN FD IP open hardware core emulation.
Jan Charvat [Mon, 14 Sep 2020 08:13:40 +0000 (10:13 +0200)] 
hw/net/can: CTU CAN FD IP open hardware core emulation.

The implementation of the model of complete open-source/design/hardware
CAN FD controller. The IP core project has been started and is maintained
by Ondrej Ille at Czech Technical University in Prague.

CTU CAN FD project pages:
https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core

CAN bus CTU FEE Projects Listing page:
http://canbus.pages.fel.cvut.cz/

The core is mapped to PCIe card same as on one of its real hardware
adaptations. The device implementing two CTU CAN FD ip cores
is instantiated after CAN bus definition

-object can-bus,id=canbus0-bus

by QEMU parameters

-device ctucan_pci,canbus0=canbus0-bus,canbus1=canbus0-bus

Signed-off-by: Jan Charvat <charvj10@fel.cvut.cz>
Signed-off-by: Pavel Pisa <pisa@cmp.felk.cvut.cz>
Message-Id: <23e3ca4dcb2cc9900991016910a6cab7686c0e31.1600069689.git.pisa@cmp.felk.cvut.cz>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
7 months agohw/net/can/ctucafd: Add CTU CAN FD core register definitions.
Jan Charvat [Mon, 14 Sep 2020 08:13:39 +0000 (10:13 +0200)] 
hw/net/can/ctucafd: Add CTU CAN FD core register definitions.

Definitions of registers and CAN FD frame message box of CTU CAN FD
IP core are generated the specification in CACTUS/IP-XACT format.

CTU CAN FD IP core repository

  https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core

The location of the CTU CAN IP core specification within
IP core design

  spec/CTU/ip/CAN_FD_IP_Core/2.1/CAN_FD_IP_Core.2.1.xml

The header files are generated by pyXact_generator designed
by Ondrej Ille which is based on ipyxact_parser.

The specification is source of header files for driver and emulation,
documentation and VHDL registers map implementation.

Signed-off-by: Jan Charvat <charvj10@fel.cvut.cz>
Signed-off-by: Pavel Pisa <pisa@cmp.felk.cvut.cz>
Message-Id: <97ae620f724bf1d76f127aaf628f7aec3af0a11c.1600069689.git.pisa@cmp.felk.cvut.cz>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
7 months agonet/can: Add can_dlc2len and can_len2dlc for CAN FD.
Jan Charvat [Mon, 14 Sep 2020 08:13:38 +0000 (10:13 +0200)] 
net/can: Add can_dlc2len and can_len2dlc for CAN FD.

Signed-off-by: Jan Charvat <charvj10@fel.cvut.cz>
Signed-off-by: Pavel Pisa <pisa@cmp.felk.cvut.cz>
Reviewed-by: Vikram Garhwal <fnu.vikram@xilinx.com>
Message-Id: <0a2efc6ef9c458505952ed230e49ae25cad7f324.1600069689.git.pisa@cmp.felk.cvut.cz>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
7 months agohw/net/can: sja1000 ignore CAN FD frames
Jan Charvat [Mon, 14 Sep 2020 08:13:37 +0000 (10:13 +0200)] 
hw/net/can: sja1000 ignore CAN FD frames

Signed-off-by: Jan Charvat <charvj10@fel.cvut.cz>
Signed-off-by: Pavel Pisa <pisa@cmp.felk.cvut.cz>
Reviewed-by: Vikram Garhwal <fnu.vikram@xilinx.com>
Message-Id: <48d9ebf6b64e7652851c12fe4566e06b44803372.1600069689.git.pisa@cmp.felk.cvut.cz>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
7 months agonet/can: Initial host SocketCan support for CAN FD.
Jan Charvat [Mon, 14 Sep 2020 08:09:02 +0000 (10:09 +0200)] 
net/can: Initial host SocketCan support for CAN FD.

Signed-off-by: Jan Charvat <charvj10@fel.cvut.cz>
Signed-off-by: Pavel Pisa <pisa@cmp.felk.cvut.cz>
Reviewed-by: Vikram Garhwal <fnu.vikram@xilinx.com>
Message-Id: <41383d4eb3f35586c696a8e29c4dff4031a81338.1600069689.git.pisa@cmp.felk.cvut.cz>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
7 months agotarget/i386: kvm: do not use kvm_check_extension to find paravirtual capabilities
Paolo Bonzini [Wed, 23 Sep 2020 03:01:39 +0000 (23:01 -0400)] 
target/i386: kvm: do not use kvm_check_extension to find paravirtual capabilities

Paravirtualized features have been listed in KVM_GET_SUPPORTED_CPUID since
Linux 2.6.35 (commit 84478c829d0f, "KVM: x86: export paravirtual cpuid flags
in KVM_GET_SUPPORTED_CPUID", 2010-05-19).  It has been more than 10 years,
so remove the fallback code.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
7 months agobios-tables-test: Remove kernel-irqchip=off option
Eduardo Habkost [Tue, 22 Sep 2020 19:47:32 +0000 (15:47 -0400)] 
bios-tables-test: Remove kernel-irqchip=off option

We don't need to use kernel-irqchip=off for irq0 override if IRQ
routing is supported by the host, which is the case since 2009
(IRQ routing was added to KVM in Linux v2.6.30).

This is a more straightforward fix for Launchpad bug #1896263, as
it doesn't require increasing the complexity of the MSR code.
kernel-irqchip=off is for debugging only and there's no need to
increase the complexity of the code just to work around an issue
that was already fixed in the kernel.

Fixes: https://bugs.launchpad.net/bugs/1896263
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Message-Id: <20200922194732.2100510-1-ehabkost@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
7 months agotarget/i386: always create kvmclock device
Vitaly Kuznetsov [Tue, 22 Sep 2020 15:19:34 +0000 (17:19 +0200)] 
target/i386: always create kvmclock device

QEMU's kvmclock device is only created when KVM PV feature bits for
kvmclock (KVM_FEATURE_CLOCKSOURCE/KVM_FEATURE_CLOCKSOURCE2) are
exposed to the guest. With 'kvm=off' cpu flag the device is not
created and we don't call KVM_GET_CLOCK/KVM_SET_CLOCK upon migration.
It was reported that without these call at least Hyper-V TSC page
clocksouce (which can be enabled independently) gets broken after
migration.

Switch to creating kvmclock QEMU device unconditionally, it seems
to always make sense to call KVM_GET_CLOCK/KVM_SET_CLOCK on migration.
Use KVM_CAP_ADJUST_CLOCK check instead of CPUID feature bits.

Reported-by: Antoine Damhet <antoine.damhet@blade-group.com>
Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Message-Id: <20200922151934.899555-1-vkuznets@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
7 months agotarget/i386: Fix VM migration when interrupt based APF is enabled
Vitaly Kuznetsov [Thu, 17 Sep 2020 10:23:16 +0000 (12:23 +0200)] 
target/i386: Fix VM migration when interrupt based APF is enabled

VM with  interrupt based APF enabled fails to migrate:
qemu-system-x86_64: error: failed to set MSR 0x4b564d02 to 0xf3

We have two issues:
1) There is a typo in kvm_put_msrs() and we write async_pf_int_msr
to MSR_KVM_ASYNC_PF_EN (instead of MSR_KVM_ASYNC_PF_INT)

2) We restore MSR_KVM_ASYNC_PF_EN before MSR_KVM_ASYNC_PF_INT is set
and this violates the check in KVM.

Re-order MSR_KVM_ASYNC_PF_EN/MSR_KVM_ASYNC_PF_INT setting (and
kvm_get_msrs() for consistency) and fix the typo.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Message-Id: <20200917102316.814804-1-vkuznets@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
7 months agohelper_syscall x86_64: clear exception_is_int
Douglas Crosher [Tue, 22 Sep 2020 04:17:56 +0000 (14:17 +1000)] 
helper_syscall x86_64: clear exception_is_int

The exception_is_int flag may be set on entry to helper_syscall,
e.g. after a prior interrupt that has returned, and processing
EXCP_SYSCALL as an interrupt causes it to fail so clear this flag.

Signed-off-by: Douglas Crosher <dtc-ubuntu@scieneer.com>
Message-Id: <a7dab33e-eda6-f988-52e9-f3d32db7538d@scieneer.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
7 months agocheckpatch: Detect '%#' or '%0#' in printf-style format strings
Dov Murik [Mon, 14 Sep 2020 17:26:23 +0000 (17:26 +0000)] 
checkpatch: Detect '%#' or '%0#' in printf-style format strings

According to the coding style document, we should use literal '0x' prefix
instead of printf's '#' flag (which appears as '%#' or '%0#' in the format
string).  Add a checkpatch rule to enforce that.

Note that checkpatch already had a similar rule for trace-events files.

Example usage:

  $ scripts/checkpatch.pl --file chardev/baum.c
  ...
  ERROR: Don't use '#' flag of printf format ('%#') in format strings, use '0x' prefix instead
  #366: FILE: chardev/baum.c:366:
  +            DPRINTF("Broken packet %#2x, tossing\n", req); \
  ...
  ERROR: Don't use '#' flag of printf format ('%#') in format strings, use '0x' prefix instead
  #472: FILE: chardev/baum.c:472:
  +        DPRINTF("unrecognized request %0#2x\n", req);
  ...

Signed-off-by: Dov Murik <dovmurik@linux.vnet.ibm.com>
Message-Id: <20200914172623.72955-1-dovmurik@linux.vnet.ibm.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
7 months agotypedefs: Restrict PCMachineState to 'hw/i386/pc.h'
Philippe Mathieu-Daudé [Tue, 8 Sep 2020 15:55:30 +0000 (17:55 +0200)] 
typedefs: Restrict PCMachineState to 'hw/i386/pc.h'

The PCMachineState type is only used under hw/i386/.
We don't need to forward-declare it for all architectures,
restrict it to the X86 one.

Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20200908155530.249806-7-philmd@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
7 months agohw/xen: Split x86-specific declaration from generic hardware ones
Philippe Mathieu-Daudé [Tue, 8 Sep 2020 15:55:29 +0000 (17:55 +0200)] 
hw/xen: Split x86-specific declaration from generic hardware ones

xen_hvm_init() is restricted to the X86 architecture.

Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20200908155530.249806-6-philmd@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
7 months agostubs: Split accelerator / hardware related stubs
Philippe Mathieu-Daudé [Tue, 8 Sep 2020 15:55:28 +0000 (17:55 +0200)] 
stubs: Split accelerator / hardware related stubs

Move hardware stubs unrelated from the accelerator to xen-hw-stub.c.

Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20200908155530.249806-5-philmd@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
7 months agosysemu/xen: Add missing 'exec/cpu-common.h' header for ram_addr_t type
Philippe Mathieu-Daudé [Tue, 8 Sep 2020 15:55:27 +0000 (17:55 +0200)] 
sysemu/xen: Add missing 'exec/cpu-common.h' header for ram_addr_t type

As this header use the ram_addr_t type, it has to include
"exec/cpu-common.h" to avoid odd errors such:

  include/sysemu/xen.h:35:44: error: unknown type name 'ram_addr_t'; did you mean 'in_addr_t'?
   35 | static inline void xen_hvm_modified_memory(ram_addr_t start, ram_addr_t length)
      |                                            ^~~~~~~~~~
      |                                            in_addr_t

Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20200908155530.249806-4-philmd@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
7 months agohw/i386/xen: Rename X86/PC specific function as xen_hvm_init_pc()
Philippe Mathieu-Daudé [Tue, 8 Sep 2020 15:55:26 +0000 (17:55 +0200)] 
hw/i386/xen: Rename X86/PC specific function as xen_hvm_init_pc()

xen_hvm_init() is only meanful to initialize a X86/PC machine,
rename it as xen_hvm_init_pc().

Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20200908155530.249806-3-philmd@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
7 months agodocs: Move object.h overview doc comment to qom.rst
Paolo Bonzini [Wed, 23 Sep 2020 16:21:39 +0000 (12:21 -0400)] 
docs: Move object.h overview doc comment to qom.rst

Move the whole contents of the overview doc comment from object.h
to qom.rst.

This makes the documentation source easier to read and edit, and
also solves the backslash escaping issue at the typecasting macro
examples.

Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Message-Id: <20200910221526.10041-10-ehabkost@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
7 months agodocs: Create docs/devel/qom.rst
Eduardo Habkost [Thu, 10 Sep 2020 22:15:25 +0000 (18:15 -0400)] 
docs: Create docs/devel/qom.rst

Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Message-Id: <20200910221526.10041-9-ehabkost@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
7 months agoqom: Add code block markup to all code blocks
Eduardo Habkost [Thu, 10 Sep 2020 22:15:24 +0000 (18:15 -0400)] 
qom: Add code block markup to all code blocks

Convert all example/codelisting markup to Sphinx code-block.

There are a few sections where backslashes at the end of lines
break code formatting.  A comment was added noting that this is
an issue.

Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Message-Id: <20200910221526.10041-8-ehabkost@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
7 months agoqom: Indent existing code examples
Eduardo Habkost [Thu, 10 Sep 2020 22:15:23 +0000 (18:15 -0400)] 
qom: Indent existing code examples

This indents existing code examples that are not indented yet,
just to make future conversion to Sphinx markup easier to review.

Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Message-Id: <20200910221526.10041-7-ehabkost@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
7 months agoqom: Reformat section titles using Sphinx syntax
Eduardo Habkost [Thu, 10 Sep 2020 22:15:22 +0000 (18:15 -0400)] 
qom: Reformat section titles using Sphinx syntax

Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Message-Id: <20200910221526.10041-6-ehabkost@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
7 months agoqom: Add kernel-doc markup to introduction doc comment
Eduardo Habkost [Thu, 10 Sep 2020 22:15:21 +0000 (18:15 -0400)] 
qom: Add kernel-doc markup to introduction doc comment

Add DOC: section keyword to introduction doc comment, so it will
be rendered by kernel-doc.

Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Message-Id: <20200910221526.10041-5-ehabkost@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
7 months agoqom: Use ``code`` Sphinx syntax where appropriate
Eduardo Habkost [Thu, 10 Sep 2020 22:15:20 +0000 (18:15 -0400)] 
qom: Use ``code`` Sphinx syntax where appropriate

Replace gtkdoc markup with Sphinx ``code`` syntax.

Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Message-Id: <20200910221526.10041-4-ehabkost@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
7 months agoqom: Use kernel-doc private/public tags in structs
Eduardo Habkost [Thu, 10 Sep 2020 22:15:19 +0000 (18:15 -0400)] 
qom: Use kernel-doc private/public tags in structs

Use kernel-doc syntax for indicating private and public struct
fields.

Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Message-Id: <20200910221526.10041-3-ehabkost@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
7 months agoqom: Document all function parameters in doc comments
Eduardo Habkost [Thu, 10 Sep 2020 22:15:18 +0000 (18:15 -0400)] 
qom: Document all function parameters in doc comments

kernel-doc requires all function parameters to be documented, so
document them all.

Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Message-Id: <20200910221526.10041-2-ehabkost@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>