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>
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>
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>
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>
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>
* 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>
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>
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>
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>
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>
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>
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).
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.
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.
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.
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
* 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>
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>
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.
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.
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.
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>
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
* 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>
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>
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>
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>
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>
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.
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>
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>
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>
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>
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>
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>
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>
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
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
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
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
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
* 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>
* 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>
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.
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
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>
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>
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>
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.
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>
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>
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>
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>
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>
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>
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>
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>
The qemu_chr_write_buffer() method sends data to the chardev backend for
writing, and then also writes to the log file. In case the chardev
backend only writes part of the data buffer, we need to make sure we
only log the same subset. qemu_chr_write_buffer() will be invoked again
later to write the rest of the buffer.
In the case the chardev backend returns an error though, no further
attempts to likely to be made to write the data. We must therefore write
the entire buffer to the log immediately.
An example where this is important is with the socket backend. This will
return -1 for all writes if no client is currently connected. We still
wish to write data to the log file when no client is present though.
This used to work because the chardev would return "len" to pretend it
had written all data when no client is connected, but this changed to
return an error in
char-socket: return -1 in case of disconnect during tcp_chr_write
and this broke the logging, resulting in all data being discarded when
no client is present.
Fixes: https://bugs.launchpad.net/qemu/+bug/1893691 Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Igor Mammedov [Fri, 11 Sep 2020 13:32:02 +0000 (09:32 -0400)]
smp: drop support for deprecated (invalid topologies)
it's was deprecated since 3.1
Support for invalid topologies is removed, the user must ensure
that topologies described with -smp include all possible cpus,
i.e. (sockets * cores * threads) == maxcpus or QEMU will
exit with error.
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Acked-by:
Message-Id: <20200911133202.938754-1-imammedo@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
projects / mirror_qemu.git / log