The resources of pxbs are obtained by crs_build and the resources
used by pxbs would be moved from the resources defined for host-bridge.
The resources for pxb are composed of following two parts:
1. The bar space of the pci-bridge/pcie-root-port behined it
2. The config space of devices behind it.
Signed-off-by: Yubo Miao <miaoyubo@huawei.com>
Signed-off-by: Jiahui Cen <cenjiahui@huawei.com>
Message-Id: <20201119014841.7298-6-cenjiahui@huawei.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Extract crs build form acpi_build.c, the function could also be used
to build the crs for pxbs for arm. The resources are composed by two parts:
1. The bar space of pci-bridge/pcie-root-ports
2. The resources needed by devices behind PXBs.
The base and limit of memory/io are obtained from the config via two APIs:
pci_bridge_get_base and pci_bridge_get_limit
Signed-off-by: Yubo Miao <miaoyubo@huawei.com>
Signed-off-by: Jiahui Cen <cenjiahui@huawei.com>
Message-Id: <20201119014841.7298-5-cenjiahui@huawei.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Add bus property to virt machine for primary PCI root bus and use it to add
extra pci roots behind it.
Signed-off-by: Jiahui Cen <cenjiahui@huawei.com>
Signed-off-by: Yubo Miao <miaoyubo@huawei.com>
Message-Id: <20201119014841.7298-4-cenjiahui@huawei.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Extract extra pci roots addition from pc machine, which could be used by
other machines.
In order to make uefi get the extra roots, it is necessary to write extra
roots into fw_cfg. And only if the uefi knows there are extra roots,
the config spaces of devices behind the root could be obtained.
Signed-off-by: Jiahui Cen <cenjiahui@huawei.com>
Signed-off-by: Yubo Miao <miaoyubo@huawei.com>
Message-Id: <20201119014841.7298-3-cenjiahui@huawei.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Extract two APIs acpi_dsdt_add_pci_route_table and
acpi_dsdt_add_pci_osc from acpi_dsdt_add_pci. The first
API is used to specify the pci route table and the second
API is used to declare the operation system capabilities.
These two APIs would be used to specify the pxb-pcie in DSDT.
Signed-off-by: Yubo Miao <miaoyubo@huawei.com>
Signed-off-by: Jiahui Cen <cenjiahui@huawei.com>
Message-Id: <20201119014841.7298-2-cenjiahui@huawei.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
If we find a queue with an inconsistent guest index value, explicitly mark the
device as needing a reset - and broken - via virtio_error().
There's at least one driver implementation - the virtio-win NetKVM driver - that
is able to handle a VIRTIO_CONFIG_S_NEEDS_RESET notification and successfully
restore the device to a working state. Other implementations do not correctly
handle this, but as the VQ is not in a functional state anyway, this is still
worth doing.
Signed-off-by: John Levon <john.levon@nutanix.com>
Message-Id: <20201120185103.GA442386@sent>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Although they didn't reach the notifier because of the filtering in
memory_region_notify_iommu_one, the vt-d was still splitting huge
memory invalidations in chunks. Skipping it.
This improves performance in case of netperf with vhost-net:
* TCP_STREAM: From 1923.6Mbit/s to 2175.13Mbit/s (13%)
* TCP_RR: From 8464.73 trans/s to 8932.703333 trans/s (5.5%)
* UDP_RR: From 8562.08 trans/s to 9005.62/s (5.1%)
* UDP_STREAM: No change observed (insignificant 0.1% improvement)
Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Message-Id: <20201116165506.31315-5-eperezma@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
This allows us to differentiate between regular IOMMU map/unmap events
and DEVIOTLB unmap. Doing so, notifiers that only need device IOTLB
invalidations will not receive regular IOMMU unmappings.
Adapt intel and vhost to use it.
Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Message-Id: <20201116165506.31315-4-eperezma@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
This way we can tell between regular IOMMUTLBEntry (entry of IOMMU
hardware) and notifications.
In the notifications, we set explicitly if it is a MAPs or an UNMAP,
instead of trusting in entry permissions to differentiate them.
Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Message-Id: <20201116165506.31315-3-eperezma@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
Previous name didn't reflect the iommu operation.
Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Message-Id: <20201116165506.31315-2-eperezma@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
A case was reported where s->io_buffer_index can be out of range.
The report skimped on the details but it seems to be triggered
by s->lba == -1 on the READ/READ CD paths (e.g. by sending an
ATAPI command with LBA = 0xFFFFFFFF). For now paper over it
with assertions. The first one ensures that there is no overflow
when incrementing s->io_buffer_index, the second checks for the
buffer overrun.
Note that the buffer overrun is only a read, so I am not sure
if the assertion failure is actually less harmful than the overrun.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-id: 20201201120926.56559-1-pbonzini@redhat.com
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
An integer underflow could occur during packet transmission due to 'tx_len' not
being updated if SONIC_TFC register is set to zero. Check for negative 'tx_len'
when removing existing FCS.
RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1899722
Signed-off-by: Mauro Matteo Cascella <mcascell@redhat.com>
Reported-by: Gaoning Pan <pgn@zju.edu.cn>
Acked-by: Jason Wang <jasowang@redhat.com>
Message-id: 20201124092445.658647-1-mcascell@redhat.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
This reverts commit bccb20c49d as it
introduced a regression blocking bus addresses > 0x1f or higher.
Legal bus numbers go up to 0xff.
Fixes: bccb20c49d ("Use qemu_strtoul() in set_pci_host_devaddr()")
Reported-by: Klaus Herman <kherman@inbox.lv>
Reported-by: Geoffrey McRae <geoff@hostfission.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: "Philippe Mathieu-Daudé" <philmd@redhat.com>
Message-Id: <20201120130409.956956-1-mst@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
While receiving packets via e1000e_write_packet_to_guest() routine,
'desc_offset' is advanced only when RX descriptor is processed. And
RX descriptor is not processed if it has NULL buffer address.
This may lead to an infinite loop condition. Increament 'desc_offset'
to process next descriptor in the ring to avoid infinite loop.
Reported-by: Cheol-woo Myung <330cjfdn@gmail.com>
Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>
Signed-off-by: Jason Wang <jasowang@redhat.com>
By default dirty pages tracking is enabled during iterative phase
(pre-copy phase).
Added per device opt-out option 'x-pre-copy-dirty-page-tracking' to
disable dirty pages tracking during iterative phase. If the option
'x-pre-copy-dirty-page-tracking=off' is set for any VFIO device, dirty
pages tracking during iterative phase will be disabled.
Signed-off-by: Kirti Wankhede <kwankhede@nvidia.com>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Support for migration of vfio devices is still in flux. Developers
are attempting to add support for new devices and new architectures,
but none are yet readily available for validation. We have concerns
whether we're transferring device resources at the right point in the
migration, whether we're guaranteeing that updates during pre-copy are
migrated, and whether we can provide bit-stream compatibility should
any of this change. Even the question of whether devices should
participate in dirty page tracking during pre-copy seems contentious.
In short, migration support has not had enough soak time and it feels
premature to mark it as supported.
Create an experimental option such that we can continue to develop.
[Retaining previous acks/reviews for a previously identical code
change with different specifics in the commit log.]
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Acked-by: Cornelia Huck <cohuck@redhat.com>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
When 'j = icu->nr_sense – 1', the 'j < icu->nr_sense' condition is true,
then 'j = icu->nr_sense', the'icu->init_sense[j]' has out-of-bounds access.
The asan showed stack:
ERROR: AddressSanitizer: heap-buffer-overflow on address 0x604000004d7d at pc 0x55852cd26a76 bp 0x7ffe39f26200 sp 0x7ffe39f261f0
READ of size 1 at 0x604000004d7d thread T0
#0 0x55852cd26a75 in rxicu_realize ../hw/intc/rx_icu.c:311
#1 0x55852cf075f7 in device_set_realized ../hw/core/qdev.c:886
#2 0x55852cd4a32f in property_set_bool ../qom/object.c:2251
#3 0x55852cd4f9bb in object_property_set ../qom/object.c:1398
#4 0x55852cd54f3f in object_property_set_qobject ../qom/qom-qobject.c:28
#5 0x55852cd4fc3f in object_property_set_bool ../qom/object.c:1465
#6 0x55852cbf0b27 in register_icu ../hw/rx/rx62n.c:156
#7 0x55852cbf12a6 in rx62n_realize ../hw/rx/rx62n.c:261
#8 0x55852cf075f7 in device_set_realized ../hw/core/qdev.c:886
#9 0x55852cd4a32f in property_set_bool ../qom/object.c:2251
#10 0x55852cd4f9bb in object_property_set ../qom/object.c:1398
#11 0x55852cd54f3f in object_property_set_qobject ../qom/qom-qobject.c:28
#12 0x55852cd4fc3f in object_property_set_bool ../qom/object.c:1465
#13 0x55852cbf1a85 in rx_gdbsim_init ../hw/rx/rx-gdbsim.c:109
#14 0x55852cd22de0 in qemu_init ../softmmu/vl.c:4380
#15 0x55852ca57088 in main ../softmmu/main.c:49
#16 0x7feefafa5d42 in __libc_start_main (/lib64/libc.so.6+0x26d42)
Add the 'ice->src[i].sense' initialize to the default value, and then
process init_sense array to identify which irqs should be level-triggered.
Suggested-by: Peter Maydell <peter.maydell@linaro.org>
Reported-by: Euler Robot <euler.robot@huawei.com>
Signed-off-by: Chen Qun <kuhn.chenqun@huawei.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20201111141733.2358800-1-kuhn.chenqun@huawei.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
We should use printf format specifier "%u" instead of "%i" for
argument of type "unsigned int".
Reported-by: Euler Robot <euler.robot@huawei.com>
Signed-off-by: Alex Chen <alex.chen@huawei.com>
Message-id: 5F9FD78B.8000300@huawei.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Commit ae5643ecc6 "hw/display/tcx: Allow 64-bit accesses to framebuffer stippler
and blitter" enabled 64-bit access for the TCX framebuffer stippler and blitter
but missed applying the change to one of the blitter MemoryRegions.
Whilst the original change works for me on my local NetBSD test image, the latest
NetBSD ISO panics on startup without this fix.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Fixes: ae5643ecc6 ("hw/display/tcx: Allow 64-bit accesses to framebuffer stippler and blitter")
Buglink: https://bugs.launchpad.net/bugs/1892540
Message-Id: <20201120081754.18250-1-mark.cave-ayland@ilande.co.uk>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Remove the "default y" for USB_XHCI_SYSBUS because
sysbus devices are not user creatable; boards that use them will
specify them manually with "imply" or "select" clauses.
It would be nice to keep the ability to remove PCIe and USB from microvm,
since thos can be disabled on the command line and therefore should not
be included if QEMU is configured --without-default-devices. However
it's too late for 5.2 to figure out a place for the DSDT creation code.
Reported-by: Bruce Rogers <brogers@suse.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The zPCI group and function structures are big endian. However, we do
not consistently store them as big endian locally, and are missing some
conversions.
Let's just store the structures as host endian instead and convert to
big endian when actually handling the instructions retrieving the data.
Also fix the layout of ClpReqQueryPciGrp: g is actually only 8 bit. This
also fixes accesses on little endian hosts, and makes accesses on big
endian hosts consistent.
Fixes: 28dc86a072 ("s390x/pci: use a PCI Group structure")
Fixes: 9670ee7527 ("s390x/pci: use a PCI Function structure")
Fixes: 1e7552ff5c ("s390x/pci: get zPCI function info from host")
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
Tested-by: Matthew Rosato <mjrosato@linux.ibm.com>
Tested-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20201118104202.1301363-1-cohuck@redhat.com>
Hot-unplugging a vfio-pci device on s390x causes a QEMU crash:
qemu-system-s390x: ../softmmu/memory.c:2772:
do_address_space_destroy: Assertion `QTAILQ_EMPTY(&as->listeners)' failed.
In s390, the IOMMU address space is freed during device unplug but the
associated vfio-pci device may not yet be finalized and therefore may
still have a listener registered to the IOMMU address space.
Commit a2166410ad ("spapr_pci: Unregister listeners before destroying
the IOMMU address space") previously resolved this issue for spapr_pci.
We are now seeing this in s390x; it would seem the possibility for this
issue was already present but based on a bisect commit 2d24a64661
("device-core: use RCU for list of children of a bus") has now changed
the timing such that it is now readily reproducible.
Add logic to ensure listeners are removed before destroying the address
space.
Reported-by: Niklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com>
Tested-by: Niklas Schnelle <schnelle@linux.ibm.com>
Reviewed-by: Pierre Morel <pmorel@linux.ibm.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <1605562955-21152-1-git-send-email-mjrosato@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
The Control Program Name Code (CPNC) portion of the diag318
info must be set within the SIE block of each VCPU in the
configuration. The handler will iterate through each VCPU
and dirty the diag318_info reg to be synced with KVM on a
subsequent sync_regs call.
Additionally, the diag318 info resets must be handled via
userspace. As such, QEMU will reset this value for each
VCPU during a modified clear, load normal, and load clear
reset event.
Fixes: fabdada935 ("s390: guest support for diagnose 0x318")
Signed-off-by: Collin Walling <walling@linux.ibm.com>
Message-Id: <20201113221022.257054-1-walling@linux.ibm.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Janosch Frank <frankja@de.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
This fixes a regression that badly breaks some guest setups because
IPIs end up misconfigured in the XIVE interrupt controller. Hopefully,
the last fix for sPAPR. I'm sending this PR with the blessing of David
who is currently on holidays.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEtIKLr5QxQM7yo0kQcdTV5YIvc9YFAl+09tcACgkQcdTV5YIv
c9aW+xAAn0H219o6zfbJSkWnFcqq3vVLGhAva/QoQHzy2oeusbTgo968J4p9zwZb
rS+jRo1uA+U6cuRo+1PPh+iMP+t8ZLlN9AQIqdqtIIeUxpKTGUKUpX7AvZcknpvN
VNvcUsGJGIl/mOjHPXbP29PGi0hWv8+kvESoOOqGfxkv0bY8L1+PItEMK22+n3n2
aaPiWtxsx6UtRoFpyj82bMM/Y5PsKlP0ZvrVChvF8VZZu0kWe8KWKsR7do2/RLAX
tb5J4BN9gWPC2KERsrBWsGn0A4pE5n1NXnERH6BlwEBU/AhUM9d80N6280SSge0k
noE2U1pVAva78NJzAWAiweP1ZGR3yt71MWP2i7ndCxcbFG9IQ7Su48nSmzwKfutT
+SEuoP0fmTSRXmWiKkrOT+9ZdC4+Vpn0IvCGFHzoPTyNlhaOZRIoqhqxTlvrSYwx
/DDwechCwPhidpZ+RYaQudX4yUtZIh+Y33LH879aDxkWW8HcaA98XSXXQ+iOiofu
SY25HisfZjj1xHNuipjoGyMCdPZh4rdspaAGWzJVkOUjjFnzY9PeOxh7bYHz32eN
xFr3f/1woPYHacqQE5lP2aWmyUvWHkvJsEW3yVix1j+luzn1UmXOwRm1P7tGC1o5
gtMgQXR3ZodyLxO20slZjt/G77aFz3bpetWcHxoxaksPua3RZoc=
=zUP3
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/gkurz/tags/ppc-for-5.2-20201118' into staging
ppc patch queue for 2020-11-18
This fixes a regression that badly breaks some guest setups because
IPIs end up misconfigured in the XIVE interrupt controller. Hopefully,
the last fix for sPAPR. I'm sending this PR with the blessing of David
who is currently on holidays.
# gpg: Signature made Wed 18 Nov 2020 10:26:31 GMT
# gpg: using RSA key B4828BAF943140CEF2A3491071D4D5E5822F73D6
# gpg: Good signature from "Greg Kurz <groug@kaod.org>" [full]
# gpg: aka "Gregory Kurz <gregory.kurz@free.fr>" [full]
# gpg: aka "[jpeg image of size 3330]" [full]
# Primary key fingerprint: B482 8BAF 9431 40CE F2A3 4910 71D4 D5E5 822F 73D6
* remotes/gkurz/tags/ppc-for-5.2-20201118:
Revert series "spapr/xive: Allocate vCPU IPIs from the vCPU contexts"
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
This series was largely built on the assumption that IPI numbers are
numerically equal to vCPU ids. Even if this happens to be the case
in practice with the default machine settings, this ceases to be true
if VSMT is set to a different value than the number of vCPUs per core.
This causes bogus IPI numbers to be created in KVM from a guest stand
point. This leads to unknow results in the guest, including crashes
or missing vCPUs (see BugLink) and even non-fatal oopses in current
KVM that lacks a check before accessing misconfigured HW (see [1]).
A tentative patch was sent (see [2]) but it seems too complex to be
merged in an RC. Since the original changes are essentially an
optimization, it seems safer to revert them for now. The damage is
done by commit acbdb9956f ("spapr/xive: Allocate IPIs independently
from the other sources") but the previous patches in the series are
really preparatory patches. So this reverts the whole series:
eab0a2d06e ("spapr/xive: Allocate vCPU IPIs from the vCPU contexts")
acbdb9956f ("spapr/xive: Allocate IPIs independently from the other sources")
fa94447a2c ("spapr/xive: Use kvmppc_xive_source_reset() in post_load")
235d3b1162 ("spapr/xive: Modify kvm_cpu_is_enabled() interface")
[1] https://marc.info/?l=kvm-ppc&m=160458409722959&w=4
[2] https://lists.gnu.org/archive/html/qemu-devel/2020-11/msg03626.html
Reported-by: Satheesh Rajendran <sathnaga@linux.vnet.ibm.com>
Fixes: acbdb9956f ("spapr/xive: Allocate IPIs independently from the other sources")
BugLink: https://bugs.launchpad.net/qemu/+bug/1900241
Signed-off-by: Greg Kurz <groug@kaod.org>
Acked-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <160554086275.1325084.12110142252189044646.stgit@bahia.lan>
Fix also a similar typo in a code comment.
Signed-off-by: Stefan Weil <sw@weilnetz.de>
Message-Id: <20201117193448.393472-1-sw@weilnetz.de>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* Update NetBSD VM to version 9.1
* Misc fixes (e.g. categorize some devices)
-----BEGIN PGP SIGNATURE-----
iQJFBAABCAAvFiEEJ7iIR+7gJQEY8+q5LtnXdP5wLbUFAl+zld8RHHRodXRoQHJl
ZGhhdC5jb20ACgkQLtnXdP5wLbWb8Q/+IRvGUGjGcPfbTvwoOqJVy4Hm7huW5i1s
wHe/6nitNtpvaAqcxbQHBIvWX9xTzppWcFiEkIs8rPwLOUFKh5xJ+NbEdf4acQaJ
m4G2mEY5bYt/o5e6p7ZK1RgS2EjD1eQ6BwMWQKeUHET7MTv0UabKtvWmBWpMqFxA
vl/3SbVWsSwGB9gOA5oksYhKY5ZRcVaDxsGk89f7iwgaStcxWNxVFEXddbBmqhfW
Q4ZPt0K7yod7NDBOaGEoc2hOjIfr0TvovHojDuAxt+2tKdYi1vwtnwKbFqTWp7Ca
7ttzoQUSsteiOjAhHRpa2PEbfrNs+loIm9fem5fQ9i7POlbS/Ozv2RnPCZm1X8pW
n7Jvsh25V066AFnHat7PnjcBVBRFfmR3xtA61PqvAMGEKW8tortbZbpqXO18Pv5p
6P/GG9G3QE0v2rEsU5BNFWp/aD7fiWy/VPu3dGFUkI9/S3biatocldHn/9eyXz94
k75Xzhe5x6n5Jf8QYFQ/6BO0qSoidNbAVg1W8+QyRXIJJhWRnvW9eYa7tSx5ezJg
5+oCo4oh6Qd9nvrl5pIwvX6QMDf2kPxzp7PsHeemqt7+QNmXErAVsIi1HUVsLWRP
Qb/BbKyKNeWJwvWWLAm/2kXVmNQfjLVNCwg04xa8tkQemhIDekVrCpMoX3cNHjWf
EWa1vEtbq9k=
=A3/B
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/huth-gitlab/tags/pull-request-2020-11-17' into staging
* Fixes for compiling on Haiku, and add Haiku VM for compile-testing
* Update NetBSD VM to version 9.1
* Misc fixes (e.g. categorize some devices)
# gpg: Signature made Tue 17 Nov 2020 09:20:31 GMT
# gpg: using RSA key 27B88847EEE0250118F3EAB92ED9D774FE702DB5
# gpg: issuer "thuth@redhat.com"
# gpg: Good signature from "Thomas Huth <th.huth@gmx.de>" [full]
# gpg: aka "Thomas Huth <thuth@redhat.com>" [full]
# gpg: aka "Thomas Huth <huth@tuxfamily.org>" [full]
# gpg: aka "Thomas Huth <th.huth@posteo.de>" [unknown]
# Primary key fingerprint: 27B8 8847 EEE0 2501 18F3 EAB9 2ED9 D774 FE70 2DB5
* remotes/huth-gitlab/tags/pull-request-2020-11-17:
max111x: put it into the 'misc' category
nand: put it into the 'storage' category
ads7846: put it into the 'input' category
ssd0323: put it into the 'display' category
gitlab-ci: Use $CI_REGISTRY instead of hard-coding registry.gitlab.com
target/microblaze: Fix possible array out of bounds in mmu_write()
tests/vm: update NetBSD to 9.1
tests/vm: Add Haiku test based on their vagrant images
configure: Add a proper check for sys/ioccom.h and use it in tpm_ioctl.h
configure: Do not build pc-bios/optionrom on Haiku
configure: Fix the _BSD_SOURCE define for the Haiku build
qemu/bswap: Remove unused qemu_bswap_len()
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The TMP105 datasheet says that in Interrupt Mode (when TM==1) the device
signals an alert when the temperature equals or exceeds the T_high value and
then remains high until a device register is read or the device responds to
the SMBUS Alert Response address, or the device is put into Shutdown Mode.
Thereafter the Alert pin will only be re-signalled when temperature falls
below T_low; alert can then be cleared in the same set of ways, and the
device returns to its initial "alert when temperature goes above T_high"
mode. (If this textual description is confusing, see figure 3 in the
TI datasheet at https://www.ti.com/lit/gpn/tmp105 .)
We were misimplementing this as a simple "always alert if temperature is
above T_high or below T_low" condition, which gives a spurious alert on
startup if using the "T_high = 80 degrees C, T_low = 75 degrees C" reset
limit values.
Implement the correct (hysteresis) behaviour by tracking whether we
are currently looking for the temperature to rise over T_high or
for it to fall below T_low. Our implementation of the comparator
mode (TM==0) wasn't wrong, but rephrase it to match the way that
interrupt mode is now handled for clarity.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Message-id: 20201110150023.25533-3-peter.maydell@linaro.org
The TMP105 datasheet (https://www.ti.com/lit/gpn/tmp105) says that the
power-up reset values for the T_low and T_high registers are 80 degrees C
and 75 degrees C, which are 0x500 and 0x4B0 hex according to table 5. These
values are then shifted right by four bits to give the register reset
values, since both registers store the 12 bits of temperature data in bits
[15..4] of a 16 bit register.
We were resetting these registers to zero, which is problematic for Linux
guests which enable the alert interrupt and then immediately take an
unexpected overtemperature alert because the current temperature is above
freezing...
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Message-id: 20201110150023.25533-2-peter.maydell@linaro.org
This patch fixes CID 1432800 by removing an unnecessary check.
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
In commit 5edab03d40 we added tracepoints to the ps2 keyboard
and mouse emulation. However we didn't remove all the debug-by-printf
support. In fact there is only one printf() remaining, and it is
redundant with the trace_ps2_write_mouse() event next to it.
Remove the printf() and the now-unused DEBUG* macros.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Message-id: 20201101133258.4240-1-peter.maydell@linaro.org
We should use printf format specifier "%u" instead of "%d" for
argument of type "unsigned int".
Reported-by: Euler Robot <euler.robot@huawei.com>
Signed-off-by: Alex Chen <alex.chen@huawei.com>
Message-id: 20201111073651.72804-1-alex.chen@huawei.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The removal of the selection of A15MPCORE from ARM_VIRT also
removed what A15MPCORE selects, ARM_GIC. We still need ARM_GIC.
Fixes: bec3c97e0c ("hw/arm/virt: Remove dependency on Cortex-A15 MPCore peripherals")
Reported-by: Miroslav Rezanina <mrezanin@redhat.com>
Signed-off-by: Andrew Jones <drjones@redhat.com>
Reviewed-by: Miroslav Rezanina <mrezanin@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20201111143440.112763-1-drjones@redhat.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Per the SD spec, to indicate a 2 GiB card, BLOCK_LEN shall be 1024
bytes, hence the READ_BL_LEN field in the CSD register shall be 10
instead of 9.
This fixes the acceptance test error for the NetBSD 9.0 test of the
Orange Pi PC that has an expanded SD card image of 2 GiB size.
Fixes: 6d2d4069c4 ("hw/sd: Correct the maximum size of a Standard Capacity SD Memory Card")
Reported-by: Niek Linnenbank <nieklinnenbank@gmail.com>
Signed-off-by: Bin Meng <bin.meng@windriver.com>
Tested-by: Niek Linnenbank <nieklinnenbank@gmail.com>
Message-Id: <20201025152357.11865-1-bmeng.cn@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
The category of the max111x device is not set, put it into the 'misc'
category.
Signed-off-by: Gan Qixin <ganqixin@huawei.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20201112125824.763182-5-ganqixin@huawei.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
The category of the nand device is not set, put it into the 'storage'
category.
Signed-off-by: Gan Qixin <ganqixin@huawei.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20201112125824.763182-4-ganqixin@huawei.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
The category of the ads7846 device is not set, put it into the 'input'
category.
Signed-off-by: Gan Qixin <ganqixin@huawei.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20201112125824.763182-3-ganqixin@huawei.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
The category of the ssd0323 device is not set, put it into the 'display'
category.
Signed-off-by: Gan Qixin <ganqixin@huawei.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20201112125824.763182-2-ganqixin@huawei.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Linux has some OS-specific (and sometimes weird) mappings for various SCSI
statuses and sense codes. The most important is probably RESERVATION
CONFLICT. Add them so that they can be reported back to the guest
kernel.
Cc: Hannes Reinecke <hare@suse.de>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
-----BEGIN PGP SIGNATURE-----
iQJFBAABCAAvFiEEJ7iIR+7gJQEY8+q5LtnXdP5wLbUFAl+xVToRHHRodXRoQHJl
ZGhhdC5jb20ACgkQLtnXdP5wLbX2ow/+MKI6s5QeaAGMJfEG1KkfCCfrybJSy+1X
BN7ANBxkwndPIZEDfE1Hnxh0nH+jYLhtVm1N7F7EJ2PuyEw+yoVIVE4xp1HFQYEb
gowE2QSjc1TqyoJhGu/Pj6cGxKFp14ZNIj8w1gKttgjK7doDom76ZZFfRoSc5Qw4
EoMe5Bnit4qOrjCKnfa0XEMlcB598KKyTxPiwlpA2Tnf2Hl7dAwnkT+fbaQ0iTcL
f0t8O1GVqyrQSkadf+n94l4kwATk92A7ZLrq7imImRfFo9JwmaAl8rZj3KUdrUax
IckyUWsiQ+RyH7Th7h8F5jqPLjDYgNOfx/BMaNcLUNBLyaco4lcZT3X0JUxuzV7Y
KPMk1PuUzv2yhEu1QV6o/0WQ/AwcZNQbNR98z5rqZsCG2rF+AVSMAEz97B7AIfbb
hJH3f7lmIPcAqkdGXxy/PphzD8qVpm0bTQUWVJi0+ASw73ucTSzgWV29g/b8gh+X
DzjFAnwYY21oUH8nhZrraQRd1Nu+GDF/+BXrIsBvznxNDyyYS12V2PurWaUwGX5o
TYLRwMHlvOlypEh0C2mjU+X/1TmLoMueSouDQ22R01sVIUG7PxbNCn46BJTGnxdE
6kd6rEC804vC2n96WFaHozBbOBwssFDrVsuwUg5HCTIu6BFyCRVTa2P5WxzYPSdM
lTs9rBwdXPc=
=GI5d
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/huth-gitlab/tags/pull-request-2020-11-15' into staging
Fix Lesser GPL license versions (should be "2.1" and not "2")
# gpg: Signature made Sun 15 Nov 2020 16:20:10 GMT
# gpg: using RSA key 27B88847EEE0250118F3EAB92ED9D774FE702DB5
# gpg: issuer "thuth@redhat.com"
# gpg: Good signature from "Thomas Huth <th.huth@gmx.de>" [full]
# gpg: aka "Thomas Huth <thuth@redhat.com>" [full]
# gpg: aka "Thomas Huth <huth@tuxfamily.org>" [full]
# gpg: aka "Thomas Huth <th.huth@posteo.de>" [unknown]
# Primary key fingerprint: 27B8 8847 EEE0 2501 18F3 EAB9 2ED9 D774 FE70 2DB5
* remotes/huth-gitlab/tags/pull-request-2020-11-15: (26 commits)
nomaintainer: Fix Lesser GPL version number
test: Fix LGPL information in the file headers
tests/acceptance: Fix LGPL information in the file headers
tests/migration: Fix LGPL information in the file headers
sparc tcg cpus: Fix Lesser GPL version number
e1000e: Fix Lesser GPL version number
x86 hvf cpus: Fix Lesser GPL version number
nvdimm: Fix Lesser GPL version number
w32: Fix Lesser GPL version number
tpm: Fix Lesser GPL version number
overall/alpha tcg cpus|hppa: Fix Lesser GPL version number
overall usermode...: Fix Lesser GPL version number
migration: Fix Lesser GPL version number
parallel nor flash: Fix Lesser GPL version number
arm tcg cpus: Fix Lesser GPL version number
x86 tcg cpus: Fix Lesser GPL version number
linux user: Fix Lesser GPL version number
usb: Fix Lesser GPL version number
tricore tcg cpus: Fix Lesser GPL version number
xtensa tcg cpus: Fix Lesser GPL version number
...
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
GCC 9.3.0 thinks that 'method' can be left uninitialized. This code
is already in the "if (bsel || pcihp_bridge_en)" block statement,
but it isn't smart enough to figure it out.
Restrict the code to be used only in the "if (bsel || pcihp_bridge_en)"
block statement to fix (on Ubuntu):
../hw/i386/acpi-build.c: In function 'build_append_pci_bus_devices':
../hw/i386/acpi-build.c:496:9: error: 'method' may be used uninitialized
in this function [-Werror=maybe-uninitialized]
496 | aml_append(parent_scope, method);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
Fixes: df4008c9c5 ("piix4: don't reserve hw resources when hotplug is off globally")
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20201108204535.2319870-4-philmd@redhat.com>
Message-Id: <20201110192316.26397-8-alex.bennee@linaro.org>
The v variable goes negative for reg < 0x20. Reorder the code
to first sanity check then calculate v and assign intr to make
sanity checkers happy.
Buglink: https://bugs.launchpad.net/qemu/+bug/1902112
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20201105134112.25119-7-kraxel@redhat.com
