When we're using the subsection we migrate both
the 'props' and 'tso_props' data; when we're not using
the subsection (to migrate to 2.11 or old machine types) we've
got to choose what to migrate in the main structure.
If we're using the subsection migrate 'props' in the main structure.
If we're not using the subsection then migrate the last one
that changed, which gives behaviour similar to the old behaviour.
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
Swing the tx.props out via a temporary structure, so in future patches
we can select what we're going to send.
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
Wire the new subsection from the previous commit to a property
so we can turn it off easily.
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
Old QEMUs only had one set of offload data; when we only receive
one lot, dupe the received data - that should give us about the
same bug level as the old version.
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
A bunch of new TSO fields were introduced by d62644b4 and this bumped
the VMState version; however it's easier for those trying to keep
backwards migration compatibility if these fields are added in a
subsection instead.
Move the new fields to a subsection.
Since this was added after 2.11, this change will only affect
compatbility with 2.12-rc0.
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
Check device having the feature of VIRTIO_CONSOLE_F_EMERG_WRITE before
get config->emerg_wr. It is neccessary because sizeof(virtio_console_config)
is 8 byte if VirtIOSerial doesn't have the feature of
VIRTIO_CONSOLE_F_EMERG_WRITE(see virtio_serial_device_realize),
read/write emerg_wr will lead to heap-over-flow.
Signed-off-by: linzhecheng <linzhecheng@huawei.com>
Message-Id: <20180328133435.20112-1-linzhecheng@huawei.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
When migrating from a pre-2.9 QEMU, no clock_is_reliable flag is
transferred. We should assume that the source host has an unreliable
KVM_GET_CLOCK, rather than using whatever was determined locally, to
ensure that any drift from the TSC-based value calculated by the guest
is corrected.
Signed-off-by: Michael Chapman <mike@very.puzzling.org>
Message-Id: <20180406053406.774-1-mike@very.puzzling.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
QEMU fails when used with the following command line:
./ppc64-softmmu/qemu-system-ppc64 -S -machine 40p -device i82374
qemu-system-ppc64: hw/isa/isa-bus.c:110: isa_bus_dma: Assertion `!bus->dma[0] && !bus->dma[1]' failed.
The 40p machine type already creates the device i82374. If specified in the
command line, it will try to create it again, hence generating the error. The
function isa_bus_dma() isn't supposed to be called twice for the same bus.
Check the bus doesn't already have a DMA controller registered before creating
the device.
Fixes: https://bugs.launchpad.net/qemu/+bug/1721224
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20180326153441.32641-2-f4bug@amsat.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
QEMU SCSI code makes assumptions about how the PROTECT and BYTCHK
works in the protocol, denying support for PI (Protection
Information) in case the guest OS requests it. However, in SCSI versions 2
and older, there is no PI concept in the protocol.
This means that when dealing with such devices:
- there is no PROTECT bit in byte 5 of the standard INQUIRY response. The
whole byte is marked as "Reserved";
- there is no RDPROTECT in byte 2 of READ. We have 'Logical Unit Number'
in this field instead;
- there is no VRPROTECT in byte 2 of VERIFY. We have 'Logical Unit Number'
in this field instead. This also means that the BYTCHK bit in this case
is not related to PI.
Since QEMU does not consider these changes, a SCSI passthrough using
a SCSI-2 device will not work. It will mistake these fields with
PI information and return Illegal Request SCSI SENSE thinking
that the driver is asking for PI support.
This patch fixes it by adding a new attribute called 'scsi_version'
that is read from the standard INQUIRY response of passthrough
devices. This allows for a version verification before applying
conditions related to PI that doesn't apply for older versions.
Reported-by: Dac Nguyen <dacng@us.ibm.com>
Signed-off-by: Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com>
Message-Id: <20180327211451.14647-1-danielhb@linux.vnet.ibm.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
We would like to have different behavior for passthrough devices
depending on the SCSI version they expose. To prepare for that,
allow the user of emulated devices to specify the desired SCSI
level, and adjust the emulation according to the property value.
The next patch will set the level for scsi-block and scsi-generic
devices.
Based on a patch by Daniel Henrique Barboza
<danielhb@linux.vnet.ibm.com>.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Some backends report big max_io_sectors. Making min_io_size the same
value in this case will make it impossible for guest to align memory,
therefore the disk may not be usable at all.
Do not enlarge them when they are zero.
Reported-by: David Gibson <dgibson@redhat.com>
Signed-off-by: Fam Zheng <famz@redhat.com>
Message-Id: <20180327164141.19075-1-famz@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Check device having the feature of VIRTIO_CONSOLE_F_EMERG_WRITE before
get config->emerg_wr. It is neccessary because sizeof(virtio_console_config)
is 8 byte if VirtIOSerial doesn't have the feature of
VIRTIO_CONSOLE_F_EMERG_WRITE(see virtio_serial_device_realize),
read/write emerg_wr will lead to heap-over-flow.
Signed-off-by: linzhecheng <linzhecheng@huawei.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
My rework of section adding combines overlapping or adjoining regions,
but checks they're actually the same underlying RAM block.
Fix the case where two blocks adjoin but don't overlap; that new region
should get added (but not combined), but my previous patch was disallowing it.
Fixes: c1ece84e7c
Reported-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Tested-by: Alex Williamson <alex.williamson@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Without a dedicated protocol feature, QEMU cannot know whether
the backend can handle VHOST_USER_SET_CONFIG and
VHOST_USER_GET_CONFIG messages.
This patch adds a protocol feature that is only advertised by
QEMU if the device implements the config ops. Vhost user init
fails if the device support the feature but the backend doesn't.
The backend should only send VHOST_USER_SLAVE_CONFIG_CHANGE_MSG
requests if the protocol feature has been negotiated.
Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Changpeng Liu <changpeng.liu@intel.com>
As soon as vhost-user init is done, the backend may send
VHOST_USER_SLAVE_CONFIG_CHANGE_MSG, so let's set the
notification callback before it.
Also, it will be used to know whether the device supports
the config feature to advertize it or not.
Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Changpeng Liu <changpeng.liu@intel.com>
Commit 567b5b309a ("vfio/pci: Relax DMA map errors for MMIO regions")
added an error message if a passed memory section address or size
is not aligned to the page size and thus cannot be DMA mapped.
This patch fixes the trace by printing the region name and the
memory region section offset within the address space (instead of
offset_within_region).
We also turn the error_report into a trace event. Indeed, In some
cases, the traces can be confusing to non expert end-users and
let think the use case does not work (whereas it works as before).
This is the case where a BAR is successively mapped at different
GPAs and its sections are not compatible with dma map. The listener
is called several times and traces are issued for each intermediate
mapping. The end-user cannot easily match those GPAs against the
final GPA output by lscpi. So let's keep those information to
informed users. In mid term, the plan is to advise the user about
BAR relocation relevance.
Fixes: 567b5b309a ("vfio/pci: Relax DMA map errors for MMIO regions")
Signed-off-by: Eric Auger <eric.auger@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
The string returned by object_property_get_str() is dynamically allocated.
Fixes: 3c4e9baacf
Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <152231460685.69730.14860451936216690693.stgit@bahia.lan>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
Section 5.5.3.2.2 of the CRB specs states that use of the TPM
through the localty control method must first be requested,
otherwise the command will be dropped.
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reset the Granted flag when relinquishing a locality.
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Commit ef0e64a983 "ide: pass IDEState to trim AIO callback" changed the
IDE trim callback from using a BlockBackend to an IDEState but forgot to update
the dma_blk_io() call in hw/ide/macio.c accordingly.
Without this fix qemu-system-ppc segfaults when issuing an IDE trim command on
any of the PPC Mac machines (easily triggered by running the Debian installer).
Reported-by: Howard Spoelstra <hsp.cat7@gmail.com>
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: Anton Nefedov <anton.nefedov@virtuozzo.com>
Message-id: 20180223184700.28854-1-mark.cave-ayland@ilande.co.uk
Signed-off-by: John Snow <jsnow@redhat.com>
commit 947858b0 "ide: abort TRIM operation for invalid range"
is incorrect for macio; just ide_dma_error() without doing a callback
is not enough for that errorpath.
Instead, pass -EINVAL to the callback and handle it there
(see related motivation for read/write in 58ac32113).
It will however catch possible EINVAL from the block layer too.
Signed-off-by: Anton Nefedov <anton.nefedov@virtuozzo.com>
Tested-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Message-id: 1520010495-58172-1-git-send-email-anton.nefedov@virtuozzo.com
Signed-off-by: John Snow <jsnow@redhat.com>
Thomas.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAABAgAGBQJauOmSAAoJEL/70l94x66DwA4IAIfXUyWSDzAMTc19N/gY4eKB
cptfJas1CmfrMU+EBIVZoiVdYF1H5qvctxVSaCXL3y7XNfwrjfDoiplfbi9rTSKb
pW59bqIf7Y+ViOYDYHdbxKMcvWxIaiWKfpzWkncy+aeqObs620VSCbVmqVsQsKQu
1OHWrTlgNAP4aqPy9gZ6O1YXBDxTCIKW9N+QIdho5RqB1uPFkjBJcxlF04ydF9S7
kIgblBsosljTOk03I2hf6KKtfXfRXctgE/RYyE8SW3dy+CQWfiGjkE/z17ABBjK2
g7Rex6S9NA/+fDXO+2MAYnx6iBA9Dkxt2CcWWDjGwg+nXS4+B/OoF4MhRwV6N2g=
=5hGp
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging
Miscellaenous bugfixes, including crash fixes from Alexey, Peter M. and
Thomas.
# gpg: Signature made Mon 26 Mar 2018 13:37:38 BST
# gpg: using RSA key BFFBD25F78C7AE83
# gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>"
# gpg: aka "Paolo Bonzini <pbonzini@redhat.com>"
# 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/tags/for-upstream:
qemu-pr-helper: Actually allow users to specify pidfile
chardev/char-fe: Allow NULL chardev in qemu_chr_fe_init()
iothread: fix breakage on windows
scsi: turn "is this a SCSI device?" into a conditional hint
chardev-socket: remove useless if
tcg: Really fix cpu_io_recompile
vhost-user-test: add back memfd check
vhost-user-test: do not hang if chardev creation failed
scripts/device-crash-test: Remove fixed isapc-with-iommu entry
hw/audio: Fix crashes when devices are used on ISA bus without DMA
fdc: Exit if ISA controller does not support DMA
hw/net/can: Fix segfaults when using the devices without bus
WHPX improve vcpu_post_run perf
WHPX fix WHvSetPartitionProperty in PropertyCode
WHPX fix WHvGetCapability out WrittenSizeInBytes
scripts/get_maintainer.pl: Print proper error message for missing $file
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
If the user does not have permissions to send ioctls to the device (due to
SELinux or cgroups, for example), the output can look like
qemu-kvm: -device scsi-block,drive=disk: cannot get SG_IO version number:
Operation not permitted. Is this a SCSI device?
but this is confusing because the ioctl was blocked _before_ the device
even received the SG_GET_VERSION_NUM ioctl. Therefore, for EPERM errors
the suggestion should be eliminated. To make that simpler, change the
code to use error_append_hint.
Reported-by: Ala Hino <ahino@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The cs4231a, gus and sb16 sound cards crash QEMU when the user tries
to instantiate them on a machine with DMA-less ISA bus (for example
with "qemu-system-mips64el -M mips -device sb16"). Add proper checks
to the realize functions to avoid the crashes.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-Id: <1521193892-15552-4-git-send-email-thuth@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
A "powernv" machine type defines an ISA bus but it does not add any DMA
controller to it so it is possible to hit assert(fdctrl->dma) by
adding "-machine powernv -device isa-fdc".
This replaces assert() with an error message.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
[thuth: Slightly adjusted error message and updated scripts/device-crash-test]
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-Id: <1521193892-15552-3-git-send-email-thuth@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The CAN devices can currently be used to crash QEMU, e.g.:
$ x86_64-softmmu/qemu-system-x86_64 -device kvaser_pci
Segmentation fault (core dumped)
So we've got to add a proper check here that the corresponding
bus is available.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-Id: <1521193892-15552-2-git-send-email-thuth@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
If the backend could not transmit a packet right away for some reason,
the packet is queued for asynchronous sending. The corresponding vq
element is tracked in the async_tx.elem field of the VirtIONetQueue,
for later freeing when the transmission is complete.
If a reset happens before completion, virtio_net_tx_complete() will push
async_tx.elem back to the guest anyway, and we end up with the inuse flag
of the vq being equal to -1. The next call to virtqueue_pop() is then
likely to fail with "Virtqueue size exceeded".
This can be reproduced easily by starting a guest with an hubport backend
that is not connected to a functional network, eg,
-device virtio-net-pci,netdev=hub0 -netdev hubport,id=hub0,hubid=0
and no other -netdev hubport,hubid=0 on the command line.
The appropriate fix is to ensure that such an asynchronous transmission
cannot survive a device reset. So for all queues, we first try to send
the packet again, and eventually we purge it if the backend still could
not deliver it.
CC: qemu-stable@nongnu.org
Reported-by: R. Nageswara Sastry <nasastry@in.ibm.com>
Buglink: https://github.com/open-power-host-os/qemu/issues/37
Signed-off-by: Greg Kurz <groug@kaod.org>
Tested-by: R. Nageswara Sastry <nasastry@in.ibm.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
* arm/translate-a64: don't lose interrupts after unmasking via write to DAIF
* sdhci: fix incorrect use of Error *
* hw/intc/arm_gicv3: Fix secure-GIC NS ICC_PMR and ICC_RPR accesses
* hw/arm/bcm2836: Use the Cortex-A7 instead of Cortex-A15
* i.MX: Support serial RS-232 break properly
* mach-virt: Set VM's SMBIOS system version to mc->name
* target/arm: Honour MDCR_EL2.TDE when routing exceptions due to BKPT/BRK
* target/arm: Factor out code to calculate FSR for debug exceptions
* target/arm: Set FSR for BKPT, BRK when raising exception
* target/arm: Always set FAR to a known unknown value for debug exceptions
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABCAAGBQJatUwZAAoJEDwlJe0UNgzeCbAP/it0Qg18DZ/0229WgvORVDJQ
AMrbLhMgYFhKm/hi2mbv1xE4SfwQ0ZGyNIsJBy1JXn5EsOvfz/KXrdS+snrogZ+S
McQi9EgAYPtKrj4rppal4efNiczNf1PJ45xTgLCUUMFxZ9CZbXnV7arzM4VwrcHk
ega/X3y+ygRgftfrXYsAQ5wI2gDEUZQrD0JUodkayXiRkvtmrDRycWLMkMlTl1Qe
PQ02yV2EZsItqvwEoG7Q6/58Uzf3/CLxs54X8kRLlNoZkmsSCmKWwqgmFjn78qjf
MPG6ujZDCFE0NUUgp4rMQ4b86zWOEaCOgU2xfKgxnhY0M4RIbl2VPXHAlbDkGVAI
PqfIqWZQn4mW1qTEpMTgVY9MY3WSoPf9+Iof3ZKCvPXKrwfw8fdX+UfiLVMBqi0u
+l7zZYEt1gdSE/G/+Tt+dRHld3aSiwtnajLK8jRpNQOAxOuX8AeajdRDXNAdnqyi
CQJuUkhBfVoAAW3FuHBLFXo5exZU20jPBLhcp39doCbXIZhvP7l2CbmqkoCDlM2N
FRIQD6fOCkPzo2PYYhWSFGLFGp7XMCK5+Jo+jPMxBl90/y74xjbeGaFwRgujgz/L
3krNAqBNJbrqxqcgyg72zbNnWP4p+gvnLV+J5EoBbLBa2AO1Kzyvd9PCWMMvbDxC
fPprx7CLaFa/QuEB//TU
=eH28
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20180323' into staging
target-arm queue:
* arm/translate-a64: don't lose interrupts after unmasking via write to DAIF
* sdhci: fix incorrect use of Error *
* hw/intc/arm_gicv3: Fix secure-GIC NS ICC_PMR and ICC_RPR accesses
* hw/arm/bcm2836: Use the Cortex-A7 instead of Cortex-A15
* i.MX: Support serial RS-232 break properly
* mach-virt: Set VM's SMBIOS system version to mc->name
* target/arm: Honour MDCR_EL2.TDE when routing exceptions due to BKPT/BRK
* target/arm: Factor out code to calculate FSR for debug exceptions
* target/arm: Set FSR for BKPT, BRK when raising exception
* target/arm: Always set FAR to a known unknown value for debug exceptions
# gpg: Signature made Fri 23 Mar 2018 18:48:57 GMT
# gpg: using RSA key 3C2525ED14360CDE
# gpg: Good signature from "Peter Maydell <peter.maydell@linaro.org>"
# gpg: aka "Peter Maydell <pmaydell@gmail.com>"
# gpg: aka "Peter Maydell <pmaydell@chiark.greenend.org.uk>"
# Primary key fingerprint: E1A5 C593 CD41 9DE2 8E83 15CF 3C25 25ED 1436 0CDE
* remotes/pmaydell/tags/pull-target-arm-20180323:
target/arm: Always set FAR to a known unknown value for debug exceptions
target/arm: Set FSR for BKPT, BRK when raising exception
target/arm: Factor out code to calculate FSR for debug exceptions
target/arm: Honour MDCR_EL2.TDE when routing exceptions due to BKPT/BRK
mach-virt: Set VM's SMBIOS system version to mc->name
i.MX: Support serial RS-232 break properly
hw/arm/bcm2836: Use the Cortex-A7 instead of Cortex-A15
hw/intc/arm_gicv3: Fix secure-GIC NS ICC_PMR and ICC_RPR accesses
sdhci: fix incorrect use of Error *
arm/translate-a64: treat DISAS_UPDATE as variant of DISAS_EXIT
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Instead of using "1.0" as the system version of SMBIOS, we should use
mc->name for mach-virt machine type to be consistent other architectures.
With this patch, "dmidecode -t 1" (e.g., "-M virt-2.12,accel=kvm") will
show:
Handle 0x0100, DMI type 1, 27 bytes
System Information
Manufacturer: QEMU
Product Name: KVM Virtual Machine
Version: virt-2.12
Serial Number: Not Specified
...
instead of:
Handle 0x0100, DMI type 1, 27 bytes
System Information
Manufacturer: QEMU
Product Name: KVM Virtual Machine
Version: 1.0
Serial Number: Not Specified
...
For backward compatibility, we allow older machine types to keep "1.0"
as the default system version.
Signed-off-by: Wei Huang <wei@redhat.com>
Reviewed-by: Andrew Jones <drjones@redhat.com>
Message-id: 20180322212318.7182-1-wei@redhat.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Linux does not detect a break from this IMX serial driver as a magic
sysrq. Nor does it note a break in the port error counts.
The former is because the Linux driver uses the BRCD bit in the USR2
register to trigger the RS-232 break handler in the kernel, which is
where sysrq hooks in. The emulated UART was not setting this status
bit.
The latter is because the Linux driver expects, in addition to the BRK
bit, that the ERR bit is set when a break is read in the FIFO. A break
should also count as a frame error, so add that bit too.
Cc: Andrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: Trent Piepho <tpiepho@impinj.com>
Message-id: 20180320013657.25038-1-tpiepho@impinj.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
If the GIC has the security extension support enabled, then a
non-secure access to ICC_PMR must take account of the non-secure
view of interrupt priorities, where real priorities 0x00..0x7f
are secure-only and not visible to the non-secure guest, and
priorities 0x80..0xff are shown to the guest as if they were
0x00..0xff. We had the logic here wrong:
* on reads, the priority is in the secure range if bit 7
is clear, not if it is set
* on writes, we want to set bit 7, not mask everything else
Our ICC_RPR read code had the same error as ICC_PMR.
(Compare the GICv3 spec pseudocode functions ICC_RPR_EL1
and ICC_PMR_EL1.)
Fixes: https://bugs.launchpad.net/qemu/+bug/1748434
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Andrew Jones <drjones@redhat.com>
Message-id: 20180315133441.24149-1-peter.maydell@linaro.org
Detected by Coverity (CID 1386072, 1386073, 1386076, 1386077). local_err
was unused, and this made the static analyzer unhappy.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-id: 20180320151355.25854-1-pbonzini@redhat.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Use the correct printf formats, so that a 32-bit compile doesn't spit
out lots of warnings about %lx being incompatible with uint64_t.
Suggested-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Yuval Shaia <yuval.shaia@oracle.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Tested-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20180322095220.9976-4-yuval.shaia@oracle.com>
Signed-off-by: Marcel Apfelbaum <marcel@redhat.com>
Macro should not cast the given variable to u64 instead it should use
the supplied format argument (fmt).
Reported-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Yuval Shaia <yuval.shaia@oracle.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Tested-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20180322095220.9976-3-yuval.shaia@oracle.com>
Signed-off-by: Marcel Apfelbaum <marcel@redhat.com>
To avoid compilation warnings on 32-bit machines:
rdma_backend.c: In function 'rdma_backend_create_mr':
rdma_backend.c:409:37: error: cast to pointer from integer of different
size [-Werror=int-to-pointer-cast]
mr->ibmr = ibv_reg_mr(pd->ibpd, (void *)addr, length, access);
Reported-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Yuval Shaia <yuval.shaia@oracle.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Tested-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20180322095220.9976-2-yuval.shaia@oracle.com>
Signed-off-by: Marcel Apfelbaum <marcel@redhat.com>
Fix some enum castings and extra parentheses.
Reported-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Marcel Apfelbaum <marcel@redhat.com>
Message-Id: <20180321140316.96045-1-marcel@redhat.com>
Reviewed-by: Yuval Shaia <yuval.shaia@oracle.com>
Our rule right now is to use <> for external headers only.
RDMA code violates that, fix it up.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Marcel Apfelbaum <marcel@redhat.com>
Signed-off-by: Marcel Apfelbaum <marcel@redhat.com>
This IB verb is needed by some applications - implement it.
Signed-off-by: Yuval Shaia <yuval.shaia@oracle.com>
Reviewed-by: Marcel Apfelbaum <marcel@redhat.com>
Signed-off-by: Marcel Apfelbaum <marcel@redhat.com>
Currently we don't support pci multifunction. If a pci with
multifucntion is plugged, the guest will spin forever. This patch fixes
this.
Signed-off-by: Yi Min Zhao <zyimin@linux.vnet.ibm.com>
Reviewed-by: Pierre Morel <pmorel@linux.vnet.ibm.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
I couldn't find a case where this prevents something bad from happening
that isn't already caught by other checks, but let's err on the safe
side and check that mh_header_addr is as expected.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Jack Schwartz <jack.schwartz@oracle.com>
The code path where mh_load_end_addr is non-zero in the Multiboot
header checks that mh_load_end_addr >= mh_load_addr and so
mb_load_size is checked. However, mb_load_size is not checked when
calculated from the file size, when mh_load_end_addr is 0.
If the kernel binary size is larger than can fit in the address space
after load_addr, we ended up with a kernel_size that is smaller than
load_size, which means that we read the file into a too small buffer.
Add a check to reject kernel files with such Multiboot headers.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Jack Schwartz <jack.schwartz@oracle.com>
