Log all traffic of a specific usb device to a pcap file for later
inspection. File format is compatible with linux usb monitor.
Usage:
qemu -device usb-${somedevice},pcap=file.pcap
wireshark file.pcap
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20210119194452.2148048-1-kraxel@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
We are not ready to handle additional CDB data.
If a guest sends a packet with such additional data,
report the command parameter as not supported.
Specify a size (of 1 byte) for the add_cdb member we
are not using, to fix the following warning:
usb/dev-uas.c:157:31: error: field 'status' with variable sized type 'uas_iu' not at the end of a struct or class is a GNU extension [-Werror,-Wgnu-variable-sized-type-not-at-end]
uas_iu status;
^
Reported-by: Ed Maste <emaste@FreeBSD.org>
Reported-by: Daniele Buono <dbuono@linux.vnet.ibm.com>
Reported-by: Han Han <hhan@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20210120153522.1173897-4-philmd@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
For some reason the assert() added in commit ccb799313a
("hw/usb: avoid format truncation warning when formatting
port name") does not fix when building with GCC 10.
KISS and expand the buffer by 4 bytes to silent the following
error when using GCC 10.2.1 on Fedora 33:
hw/usb/hcd-xhci.c: In function 'usb_xhci_realize':
hw/usb/hcd-xhci.c:3309:54: error: '%d' directive output may be truncated writing between 1 and 8 bytes into a region of size 5 [-Werror=format-truncation=]
3309 | snprintf(port->name, sizeof(port->name), "usb2 port #%d", i+1);
| ^~~~~~~~~~~~~~~
hw/usb/hcd-xhci.c:3309:54: note: directive argument in the range [1, 89478486]
In file included from /usr/include/stdio.h:866,
from include/qemu/osdep.h:85,
from hw/usb/hcd-xhci.c:22:
/usr/include/bits/stdio2.h:70:10: note: '__builtin___snprintf_chk' output between 13 and 20 bytes into a destination of size 16
70 | return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
71 | __bos (__s), __fmt, __va_arg_pack ());
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
hw/usb/hcd-xhci.c:3323:54: error: '%d' directive output may be truncated writing between 1 and 8 bytes into a region of size 5 [-Werror=format-truncation=]
3323 | snprintf(port->name, sizeof(port->name), "usb3 port #%d", i+1);
| ^~~~~~~~~~~~~~~
hw/usb/hcd-xhci.c:3323:54: note: directive argument in the range [1, 89478486]
In file included from /usr/include/stdio.h:866,
from include/qemu/osdep.h:85,
from hw/usb/hcd-xhci.c:22:
/usr/include/bits/stdio2.h:70:10: note: '__builtin___snprintf_chk' output between 13 and 20 bytes into a destination of size 16
70 | return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
71 | __bos (__s), __fmt, __va_arg_pack ());
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20210118181115.313742-1-philmd@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Device code shouldn't mess with QOM property "realized" since we have
proper interfaces (merge commit 6675a653). Commit 8ddab8dd3d
"usb/hcd-xhci: Split pci wrapper for xhci base model" and commit
f00ff136ee "usb: hcd-xhci-sysbus: Attach xhci to sysbus device"
reintroduced two instances. Clean them up. Note that s->xhci is
a (bus-less) TYPE_XHCI device.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20210119120151.53757-1-armbru@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
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: 20201119025751.45750-1-alex.chen@huawei.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
USBDEVFS_GET_SPEED is used since version 5.2.0 and
202d69a715
resulting in the following build failure with kernel < 5.0:
../hw/usb/host-libusb.c: In function 'usb_host_open':
../hw/usb/host-libusb.c:953:32: error: 'USBDEVFS_GET_SPEED' undeclared (first use in this function); did you mean 'USBDEVFS_GETDRIVER'?
int rc = ioctl(hostfd, USBDEVFS_GET_SPEED, NULL);
^~~~~~~~~~~~~~~~~~
USBDEVFS_GETDRIVER
A tentative was made to fix this build failure with
4969e697c1
However, the assumption that distros with old kernels also have old
libusb is just wrong so also add a check for defined(USBDEVFS_GET_SPEED)
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Message-id: 20201213213016.457350-1-fontaine.fabrice@gmail.com
[ kraxel: codestyle whitespace fixup ]
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
- headers update to Linux 5.11-rc2
- fix tcg emulation for some instructions that are generated by
clang Linux kernel builds
- vfio-ccw: wire up the device unplug notification mechanism
- fix a gcc 11 warning
-----BEGIN PGP SIGNATURE-----
iQJGBAABCAAwFiEEw9DWbcNiT/aowBjO3s9rk8bwL68FAmAJbqwSHGNvaHVja0By
ZWRoYXQuY29tAAoJEN7Pa5PG8C+vLYQP/22DjhdzHBNPe8ewnJ++QHYGfvcaK0m1
QMN6ug9HGyBj7yENf1qWf8i49vO6rtsNBc9vMRJfps/dy0ZpeHXl88j9Ela+6cJ3
v1tb4WtRFmNEe44SaxAmfvo0VgkgzXL4DLCSw39UX4dAd6U3UMI18sLSOltBhza5
vNbA4TbOlQIIxYQrcnQD8zUzDx3PKf+z3lESbMcHs9ruJ90BJ5hLUSfhLv+GG+lS
Y0+/5k+7OOTrwO5Dvg1u4GdOYsSIYhqzuevtdsGXjrnJA6OBbXrub+ZyDMAe5BcB
GKTqza5Yj9QSGHk4Na2x2ZdTkPjcj04dhW2SyvR6PUQkOD5oQ7T6h0UQP6HvXxF9
wOaTSLuIKhFO5AodiUGKcXwIhQ2OImGdNM23eyrDy3nwyf0smdz9HOMZkqTGVPjI
7yfHPIjbRj9hFqzAy4FEedGx9VOOpFQ4ColgA7iv5KBl0fedFU7uOHR3B95AJ2o7
+v6nrJjAMkrT+cOuoz49W+xUi1iJ5Yc7Wij7TYeX11mpCfnkjBzAdch3pedmY5Kr
0ksBW5tNE9OZd4/V/oK9yfWvJZ76dKK2/ysnsQXM2FMUrc5crvaJ6YtgcBlfzDXj
fwv/hnq4zBCCbQJNfF4jJ8mCe/nH0Ts+aFYMRca88a5HaTu+PnqIOM5sgIOb5vQd
xb5wuQ6VTdz7
=lCNW
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/cohuck-gitlab/tags/s390x-20210121' into staging
s390x updates:
- headers update to Linux 5.11-rc2
- fix tcg emulation for some instructions that are generated by
clang Linux kernel builds
- vfio-ccw: wire up the device unplug notification mechanism
- fix a gcc 11 warning
# gpg: Signature made Thu 21 Jan 2021 12:08:12 GMT
# gpg: using RSA key C3D0D66DC3624FF6A8C018CEDECF6B93C6F02FAF
# gpg: issuer "cohuck@redhat.com"
# gpg: Good signature from "Cornelia Huck <conny@cornelia-huck.de>" [unknown]
# gpg: aka "Cornelia Huck <huckc@linux.vnet.ibm.com>" [full]
# gpg: aka "Cornelia Huck <cornelia.huck@de.ibm.com>" [full]
# gpg: aka "Cornelia Huck <cohuck@kernel.org>" [unknown]
# gpg: aka "Cornelia Huck <cohuck@redhat.com>" [unknown]
# Primary key fingerprint: C3D0 D66D C362 4FF6 A8C0 18CE DECF 6B93 C6F0 2FAF
* remotes/cohuck-gitlab/tags/s390x-20210121:
s390x: Use strpadcpy for copying vm name
vfio-ccw: Connect the device request notifier
Update linux headers to 5.11-rc2
update-linux-headers: Include const.h
s390x/tcg: Ignore register content if b1/b2 is zero when handling EXECUTE
tests/tcg/s390x: Fix EXRL tests
s390x/tcg: Don't ignore content in r0 when not specified via "b" or "x"
s390x/tcg: Fix RISBHG
s390x/tcg: Fix ALGSI
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The fid_list is currently open-coded. This doesn't seem to serve any
purpose that cannot be met with QEMU's generic lists. Let's go for a
QSIMPLEQ : this will allow to add new fids at the end of the list and
to improve the logic in v9fs_mark_fids_unreclaim().
Reviewed-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Message-Id: <20210118142300.801516-3-groug@kaod.org>
Signed-off-by: Greg Kurz <groug@kaod.org>
This can only be 0 or 1.
Reviewed-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Message-Id: <20210118142300.801516-2-groug@kaod.org>
Signed-off-by: Greg Kurz <groug@kaod.org>
This should always successfully write exactly two 32-bit integers.
Make it clear with an assert(), like v9fs_receive_status() and
v9fs_receive_response() already do when unmarshalling the same
header.
Fixes: Coverity CID 1438968
Reviewed-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Message-Id: <161035859647.1221144.4691749806675653934.stgit@bahia.lan>
Signed-off-by: Greg Kurz <groug@kaod.org>
- minor resource leak fixes in qemu-nbd
- ensure proper aio context when nbd server uses iothreads
- iotest refactorings in preparation for rewriting ./check to be more
flexible, and preparing for more nbd server reconnect features
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEEccLMIrHEYCkn0vOqp6FrSiUnQ2oFAmAI5sMACgkQp6FrSiUn
Q2rmQwf+Jmlsn8s0tdeeOhv6mp8ZSyvr2/x1/daGHkzZqhoL7m/4kJLP4p/u8uTV
XzXyXt7MKvHKd8UvKB6VsN6z75RJvi7y8pKpOQA96t08hjWuAcVtivKnyZd6MTwj
zeKsmrE8LAuMjHvmsrtrmRqCSdaVeFPb3qC6bvJ+WEiXJIMiXybF7lccPvR7WWjR
2FcyraZJgnlKrQv1i8M1++Px5W14jhOacAMUNAdVzNiYpu4tq6PTk9giq1/GULCz
xVYGHqoTFYy7Slj7xKQJuOwGNLMwL+F9x7/6wRFhKxjutc0/Po1lSfbaNe8q147H
p9jtDT9/OuTlQf7qpqqyQnASABDgaA==
=XW+E
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/ericb/tags/pull-nbd-2021-01-20' into staging
nbd patches for 2021-01-20
- minor resource leak fixes in qemu-nbd
- ensure proper aio context when nbd server uses iothreads
- iotest refactorings in preparation for rewriting ./check to be more
flexible, and preparing for more nbd server reconnect features
# gpg: Signature made Thu 21 Jan 2021 02:28:19 GMT
# gpg: using RSA key 71C2CC22B1C4602927D2F3AAA7A16B4A2527436A
# gpg: Good signature from "Eric Blake <eblake@redhat.com>" [full]
# gpg: aka "Eric Blake (Free Software Programmer) <ebb9@byu.net>" [full]
# gpg: aka "[jpeg image of size 6874]" [full]
# Primary key fingerprint: 71C2 CC22 B1C4 6029 27D2 F3AA A7A1 6B4A 2527 436A
* remotes/ericb/tags/pull-nbd-2021-01-20:
iotests.py: qemu_io(): reuse qemu_tool_pipe_and_status()
iotests.py: fix qemu_tool_pipe_and_status()
iotests/264: fix style
iotests: define group in each iotest
iotests/294: add shebang line
iotests: make tests executable
iotests: fix some whitespaces in test output files
iotests/303: use dot slash for qcow2.py running
iotests/277: use dot slash for nbd-fault-injector.py running
nbd/server: Quiesce coroutines on context switch
block: Honor blk_set_aio_context() context requirements
qemu-nbd: Fix a memleak in nbd_client_thread()
qemu-nbd: Fix a memleak in qemu_nbd_client_list()
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Now that the vfio-ccw code has a notifier interface to request that
a device be unplugged, let's wire that together.
Signed-off-by: Eric Farman <farman@linux.ibm.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Message-Id: <20210104202057.48048-4-farman@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
The documentation for bdrv_set_aio_context_ignore() states this:
* The caller must own the AioContext lock for the old AioContext of bs, but it
* must not own the AioContext lock for new_context (unless new_context is the
* same as the current context of bs).
As blk_set_aio_context() makes use of this function, this rule also
applies to it.
Fix all occurrences where this rule wasn't honored.
Suggested-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Sergio Lopez <slp@redhat.com>
Message-Id: <20201214170519.223781-2-slp@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
As per POSIX specification of limits.h [1], OS libc may define
PAGE_SIZE in limits.h.
To prevent collosion of definition, we rename PAGE_SIZE here.
[1]: https://pubs.opengroup.org/onlinepubs/7908799/xsh/limits.h.html
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20210118063808.12471-5-jiaxun.yang@flygoat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Add the vmstate for the new NeXTPC devic; this is in theory
a migration compatibility break, but this machine doesn't have
working migration currently anyway.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20210115201206.17347-11-peter.maydell@linaro.org>
Signed-off-by: Thomas Huth <huth@tuxfamily.org>
The fields scsi_irq, scsi_dma, scsi_reset and fd_irq in
NeXTState are all unused, except in commented out
"this should do something like this" code. Remove the
unused fields. As and when the functionality that might
use them is added, we can put in the correct kind of
wiring (which might or might not need to be a qemu_irq,
but which in any case will need to be in the NeXTPC
device, not in NeXTState).
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20210115201206.17347-10-peter.maydell@linaro.org>
Signed-off-by: Thomas Huth <huth@tuxfamily.org>
Move the rtc into the NeXTPC struct. Since this is the last
use of the 'backdoor' NextState pointer we can now remove that.
Probably the RTC should be its own device at some point: in hardware
there is a separate MCS1850 RTC chip connected to the Peripheral
Controller via a 1-bit serial interface. That goes beyond the remit
of the current refactoring, though.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20210115201206.17347-9-peter.maydell@linaro.org>
Signed-off-by: Thomas Huth <huth@tuxfamily.org>
Make the next_irq function be GPIO inputs to the NEXT_PC
device, rather than a freestanding set of qemu_irq lines.
This fixes a minor Coverity issue where it correctly points
out the trivial memory leak of the memory allocated in the
call to qemu_allocate_irqs().
Fixes: CID 1421962
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20210115201206.17347-8-peter.maydell@linaro.org>
Signed-off-by: Thomas Huth <huth@tuxfamily.org>
All the code which accesses int_status and int_mask is now doing
so via the NeXTPC->NeXTState indirection, so we can move these
fields into the NeXTPC struct where they belong.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20210115201206.17347-7-peter.maydell@linaro.org>
Signed-off-by: Thomas Huth <huth@tuxfamily.org>
Make the next_irq function take a NeXTPC* as its opaque rather than
the M68kCPU*. This will make it simpler to turn the next_irq
function into a gpio input line of the NeXTPC device in the next
commit.
For this to work we have to pass the CPU to the NeXTPC device via a
link property, in the same way we do in q800.c (and for the same
reason).
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20210115201206.17347-6-peter.maydell@linaro.org>
Signed-off-by: Thomas Huth <huth@tuxfamily.org>
Move the registers handled by the scr_ops struct into the NeXTPC
device.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20210115201206.17347-5-peter.maydell@linaro.org>
Signed-off-by: Thomas Huth <huth@tuxfamily.org>
Move the registers handled by the mmio_ops struct into the NeXTPC
device. This allows us to also move the scr1 and scr2 data fields.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20210115201206.17347-4-peter.maydell@linaro.org>
Signed-off-by: Thomas Huth <huth@tuxfamily.org>
Currently the next-cube board code open-codes a lot of handling of
interrupts and some miscellaneous registers. Move this into a proper
QOM device.
In the real hardware this functionality seems to be the
responsibility of the Peripheral Controller (PC) chip, so name the
device that.
There are several different things that will need to be moved into
this device:
* the mmio_iops register set
* the scr_ops register set
* the next_irq IRQ handling
To ease review, we structure the change as a sequence of commits: in
this first commit we create the skeleton of the NeXTPC device with no
content, but with a backdoor pointer to the NeXTState machine's state
struct so we can move parts of the code and still have refactored and
non-refactored code using the same struct data fields. Further
commits will move functionality into the new device piece by piece.
At the end we will be able to remove the backdoor pointer because all
the data fields will be in the NeXTPC struct and not the NeXTState
struct.
We'll add the VMState for the new device at the end of all that; this
is in theory a migration compatibility break but this machine does
not currently support migration at all anyway.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20210115201206.17347-3-peter.maydell@linaro.org>
[huth: Add a comment in front of struct NeXTPC]
Signed-off-by: Thomas Huth <huth@tuxfamily.org>
The next_irq() function is global, but isn't actually used anywhere
outside next-cube.c. Make it static.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20210115201206.17347-2-peter.maydell@linaro.org>
Signed-off-by: Thomas Huth <huth@tuxfamily.org>
Use g_autoptr() with Object and g_autofree with the string to
avoid the need of a cleanup path.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20210114180628.1675603-6-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The function is called only inside spapr_hcall.c.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20210114180628.1675603-3-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Since commit 1e8b5b1aa1 ("spapr: Allow memory unplug to always succeed")
trying to unplug memory from a guest that doesn't support it (eg. rhel6)
no longer generates an error like it used to. Instead, it leaves the
memory around : only a subsequent reboot or manual use of drmgr within
the guest can complete the hot-unplug sequence. A flag was added to
SpaprMachineClass so that this new behavior only applies to the default
machine type.
We can do better. CAS processes all pending hot-unplug requests. This
means that we don't really care about what the guest supports if
the hot-unplug request happens before CAS.
All guests that we care for, even old ones, set enough bits in OV5
that lead to a non-empty bitmap in spapr->ov5_cas. Use that as a
heuristic to decide if CAS has already occured or not.
Always accept unplug requests that happen before CAS since CAS will
process them. Restore the previous behavior of rejecting them after
CAS when we know that the guest doesn't support memory hot-unplug.
This behavior is suitable for all machine types : this allows to
drop the pre_6_0_memory_unplug flag.
Fixes: 1e8b5b1aa1 ("spapr: Allow memory unplug to always succeed")
Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <161012708715.801107.11418801796987916516.stgit@bahia.lan>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Use the PCI_BUS type cast macro to convert result of qdev_get_child_bus().
Also remove the check for NULL afterwards which should not be needed
because sysbus_create_simple() uses error_abort and we create the PCI
host object here that's expected to have a PCI bus so this shouldn't
fail. Even if it would fail that would be due to a programmer error so
an error message is not necessary.
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
Message-Id: <a4dc55b56eed3ce899b7bf9835b980a114c52598.1610143658.git.balaton@eik.bme.hu>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
This reverts commit e6d5106786 which was added mistakenly. While this
change works it was suggested during review that keeping dependencies
explicit for each board may be better than listing them in a common
option so keep the previous version and revert this change.
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
Message-Id: <8c65807fc7dc1c4c4f6320f2fd6409a3091c88ff.1610143658.git.balaton@eik.bme.hu>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
This reverts commit 038da2adf that was mistakenly added, this
dependency is still needed to get libfdt dependencies even if fdt.o is
not needed by sam460ex.
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
Message-Id: <15a9fa72eed4f02bdbeaef206803d5e22260e2de.1610143658.git.balaton@eik.bme.hu>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Now we've converted all the callsites to directly create the QOM UIC
device themselves, the ppcuic_init() function is unused and can be
removed. The enum defining PPCUIC symbolic constants can be moved
to the ppc-uic.h header where it more naturally belongs.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
Tested-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
Message-Id: <20210108171212.16500-5-peter.maydell@linaro.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Switch the ppc405_uc boards to directly creating and configuring the
UIC, rather than doing it via the old ppcuic_init() helper function.
We retain the API feature of ppc405ep_init() where it passes back
something allowing the callers to wire up devices to the UIC if
they need to, even though neither of the callsites currently makes
use of this ability -- instead of passing back the qemu_irq array
we pass back the UIC DeviceState.
This fixes a trivial Coverity-detected memory leak where
we were leaking the array of IRQs returned by ppcuic_init().
Fixes: Coverity CID 1421922
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20210108171212.16500-4-peter.maydell@linaro.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
In commit 34d0831f38 the ppc-uic device was added, with a dcr-base
property. The intention was that the default value of dcr-base should be
the one that most of our boards need, so that in the common case they
don't need to specify a property value.
All QEMU boards with a UIC use a dcr-base of 0xc0, with the exception of
sam460ex which has four UICs and so puts them at 0xc0, 0xd0, 0xe0, 0xf0.
So 0xc0 is the obvious right choice for the default dcr-base.
The board code conversions in commits 0270d74ef8 (bamboo) and
c5ac9dc64f (virtex_ml507) assumed that default was 0xc0. Unfortunately
the actual default in 34d0831f38 was 0x30, by mistake, so the
bamboo and virtex_ml507 boards were broken as they were converted
away from ppcuic_init() (which always specifies the dcr_base property
value explicitly).
Set the default dcr-base to 0xc0 as was intended, fixing bamboo and
virtex_ml507.
Fixes: 34d0831f38
Reported-by: Nathan Chancellor <natechancellor@gmail.com>
Suggested-by: BALATON Zoltan <balaton@eik.bme.hu>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20210111213007.7381-1-peter.maydell@linaro.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The function ppc405cr_init() has apparently been unused since it was
added in commit 8ecc791352 in 2007.
Remove this dead code, so we don't have to convert it away from using
ppcuic_init().
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20210108171212.16500-3-peter.maydell@linaro.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Switch the sam460ex board to directly creating and configuring the
UIC, rather than doing it via the old ppcuic_init() helper function.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20210108171212.16500-2-peter.maydell@linaro.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
- clean-ups to docker images
- drop duplicate jobs from shippable
- prettier tag generation (+gtags)
- generate browsable source tree
- more Travis->GitLab migrations
- fix checkpatch to deal with commits
- gate gdbstub tests on 8.3.1, expand tests
- support Xfer:auxv:read gdb packet
- better gdbstub cleanup
- use GDB's SVE register layout
- make arm-compat-semihosting common
- add riscv semihosting support
- add HEAPINFO, ELAPSED, TICKFREQ, TMPNAM and ISERROR to semihosting
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEZoWumedRZ7yvyN81+9DbCVqeKkQFAmAFXkcACgkQ+9DbCVqe
KkSP7Af/YNU4dWFf/N9CwvKQTSoJmBrO77HXccOJyYDS62hA8eoh83HWNll+xMV7
GxJDwQs0GS8J3oqcq1DktGgTUkCNxUfbHROjI2YXfRzoWnl0PFHY+Z/qRsq+bRhX
C3CiNCS/nM/NW2Q+H6TAD1MnXkia11+hqFhXrBRKVDON83MSvm0AspS5RO5eVpxo
TUTOD1YND+tAPWi5xAN+NyDuvfoY3tG4S4/DFUrHQfpS7uaHY/4qe8gMmJczveeo
uzJln9M7+pV5cgUWwr1fgCkbSyGgra+KX3GNoLIGS34C88cKRXAp7ZF19A3wQpiy
LXljmOinLfKuJqeRGwcnt6f8GrTn7A==
=XR0h
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/stsquad/tags/pull-testing-and-misc-180121-2' into staging
Testing, gdbstub and semihosting patches:
- clean-ups to docker images
- drop duplicate jobs from shippable
- prettier tag generation (+gtags)
- generate browsable source tree
- more Travis->GitLab migrations
- fix checkpatch to deal with commits
- gate gdbstub tests on 8.3.1, expand tests
- support Xfer:auxv:read gdb packet
- better gdbstub cleanup
- use GDB's SVE register layout
- make arm-compat-semihosting common
- add riscv semihosting support
- add HEAPINFO, ELAPSED, TICKFREQ, TMPNAM and ISERROR to semihosting
# gpg: Signature made Mon 18 Jan 2021 10:09:11 GMT
# 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-misc-180121-2: (30 commits)
semihosting: Implement SYS_ISERROR
semihosting: Implement SYS_TMPNAM
semihosting: Implement SYS_ELAPSED and SYS_TICKFREQ
riscv: Add semihosting support for user mode
riscv: Add semihosting support
semihosting: Support SYS_HEAPINFO when env->boot_info is not set
semihosting: Change internal common-semi interfaces to use CPUState *
semihosting: Change common-semi API to be architecture-independent
semihosting: Move ARM semihosting code to shared directories
target/arm: use official org.gnu.gdb.aarch64.sve layout for registers
gdbstub: ensure we clean-up when terminated
gdbstub: drop gdbserver_cleanup in favour of gdb_exit
gdbstub: drop CPUEnv from gdb_exit()
gdbstub: add support to Xfer:auxv:read: packet
gdbstub: implement a softmmu based test
Revert "tests/tcg/multiarch/Makefile.target: Disable run-gdbstub-sha1 test"
configure: gate our use of GDB to 8.3.1 or above
test/guest-debug: echo QEMU command as well
scripts/checkpatch.pl: fix git-show invocation to include diffstat
gitlab: migrate the minimal tools and unit tests from Travis
...
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
# Conflicts:
# default-configs/targets/riscv32-linux-user.mak
# default-configs/targets/riscv64-linux-user.mak
When running device-introspect-test, a memory leak occurred in the mos6522_init
function, this patch use timer_free() in the finalize function to fix it.
ASAN shows memory leak stack:
Direct leak of 96 byte(s) in 2 object(s) allocated from:
#0 0xfffd5fe9e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0)
#1 0xfffd5f7b6800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800)
#2 0xaaae50303d0c in timer_new_full qemu/include/qemu/timer.h:523
#3 0xaaae50303d0c in timer_new qemu/include/qemu/timer.h:544
#4 0xaaae50303d0c in timer_new_ns qemu/include/qemu/timer.h:562
#5 0xaaae50303d0c in mos6522_init qemu/hw/misc/mos6522.c:490
#6 0xaaae50b77d70 in object_init_with_type qemu/qom/object.c:371
#7 0xaaae50b7ae84 in object_initialize_with_type qemu/qom/object.c:515
#8 0xaaae50b7b0f8 in object_new_with_type qemu/qom/object.c:729
#9 0xaaae50bb6d58 in qmp_device_list_properties qemu/qom/qom-qmp-cmds.c:153
#10 0xaaae50d7e1dc in qmp_marshal_device_list_properties qemu/qapi/qapi-commands-qdev.c:59
#11 0xaaae50dc87a0 in do_qmp_dispatch_bh qemu/qapi/qmp-dispatch.c:110
#12 0xaaae50d931a0 in aio_bh_call qemu/util/async.c:136
Reported-by: Euler Robot <euler.robot@huawei.com>
Signed-off-by: Gan Qixin <ganqixin@huawei.com>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20210112112705.380534-3-ganqixin@huawei.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
When running device-introspect-test, a memory leak occurred in the pl031_init
function, this patch use timer_free() in the finalize function to fix it.
ASAN shows memory leak stack:
Direct leak of 48 byte(s) in 1 object(s) allocated from:
#0 0xffffab97e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0)
#1 0xffffab256800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800)
#2 0xaaabf5621cfc in timer_new_full qemu/include/qemu/timer.h:523
#3 0xaaabf5621cfc in timer_new qemu/include/qemu/timer.h:544
#4 0xaaabf5621cfc in timer_new_ns qemu/include/qemu/timer.h:562
#5 0xaaabf5621cfc in pl031_init qemu/hw/rtc/pl031.c:194
#6 0xaaabf6339f6c in object_initialize_with_type qemu/qom/object.c:515
#7 0xaaabf633a1e0 in object_new_with_type qemu/qom/object.c:729
#8 0xaaabf6375e40 in qmp_device_list_properties qemu/qom/qom-qmp-cmds.c:153
#9 0xaaabf5a95540 in qdev_device_help qemu/softmmu/qdev-monitor.c:283
#10 0xaaabf5a96940 in qmp_device_add qemu/softmmu/qdev-monitor.c:801
#11 0xaaabf5a96e70 in hmp_device_add qemu/softmmu/qdev-monitor.c:916
#12 0xaaabf5ac0a2c in handle_hmp_command qemu/monitor/hmp.c:1100
Reported-by: Euler Robot <euler.robot@huawei.com>
Signed-off-by: Gan Qixin <ganqixin@huawei.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20210112112705.380534-2-ganqixin@huawei.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
This PR:
- Fixes some issues with the m25p80
- Improves GDB support for RISC-V
- Fixes some Linux boot issues, specifiaclly 32-bit boot failures
- Enforces PMP exceptions correctly
- Fixes some Coverity issues
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEE9sSsRtSTSGjTuM6PIeENKd+XcFQFAmAEsc8ACgkQIeENKd+X
cFT3cwf+NNPVzjl0T7OEI1XxL6UCEkX6/cgxPv+ChjMCRlfnts9iHMWyeiO8E4mG
qORpLe5YCT+tAVA+rKKVu8ADp5pE9sdRp8gO7TMhZaHi3r1CQpsleZWE9R0IoBIu
eiENTgFHIV3VFcJQpOgorqCJ9qRnx2pPjjwf0H8G/hMYcgaMAzz+rdK+XvP0cCaY
/U78g0pPWx1MwdIFhhhaxAhbthnv6TkWf6oSPeGezDaAp1tnNg/Bd+FL6pT0vAM9
Mhr39TqrOJ/R0npsTngVe5Rl23Gqh3/1AYOnZz1+e9J0pB4YXnxwwiuV0t8lZnsw
OFIGXm7V3dL8BQ4ycZojlIkmML2Siw==
=3q/k
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/alistair/tags/pull-riscv-to-apply-20210117-3' into staging
First RISC-V PR for 6.0
This PR:
- Fixes some issues with the m25p80
- Improves GDB support for RISC-V
- Fixes some Linux boot issues, specifiaclly 32-bit boot failures
- Enforces PMP exceptions correctly
- Fixes some Coverity issues
# gpg: Signature made Sun 17 Jan 2021 21:53:19 GMT
# gpg: using RSA key F6C4AC46D4934868D3B8CE8F21E10D29DF977054
# gpg: Good signature from "Alistair Francis <alistair@alistair23.me>" [full]
# Primary key fingerprint: F6C4 AC46 D493 4868 D3B8 CE8F 21E1 0D29 DF97 7054
* remotes/alistair/tags/pull-riscv-to-apply-20210117-3:
riscv: Pass RISCVHartArrayState by pointer
target/riscv: Remove built-in GDB XML files for CSRs
target/riscv: Generate the GDB XML file for CSR registers dynamically
target/riscv: Add CSR name in the CSR function table
target/riscv: Make csr_ops[CSR_TABLE_SIZE] external
hw/misc/sifive_u_otp: handling the fails of blk_pread and blk_pwrite
hw/riscv: sifive_u: Use SIFIVE_U_CPU for mc->default_cpu_type
target/riscv/pmp: Raise exception if no PMP entry is configured
RISC-V: Place DTB at 3GB boundary instead of 4GB
gdb: riscv: Add target description
hw/block: m25p80: Implement AAI-WP command support for SST flashes
hw/block: m25p80: Don't write to flash if write is disabled
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Part of Semihosting for AArch32 and AArch64 Release 2.0
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20210107170717.2098982-10-keithp@keithp.com>
Message-Id: <20210108224256.2321-21-alex.bennee@linaro.org>
Part of Semihosting for AArch32 and AArch64 Release 2.0
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20210107170717.2098982-9-keithp@keithp.com>
Message-Id: <20210108224256.2321-20-alex.bennee@linaro.org>
These are part of Semihosting for AArch32 and AArch64 Release 2.0
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20210107170717.2098982-8-keithp@keithp.com>
Message-Id: <20210108224256.2321-19-alex.bennee@linaro.org>
Adapt the arm semihosting support code for RISCV. This implementation
is based on the standard for RISC-V semihosting version 0.2 as
documented in
https://github.com/riscv/riscv-semihosting-spec/releases/tag/0.2
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-Id: <20210107170717.2098982-6-keithp@keithp.com>
Message-Id: <20210108224256.2321-17-alex.bennee@linaro.org>
env->boot_info is only set in some ARM startup paths, so we cannot
rely on it to support the SYS_HEAPINFO semihosting function. When not
available, fallback to finding a RAM memory region containing the
current stack and use the base of that.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20210107170717.2098982-5-keithp@keithp.com>
Message-Id: <20210108224256.2321-16-alex.bennee@linaro.org>
This makes all of the internal interfaces architecture-independent and
renames the internal functions to use the 'common_semi' prefix instead
of 'arm' or 'arm_semi'.
To do this, some new architecture-specific internal helper functions
were created:
static inline target_ulong
common_semi_arg(CPUState *cs, int argno)
Returns the argno'th semihosting argument, where argno can be
either 0 or 1.
static inline void
common_semi_set_ret(CPUState *cs, target_ulong ret)
Sets the semihosting return value.
static inline bool
common_semi_sys_exit_extended(CPUState *cs, int nr)
This detects whether the specified semihosting call, which
is either TARGET_SYS_EXIT or TARGET_SYS_EXIT_EXTENDED should
be executed using the TARGET_SYS_EXIT_EXTENDED semantics.
static inline target_ulong
common_semi_rambase(CPUState *cs)
Returns the base of RAM region used for heap and stack. This
is used to construct plausible values for the SYS_HEAPINFO
call.
In addition, several existing functions have been changed to flag
areas of code which are architecture specific:
static target_ulong
common_semi_flen_buf(CPUState *cs)
Returns the current stack pointer minus 64, which is
where a stat structure will be placed on the stack
#define GET_ARG(n)
This fetches arguments from the semihosting command's argument
block. The address of this is available implicitly through the
local 'args' variable. This is *mostly* architecture
independent, but does depend on the current ABI's notion of
the size of a 'long' parameter, which may need run-time checks
(as it does on AARCH64)
#define SET_ARG(n, val)
This mirrors GET_ARG and stores data back into the argument
block.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-Id: <20210107170717.2098982-4-keithp@keithp.com>
Message-Id: <20210108224256.2321-15-alex.bennee@linaro.org>
The public API is now defined in
hw/semihosting/common-semi.h. do_common_semihosting takes CPUState *
instead of CPUARMState *. All internal functions have been renamed
common_semi_ instead of arm_semi_ or arm_. Aside from the API change,
there are no functional changes in this patch.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-Id: <20210107170717.2098982-3-keithp@keithp.com>
Message-Id: <20210108224256.2321-14-alex.bennee@linaro.org>
This commit renames two files which provide ARM semihosting support so
that they can be shared by other architectures:
1. target/arm/arm-semi.c -> hw/semihosting/common-semi.c
2. linux-user/arm/semihost.c -> linux-user/semihost.c
The build system was modified use a new config variable,
CONFIG_ARM_COMPATIBLE_SEMIHOSTING, which has been added to the ARM
softmmu and linux-user default configs. The contents of the source
files has not been changed in this patch.
Signed-off-by: Keith Packard <keithp@keithp.com>
[AJB: rename arm-compat-semi, select SEMIHOSTING]
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20210107170717.2098982-2-keithp@keithp.com>
Message-Id: <20210108224256.2321-13-alex.bennee@linaro.org>
PXB is now supported on ARM, so let's compile for arm_virt machine.
Acked-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Jiahui Cen <cenjiahui@huawei.com>
Message-Id: <20210114100643.10617-7-cenjiahui@huawei.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Exclude the resources of extra root bridges from PCI0's _CRS. Otherwise,
the resource windows would overlap in guest, and the IO resource window
would fail to be registered.
Acked-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Jiahui Cen <cenjiahui@huawei.com>
Message-Id: <20210114100643.10617-6-cenjiahui@huawei.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
There may be some differences in pci resource assignment between guest os
and firmware.
Eg. A Bridge with Bus [d2]
-+-[0000:d2]---01.0-[d3]----01.0
where [d2:01.00] is a pcie-pci-bridge with BAR0 (mem, 64-bit, non-pref) [size=256]
[d3:01.00] is a PCI Device with BAR0 (mem, 64-bit, pref) [size=128K]
BAR4 (mem, 64-bit, pref) [size=64M]
In EDK2, the Resource Map would be:
PciBus: Resource Map for Bridge [D2|01|00]
Type = PMem64; Base = 0x8004000000; Length = 0x4100000; Alignment = 0x3FFFFFF
Base = 0x8004000000; Length = 0x4000000; Alignment = 0x3FFFFFF; Owner = PCI [D3|01|00:20]
Base = 0x8008000000; Length = 0x20000; Alignment = 0x1FFFF; Owner = PCI [D3|01|00:10]
Type = Mem64; Base = 0x8008100000; Length = 0x100; Alignment = 0xFFF
It would use 0x4100000 to calculate the root bus's PMem64 resource window.
While in Linux, kernel will use 0x1FFFFFF as the alignment to calculate
the PMem64 size, which would be 0x6000000. So kernel would try to
allocate 0x6000000 from the PMem64 resource window, but since the window
size is 0x4100000 as assigned by EDK2, the allocation would fail.
The diffences could result in resource assignment failure.
Using _DSM #5 method to inform guest os not to ignore the PCI configuration
that firmware has done at boot time could handle the differences.
Acked-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Jiahui Cen <cenjiahui@huawei.com>
Message-Id: <20210114100643.10617-5-cenjiahui@huawei.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
AML needs Address Translation offset to describe how a bridge translates
addresses accross the bridge when using an address descriptor, and
especially on ARM, the translation offset of pio resource is usually
non zero.
Therefore, it's necessary to pass offset for pio, mmio32, mmio64 and bus
number into build_crs.
Acked-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Jiahui Cen <cenjiahui@huawei.com>
Message-Id: <20210114100643.10617-4-cenjiahui@huawei.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
We were accidently passing RISCVHartArrayState by value instead of
pointer. The type is 824 bytes long so let's correct that and pass it by
pointer instead.
Fixes: Coverity CID 1438099
Fixes: Coverity CID 1438100
Fixes: Coverity CID 1438101
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com>
Reviewed-by: Bin Meng <bin.meng@windriver.com>
Message-id: f3e04424723e0e222769991896cc82308fd23f76.1610751609.git.alistair.francis@wdc.com
Fix code coverage issues by checking return value and handling fail case
of blk_pread() and blk_pwrite(). Return default value 0xff if read fails.
Fixes: Coverity CID 1435959
Fixes: Coverity CID 1435960
Fixes: Coverity CID 1435961
Signed-off-by: Green Wan <green.wan@sifive.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-id: 20201104092900.21214-1-green.wan@sifive.com
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
SIFIVE_U_CPU is conditionally set to SIFIVE_U34 or SIFIVE_U54, hence
there is no need to use #idef to set the mc->default_cpu_type.
Signed-off-by: Bin Meng <bin.meng@windriver.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-id: 20210109143637.29645-1-bmeng.cn@gmail.com
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Currently, we place the DTB at 2MB from 4GB or end of DRAM which ever is
lesser. However, Linux kernel can address only 1GB of memory for RV32.
Thus, it can not map anything beyond 3GB (assuming 2GB is the starting address).
As a result, it can not process DT and panic if opensbi dynamic firmware
is used. While at it, place the DTB further away to avoid in memory placement
issues in future.
Fix this by placing the DTB at 16MB from 3GB or end of DRAM whichever is lower.
Fixes: 66b1205bc5 ("RISC-V: Copy the fdt in dram instead of ROM")
Reviewed-by: Bin Meng <bin.meng@windriver.com>
Tested-by: Bin Meng <bin.meng@windriver.com>
Signed-off-by: Atish Patra <atish.patra@wdc.com>
Message-id: 20210107091127.3407870-1-atish.patra@wdc.com
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Auto Address Increment (AAI) Word-Program is a special command of
SST flashes. AAI-WP allows multiple bytes of data to be programmed
without re-issuing the next sequential address location.
Signed-off-by: Xuzhou Cheng <xuzhou.cheng@windriver.com>
Signed-off-by: Bin Meng <bin.meng@windriver.com>
Reviewed-by: Francisco Iglesias <frasse.iglesias@gmail.com>
Message-id: 1608688825-81519-2-git-send-email-bmeng.cn@gmail.com
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
When write is disabled, the write to flash should be avoided
in flash_write8().
Fixes: 82a2499011 ("m25p80: Initial implementation of SPI flash device")
Signed-off-by: Bin Meng <bin.meng@windriver.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Francisco Iglesias <frasse.iglesias@gmail.com>
Message-id: 1608688825-81519-1-git-send-email-bmeng.cn@gmail.com
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Depending on the client activity, the server can be asked to open a huge
number of file descriptors and eventually hit RLIMIT_NOFILE. This is
currently mitigated using a reclaim logic : the server closes the file
descriptors of idle fids, based on the assumption that it will be able
to re-open them later. This assumption doesn't hold of course if the
client requests the file to be unlinked. In this case, we loop on the
entire fid list and mark all related fids as unreclaimable (the reclaim
logic will just ignore them) and, of course, we open or re-open their
file descriptors if needed since we're about to unlink the file.
This is the purpose of v9fs_mark_fids_unreclaim(). Since the actual
opening of a file can cause the coroutine to yield, another client
request could possibly add a new fid that we may want to mark as
non-reclaimable as well. The loop is thus restarted if the re-open
request was actually transmitted to the backend. This is achieved
by keeping a reference on the first fid (head) before traversing
the list.
This is wrong in several ways:
- a potential clunk request from the client could tear the first
fid down and cause the reference to be stale. This leads to a
use-after-free error that can be detected with ASAN, using a
custom 9p client
- fids are added at the head of the list : restarting from the
previous head will always miss fids added by a some other
potential request
All these problems could be avoided if fids were being added at the
end of the list. This can be achieved with a QSIMPLEQ, but this is
probably too much change for a bug fix. For now let's keep it
simple and just restart the loop from the current head.
Fixes: CVE-2021-20181
Buglink: https://bugs.launchpad.net/qemu/+bug/1911666
Reported-by: Zero Day Initiative <zdi-disclosures@trendmicro.com>
Reviewed-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Message-Id: <161064025265.1838153.15185571283519390907.stgit@bahia.lan>
Signed-off-by: Greg Kurz <groug@kaod.org>
The 'fulong2e' machine alias has been marked as deprecated since
QEMU v5.1 (commit c3a09ff68d, the machine is renamed 'fuloong2e').
Time to remove it now.
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Huacai Chen <chenhuacai@kernel.org>
Reviewed-by: Thomas Huth <huth@tuxfamily.org>
Message-Id: <20210106184602.3771551-1-f4bug@amsat.org>
Directly check if the CPU supports 64-bit with the recently
added cpu_type_is_64bit() helper (inlined).
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20210104221154.3127610-6-f4bug@amsat.org>
virtio-fs qualifies as a bootable device minimally under OVMF, but
currently the necessary "bootindex" property is missing. Add the property.
Expose the property only in the PCI device, for now. There is no boot
support for virtiofs on s390x (ccw) for the time being [1] [2], so leave
the CCW device unchanged. Add the property to the base device still,
because adding the alias to the CCW device later will be easier this way
[3].
[1] https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg01745.html
[2] https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg01870.html
[3] https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg01751.html
Example OpenFirmware device path for the "vhost-user-fs-pci" device in the
"bootorder" fw_cfg file:
/pci@i0cf8/pci-bridge@1,6/pci1af4,105a@0/filesystem@0
Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Ján Tomko <jtomko@redhat.com>
Cc: Stefan Hajnoczi <stefanha@redhat.com>
Cc: virtio-fs@redhat.com
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Message-Id: <20210112131603.12686-1-lersek@redhat.com>
Acked-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
When the slot is in steady powered-off state and the device is being
removed, there's no need to press the attention button. Nor is it
mandated by the Standard Hot-Plug Controller Specification, Rev. 1.0.
Moreover it confuses the guest, Linux in particular, as it assumes that
the attention button pressed in this state indicates that the device has
been inserted and will need to be powered on. Therefore it transitions
the slot into BLINKING_ON state for 5 seconds, and discovers at the end
that no device is actually inserted:
... unplug request
[12685.451329] shpchp 0000:01:00.0: Button pressed on Slot(2)
[12685.455478] shpchp 0000:01:00.0: PCI slot #2 - powering off due to button press
... in 5 seconds OS powers off the slot, QEMU ejects the device
[12690.632282] shpchp 0000:01:00.0: Latch open on Slot(2)
... excessive button press in steady powered-off state
[12690.634267] shpchp 0000:01:00.0: Button pressed on Slot(2)
[12690.636256] shpchp 0000:01:00.0: Card not present on Slot(2)
... the last button press spawns powering on the slot
[12690.638909] shpchp 0000:01:00.0: PCI slot #2 - powering on due to button press
... in 5 more seconds attempt to power on discovers empty slot
[12695.735986] shpchp 0000:01:00.0: No adapter on slot(2)
Worse, if the real device insertion happens within 5 seconds from the
apparent completion of the previous device removal (signaled via
DEVICE_DELETED event), the new button press will be interpreted as the
cancellation of that misguided powering on:
[13448.965295] shpchp 0000:01:00.0: Button pressed on Slot(2)
[13448.969430] shpchp 0000:01:00.0: PCI slot #2 - powering off due to button press
[13454.025107] shpchp 0000:01:00.0: Latch open on Slot(2)
[13454.027101] shpchp 0000:01:00.0: Button pressed on Slot(2)
[13454.029165] shpchp 0000:01:00.0: Card not present on Slot(2)
... the excessive button press spawns powering on the slot
... device has already been ejected by QEMU
[13454.031949] shpchp 0000:01:00.0: PCI slot #2 - powering on due to button press
... new device is inserted in the slot
[13456.861545] shpchp 0000:01:00.0: Latch close on Slot(2)
... valid button press arrives before 5 s since the wrong one
[13456.864894] shpchp 0000:01:00.0: Button pressed on Slot(2)
[13456.869211] shpchp 0000:01:00.0: Card present on Slot(2)
... the valid button press is counted as cancellation of the wrong one
[13456.873173] shpchp 0000:01:00.0: Button cancel on Slot(2)
[13456.877101] shpchp 0000:01:00.0: PCI slot #2 - action canceled due to button press
As a result, the newly inserted device isn't brought up by the guest.
Avoid this situation by not pushing the attention button when the device
in the slot is in powered-off state and is being ejected.
FWIW pcie implementation doesn't suffer from this problem.
Signed-off-by: Roman Kagan <rvkagan@yandex-team.ru>
Message-Id: <20201102053750.2281818-1-rvkagan@yandex-team.ru>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Now that all of the object property links to the heathrow PIC and OpenPIC have
been removed from the macio devices, it is safe to allow the macio-oldworld
and macio-neworld devices to be marked as user_creatable.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Message-Id: <20201229175619.6051-8-mark.cave-ayland@ilande.co.uk>
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
This both allows the wiring to be done as Ben suggested in his original comment in
gpio.c and also enables the OpenPIC object property link to be removed.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Message-Id: <20201229175619.6051-7-mark.cave-ayland@ilande.co.uk>
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
The OpenPIC device is located within the macio device on real hardware so make it
a child of the macio-newworld device. This also removes the need for setting and
checking a separate PIC object property link on the macio-newworld device which
currently causes the automated QOM introspection tests to fail.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Message-Id: <20201229175619.6051-6-mark.cave-ayland@ilande.co.uk>
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
In order to move the OpenPIC device to the macio device, the PCI bus needs to be
initialised before the macio device and also before wiring the OpenPIC IRQs.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Message-Id: <20201229175619.6051-5-mark.cave-ayland@ilande.co.uk>
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
The heathrow PIC is located within the macio device on real hardware so make it
a child of the macio-oldworld device. This also removes the need for setting and
checking a separate PIC object property link on the macio-oldworld device which
currently causes the automated QOM introspection tests to fail.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Message-Id: <20201229175619.6051-4-mark.cave-ayland@ilande.co.uk>
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
In order to move the heathrow PIC to the macio device, the PCI bus needs to be
initialised before the macio device and also before wiring the PIC IRQs.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Message-Id: <20201229175619.6051-3-mark.cave-ayland@ilande.co.uk>
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
This condition will have already been caught when wiring the heathrow PIC
IRQs to the CPU.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Message-Id: <20201229175619.6051-2-mark.cave-ayland@ilande.co.uk>
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
A device shouldn't access its parent object which is QOM internal.
Instead it should use type cast for this purporse. This patch fixes this
issue for all NPCM7XX Devices.
Signed-off-by: Hao Wu <wuhaotsh@google.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20210108190945.949196-7-wuhaotsh@google.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The PWM module is part of NPCM7XX module. Each NPCM7XX module has two
identical PWM modules. Each module contains 4 PWM entries. Each PWM has
two outputs: frequency and duty_cycle. Both are computed using inputs
from software side.
This module does not model detail pulse signals since it is expensive.
It also does not model interrupts and watchdogs that are dependant on
the detail models. The interfaces for these are left in the module so
that anyone in need for these functionalities can implement on their
own.
The user can read the duty cycle and frequency using qom-get command.
Reviewed-by: Havard Skinnemoen <hskinnemoen@google.com>
Reviewed-by: Tyrone Ting <kfting@nuvoton.com>
Signed-off-by: Hao Wu <wuhaotsh@google.com>
Message-id: 20210108190945.949196-5-wuhaotsh@google.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The ADC is part of NPCM7XX Module. Its behavior is controled by the
ADC_CON register. It converts one of the eight analog inputs into a
digital input and stores it in the ADC_DATA register when enabled.
Users can alter input value by using qom-set QMP command.
Reviewed-by: Havard Skinnemoen <hskinnemoen@google.com>
Reviewed-by: Tyrone Ting <kfting@nuvoton.com>
Signed-off-by: Hao Wu <wuhaotsh@google.com>
Message-id: 20210108190945.949196-4-wuhaotsh@google.com
[PMM: Added missing hw/adc/trace.h file]
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
This patch makes NPCM7XX Timer to use a the timer clock generated by the
CLK module instead of the magic number TIMER_REF_HZ.
Reviewed-by: Havard Skinnemoen <hskinnemoen@google.com>
Reviewed-by: Tyrone Ting <kfting@nuvoton.com>
Signed-off-by: Hao Wu <wuhaotsh@google.com>
Message-id: 20210108190945.949196-3-wuhaotsh@google.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
This patch allows NPCM7XX CLK module to compute clocks that are used by
other NPCM7XX modules.
Add a new struct NPCM7xxClockConverterState which represents a
single converter. Each clock converter in CLK module represents one
converter in NPCM7XX CLK Module(PLL, SEL or Divider). Each converter
takes one or more input clocks and converts them into one output clock.
They form a clock hierarchy in the CLK module and are responsible for
outputing clocks for various other modules in an NPCM7XX SoC.
Each converter has a function pointer called "convert" which represents
the unique logic for that converter.
The clock contains two initialization information: ConverterInitInfo and
ConverterConnectionInfo. They represent the vertices and edges in the
clock diagram respectively.
Reviewed-by: Havard Skinnemoen <hskinnemoen@google.com>
Reviewed-by: Tyrone Ting <kfting@nuvoton.com>
Signed-off-by: Hao Wu <wuhaotsh@google.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20210108190945.949196-2-wuhaotsh@google.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The lan9118 code mostly uses symbolic constants for register offsets;
the exceptions are those which the datasheet doesn't give an official
symbolic name to.
Add some names for the registers which don't already have them, based
on the longer names they are given in the memory map.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-id: 20210108180401.2263-3-peter.maydell@linaro.org
Add trace events for virtio command and response tracing.
Signed-off-by: Hannes Reinecke <hare@suse.de>
Message-Id: <20201116183114.55703-2-hare@suse.de>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
At present, when booting U-Boot on QEMU sabrelite, we see:
Net: Board Net Initialization Failed
No ethernet found.
U-Boot scans PHY at address 4/5/6/7 (see board_eth_init() in the
U-Boot source: board/boundary/nitrogen6x/nitrogen6x.c). On the real
board, the Ethernet PHY is at address 6. Adjust this by updating the
"fec-phy-num" property of the fsl_imx6 SoC object.
With this change, U-Boot sees the PHY but complains MAC address:
Net: using phy at 6
FEC [PRIME]
Error: FEC address not set.
This is due to U-Boot tries to read the MAC address from the fuse,
which QEMU does not have any valid content filled in. However this
does not prevent the Ethernet from working in QEMU. We just need to
set up the MAC address later in the U-Boot command shell, by:
=> setenv ethaddr 00:11:22:33:44:55
Signed-off-by: Bin Meng <bin.meng@windriver.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Message-id: 20210106063504.10841-4-bmeng.cn@gmail.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Currently when U-Boot boots, it prints "??" for i.MX processor:
CPU: Freescale i.MX?? rev1.0 at 792 MHz
The register that was used to determine the silicon type is
undocumented in the latest IMX6DQRM (Rev. 6, 05/2020), but we
can refer to get_cpu_rev() in arch/arm/mach-imx/mx6/soc.c in
the U-Boot source codes that USB_ANALOG_DIGPROG is used.
Update its reset value to indicate i.MX6Q.
Signed-off-by: Bin Meng <bin.meng@windriver.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Message-id: 20210106063504.10841-3-bmeng.cn@gmail.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
U-Boot expects PMU_MISC0 register bit 7 is set (see init_bandgap()
in arch/arm/mach-imx/mx6/soc.c) during boot. This bit indicates the
bandgap has stabilized.
With this change, the latest upstream U-Boot (v2021.01-rc3) for imx6
sabrelite board (mx6qsabrelite_defconfig), with a slight change made
by switching CONFIG_OF_SEPARATE to CONFIG_OF_EMBED, boots to U-Boot
shell on QEMU with the following command:
$ qemu-system-arm -M sabrelite -smp 4 -m 1G -kernel u-boot \
-display none -serial null -serial stdio
Boot log below:
U-Boot 2021.01-rc3 (Dec 12 2020 - 17:40:02 +0800)
CPU: Freescale i.MX?? rev1.0 at 792 MHz
Reset cause: POR
Model: Freescale i.MX6 Quad SABRE Lite Board
Board: SABRE Lite
I2C: ready
DRAM: 1 GiB
force_idle_bus: sda=0 scl=0 sda.gp=0x5c scl.gp=0x55
force_idle_bus: failed to clear bus, sda=0 scl=0
force_idle_bus: sda=0 scl=0 sda.gp=0x6d scl.gp=0x6c
force_idle_bus: failed to clear bus, sda=0 scl=0
force_idle_bus: sda=0 scl=0 sda.gp=0xcb scl.gp=0x5
force_idle_bus: failed to clear bus, sda=0 scl=0
MMC: FSL_SDHC: 0, FSL_SDHC: 1
Loading Environment from MMC... *** Warning - No block device, using default environment
In: serial
Out: serial
Err: serial
Net: Board Net Initialization Failed
No ethernet found.
starting USB...
Bus usb@2184000: usb dr_mode not found
USB EHCI 1.00
Bus usb@2184200: USB EHCI 1.00
scanning bus usb@2184000 for devices... 1 USB Device(s) found
scanning bus usb@2184200 for devices... 1 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
scanning usb for ethernet devices... 0 Ethernet Device(s) found
Hit any key to stop autoboot: 0
=>
Signed-off-by: Bin Meng <bin.meng@windriver.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Message-id: 20210106063504.10841-2-bmeng.cn@gmail.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
When running device-introspect-test, a memory leak occurred in the
exynos4210_mct_init function, so use ptimer_free() in the finalize function to
avoid it.
ASAN shows memory leak stack:
Indirect leak of 96 byte(s) in 1 object(s) allocated from:
#0 0xffffab97e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0)
#1 0xffffab256800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800)
#2 0xaaabf555db78 in ptimer_init /qemu/hw/core/ptimer.c:432
#3 0xaaabf56b01a0 in exynos4210_mct_init /qemu/hw/timer/exynos4210_mct.c:1505
#4 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515
#5 0xaaabf633a1e0 in object_new_with_type /qemu/qom/object.c:729
#6 0xaaabf6375e40 in qmp_device_list_properties /qemu/qom/qom-qmp-cmds.c:153
#7 0xaaabf653d8ec in qmp_marshal_device_list_properties /qemu/qapi/qapi-commands-qdev.c:59
#8 0xaaabf6587d08 in do_qmp_dispatch_bh /qemu/qapi/qmp-dispatch.c:110
#9 0xaaabf6552708 in aio_bh_call /qemu/util/async.c:136
#10 0xaaabf6552708 in aio_bh_poll /qemu/util/async.c:164
#11 0xaaabf655f19c in aio_dispatch /qemu/util/aio-posix.c:381
#12 0xaaabf65523f4 in aio_ctx_dispatch /qemu/util/async.c:306
Reported-by: Euler Robot <euler.robot@huawei.com>
Signed-off-by: Gan Qixin <ganqixin@huawei.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
When running device-introspect-test, a memory leak occurred in the
mv88w8618_pit_init function, so use ptimer_free() in the finalize function to
avoid it.
ASAN shows memory leak stack:
Indirect leak of 192 byte(s) in 4 object(s) allocated from:
#0 0xffffab97e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0)
#1 0xffffab256800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800)
#2 0xaaabf555db84 in timer_new_full /qemu/include/qemu/timer.h:523
#3 0xaaabf555db84 in timer_new /qemu/include/qemu/timer.h:544
#4 0xaaabf555db84 in timer_new_ns /qemu/include/qemu/timer.h:562
#5 0xaaabf555db84 in ptimer_init /qemu/hw/core/ptimer.c:433
#6 0xaaabf5bb2290 in mv88w8618_timer_init /qemu/hw/arm/musicpal.c:862
#7 0xaaabf5bb2290 in mv88w8618_pit_init /qemu/hw/arm/musicpal.c:954
#8 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515
#9 0xaaabf633a1e0 in object_new_with_type /qemu/qom/object.c:729
#10 0xaaabf6375e40 in qmp_device_list_properties /qemu/qom/qom-qmp-cmds.c:153
#11 0xaaabf5a95540 in qdev_device_help /qemu/softmmu/qdev-monitor.c:283
#12 0xaaabf5a96940 in qmp_device_add /qemu/softmmu/qdev-monitor.c:801
Reported-by: Euler Robot <euler.robot@huawei.com>
Signed-off-by: Gan Qixin <ganqixin@huawei.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
When running device-introspect-test, a memory leak occurred in the
mss_timer_init function, so use ptimer_free() in the finalize function to avoid
it.
ASAN shows memory leak stack:
Indirect leak of 192 byte(s) in 2 object(s) allocated from:
#0 0xffffab97e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0)
#1 0xffffab256800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800)
#2 0xaaabf555db78 in ptimer_init /qemu/hw/core/ptimer.c:432
#3 0xaaabf58a0010 in mss_timer_init /qemu/hw/timer/mss-timer.c:235
#4 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515
#5 0xaaabf633ca04 in object_initialize_child_with_propsv /qemu/qom/object.c:564
#6 0xaaabf633cc08 in object_initialize_child_with_props /qemu/qom/object.c:547
#7 0xaaabf5b8316c in m2sxxx_soc_initfn /qemu/hw/arm/msf2-soc.c:70
#8 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515
#9 0xaaabf633a1e0 in object_new_with_type /qemu/qom/object.c:729
#10 0xaaabf6375e40 in qmp_device_list_properties /qemu/qom/qom-qmp-cmds.c:153
#11 0xaaabf653d8ec in qmp_marshal_device_list_properties /qemu/qapi/qapi-commands-qdev.c:59
#12 0xaaabf6587d08 in do_qmp_dispatch_bh /qemu/qapi/qmp-dispatch.c:110
Reported-by: Euler Robot <euler.robot@huawei.com>
Signed-off-by: Gan Qixin <ganqixin@huawei.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
When running device-introspect-test, a memory leak occurred in the
exynos4210_pwm_init function, so use ptimer_free() in the finalize function to
avoid it.
ASAN shows memory leak stack:
Indirect leak of 240 byte(s) in 5 object(s) allocated from:
#0 0xffffab97e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0)
#1 0xffffab256800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800)
#2 0xaaabf555db84 in timer_new_full /qemu/include/qemu/timer.h:523
#3 0xaaabf555db84 in timer_new /qemu/include/qemu/timer.h:544
#4 0xaaabf555db84 in timer_new_ns /qemu/include/qemu/timer.h:562
#5 0xaaabf555db84 in ptimer_init /qemu/hw/core/ptimer.c:433
#6 0xaaabf56a36cc in exynos4210_pwm_init /qemu/hw/timer/exynos4210_pwm.c:401
#7 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515
#8 0xaaabf633a1e0 in object_new_with_type /qemu/qom/object.c:729
#9 0xaaabf6375e40 in qmp_device_list_properties /qemu/qom/qom-qmp-cmds.c:153
#10 0xaaabf653d8ec in qmp_marshal_device_list_properties /qemu/qapi/qapi-commands-qdev.c:59
#11 0xaaabf6587d08 in do_qmp_dispatch_bh /qemu/qapi/qmp-dispatch.c:110
#12 0xaaabf6552708 in aio_bh_call /qemu/util/async.c:136
Reported-by: Euler Robot <euler.robot@huawei.com>
Signed-off-by: Gan Qixin <ganqixin@huawei.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
When running device-introspect-test, a memory leak occurred in the
exynos4210_rtc_init function, so use ptimer_free() in the finalize function to
avoid it.
ASAN shows memory leak stack:
Indirect leak of 96 byte(s) in 1 object(s) allocated from:
#0 0xffffab97e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0)
#1 0xffffab256800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800)
#2 0xaaabf555db78 in ptimer_init /qemu/hw/core/ptimer.c:432
#3 0xaaabf57b3934 in exynos4210_rtc_init /qemu/hw/rtc/exynos4210_rtc.c:567
#4 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515
#5 0xaaabf633a1e0 in object_new_with_type /qemu/qom/object.c:729
#6 0xaaabf6375e40 in qmp_device_list_properties /qemu/qom/qom-qmp-cmds.c:153
#7 0xaaabf653d8ec in qmp_marshal_device_list_properties /qemu/qapi/qapi-commands-qdev.c:59
#8 0xaaabf6587d08 in do_qmp_dispatch_bh /qemu/qapi/qmp-dispatch.c:110
#9 0xaaabf6552708 in aio_bh_call /qemu/util/async.c:136
#10 0xaaabf6552708 in aio_bh_poll /qemu/util/async.c:164
#11 0xaaabf655f19c in aio_dispatch /qemu/util/aio-posix.c:381
#12 0xaaabf65523f4 in aio_ctx_dispatch /qemu/util/async.c:306
Reported-by: Euler Robot <euler.robot@huawei.com>
Signed-off-by: Gan Qixin <ganqixin@huawei.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
When running device-introspect-test, a memory leak occurred in the a10_pit_init
function, so use ptimer_free() in the finalize function to avoid it.
ASAN shows memory leak stack:
Indirect leak of 288 byte(s) in 6 object(s) allocated from:
#0 0xffffab97e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0)
#1 0xffffab256800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800)
#2 0xaaabf555db84 in timer_new_full /qemu/include/qemu/timer.h:523
#3 0xaaabf555db84 in timer_new /qemu/include/qemu/timer.h:544
#4 0xaaabf555db84 in timer_new_ns /qemu/include/qemu/timer.h:562
#5 0xaaabf555db84 in ptimer_init /qemu/hw/core/ptimer.c:433
#6 0xaaabf57415e8 in a10_pit_init /qemu/hw/timer/allwinner-a10-pit.c:278
#7 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515
#8 0xaaabf633ca04 in object_initialize_child_with_propsv /qemu/qom/object.c:564
#9 0xaaabf633cc08 in object_initialize_child_with_props /qemu/qom/object.c:547
#10 0xaaabf5b94680 in aw_a10_init /qemu/hw/arm/allwinner-a10.c:49
#11 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515
#12 0xaaabf633a1e0 in object_new_with_type /qemu/qom/object.c:729
Reported-by: Euler Robot <euler.robot@huawei.com>
Signed-off-by: Gan Qixin <ganqixin@huawei.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
When running device-introspect-test, a memory leak occurred in the
digic_timer_init function, so use ptimer_free() in the finalize function to
avoid it.
ASAN shows memory leak stack:
Indirect leak of 288 byte(s) in 3 object(s) allocated from:
#0 0xffffab97e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0)
#1 0xffffab256800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800)
#2 0xaaabf555db78 in ptimer_init /qemu/hw/core/ptimer.c:432
#3 0xaaabf5b04084 in digic_timer_init /qemu/hw/timer/digic-timer.c:142
#4 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515
#5 0xaaabf633ca04 in object_initialize_child_with_propsv /qemu/qom/object.c:564
#6 0xaaabf633cc08 in object_initialize_child_with_props /qemu/qom/object.c:547
#7 0xaaabf5b40e84 in digic_init /qemu/hw/arm/digic.c:46
#8 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515
#9 0xaaabf633a1e0 in object_new_with_type /qemu/qom/object.c:729
#10 0xaaabf6375e40 in qmp_device_list_properties /qemu/qom/qom-qmp-cmds.c:153
#11 0xaaabf653d8ec in qmp_marshal_device_list_properties /qemu/qapi/qapi-commands-qdev.c:59
#12 0xaaabf6587d08 in do_qmp_dispatch_bh /qemu/qapi/qmp-dispatch.c:110
Reported-by: Euler Robot <euler.robot@huawei.com>
Signed-off-by: Gan Qixin <ganqixin@huawei.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
This commit is the result of running the timer-del-timer-free.cocci
script on the whole source tree.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Acked-by: Corey Minyard <cminyard@mvista.com>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20201215154107.3255-4-peter.maydell@linaro.org
Support for running KVM on 32-bit Arm hosts was removed in commit
82bf7ae84c. You can still run a 32-bit guest on a 64-bit Arm
host CPU, but because Arm KVM requires the host and guest CPU types
to match, it is not possible to run a guest that requires a Cortex-A9
or Cortex-A15 CPU there. That means that the code in the
highbank/midway board models to support KVM is no longer used, and we
can delete it.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-id: 20201215144215.28482-1-peter.maydell@linaro.org
The CCR is a register most of whose bits are banked between security
states but where BFHFNMIGN is not, and we keep it in the non-secure
entry of the v7m.ccr[] array. The logic which tries to handle this
bit fails to implement the "RAZ/WI from Nonsecure if AIRCR.BFHFNMINS
is zero" requirement; correct the omission.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20201210201433.26262-2-peter.maydell@linaro.org
virt machine's 'smp_cpus' and machine->smp.cpus must always have the
same value. And, anywhere we have virt machine state we have machine
state. So let's remove the redundancy. Also, to make it easier to see
that machine->smp is the true source for "smp_cpus" and "max_cpus",
avoid passing them in function parameters, preferring instead to get
them from the state.
No functional change intended.
Signed-off-by: Andrew Jones <drjones@redhat.com>
Reviewed-by: David Edmondson <david.edmondson@oracle.com>
Reviewed-by: Ying Fang <fangying1@huawei.com>
Message-id: 20201215174815.51520-1-drjones@redhat.com
[PMM: minor formatting tweak to smp_cpus variable declaration]
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Correct the indexing into s->cpu_ctlr for vCPUs.
Signed-off-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Luc Michel <luc.michel@greensocs.com>
Message-id: 20201214222154.3480243-2-edgar.iglesias@gmail.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The sun4m board code connects both of the IRQ outputs of each ESCC to the
same slavio input qemu_irq. Connecting two qemu_irqs outputs directly to the
same input is not valid as it produces subtly wrong behaviour (for instance
if both the IRQ lines are high, and then one goes low, the PIC input will see
this as a high-to-low transition even though the second IRQ line should still
be holding it high).
This kind of wiring needs an explicitly created OR gate; add one.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Message-Id: <20201219111934.5540-1-mark.cave-ayland@ilande.co.uk>
Reviewed-by: Artyom Tarasenko <atar4qemu@gmail.com>
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Currently the GRLIB_IRQMP device is used in one place (the leon3 board),
but instead of the device providing inbound gpio lines for the board
to wire up, the board code itself calls qemu_allocate_irqs() with
the handler function being a set_irq function defined in the code
for the device.
Refactor this into the standard setup of a device having input
gpio lines.
This fixes a trivial Coverity memory leak report (the leon3
board code leaks the IRQ array returned from qemu_allocate_irqs()).
Fixes: Coverity CID 1421922
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20201212144134.29594-2-peter.maydell@linaro.org>
Reviewed-by: KONRAD Frederic <frederic.konrad@adacore.com>
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Per the "NCR89C105 Chip Specification" referenced in the header:
Chip-level Address Map
------------------------------------------------------------------
| 1D0 0000 -> | Counter/Timers | W,D |
| 1DF FFFF | | |
...
The address map indicated the allowed accesses at each address.
[...] W indicates a word access, and D indicates a double-word
access.
The SLAVIO timer controller is implemented expecting 32-bit accesses.
Commit a3d12d073e restricted the memory accesses to 32-bit, while
the device allows 64-bit accesses.
This was not an issue until commit 5d971f9e67 which reverted
("memory: accept mismatching sizes in memory_region_access_valid").
Fix by renaming .valid MemoryRegionOps as .impl, and add the valid
access range (W -> 4, D -> 8).
Since commit 21786c7e59 ("memory: Log invalid memory accesses")
this class of bug can be quickly debugged displaying 'guest_errors'
accesses, as:
$ qemu-system-sparc -M SS-20 -m 256 -bios ss20_v2.25_rom -serial stdio -d guest_errors
Power-ON Reset
Invalid access at addr 0x0, size 8, region 'timer-1', reason: invalid size (min:4 max:4)
$ qemu-system-sparc -M SS-20 -m 256 -bios ss20_v2.25_rom -monitor stdio -S
(qemu) info mtree
address-space: memory
0000000000000000-ffffffffffffffff (prio 0, i/o): system
...
0000000ff1300000-0000000ff130000f (prio 0, i/o): timer-1
^^^^^^^^^ ^^^^^^^
\ memory region base address and name /
(qemu) info qtree
bus: main-system-bus
dev: slavio_timer, id "" <-- device type name
gpio-out "sysbus-irq" 17
num_cpus = 1 (0x1)
mmio 0000000ff1310000/0000000000000014
mmio 0000000ff1300000/0000000000000010 <--- base address
mmio 0000000ff1301000/0000000000000010
mmio 0000000ff1302000/0000000000000010
...
Reported-by: Yap KV <yapkv@yahoo.com>
Buglink: https://bugs.launchpad.net/bugs/1906905
Fixes: a3d12d073e ("slavio_timer: convert to memory API")
CC: qemu-stable@nongnu.org
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20201205150903.3062711-1-f4bug@amsat.org>
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
First pull request for 2021, which has a bunch of things accumulated
over the holidays. Includes:
* A number of cleanups to sam460ex and ppc440 code from BALATON Zoltan
* Several fixes for builds with --without-default-devices from Greg Kurz
* Fixes for some DRC reset problems from Greg Kurz
* QOM conversion of the PPC 4xx UIC devices from Peter Maydell
* Some other assorted fixes and cleanups
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEdfRlhq5hpmzETofcbDjKyiDZs5IFAl/1L38ACgkQbDjKyiDZ
s5JmvQ//RddzvCrHewdtRys+XnLDsKbWng3rQGKh2rSpKMYM11ilmo7FOGoOMNwq
aiZXm5z3t2lpSUTGZorVuPAnYKExzkuAQkPsFZ65uf9wfDhB2wg3BIr97GgZBF2S
MvK9DlxhUNJI+1W8Y+hwj9xDMOX3oFqZp24g2i6EQPRcpqE7GtRpOzt6PdL15sNz
KiJtIeyZ32uGDQaqNlWHJ/pBiYECEQTVpaZIztg2WLdfMICzgYMSCSZzbUrYXCii
WPDJ9sr69sMFwX2oEAgmfmJeFaTOFMt/xTOwFvi2ex4Rd1Rzqb9XToZ+ihOeOAFr
c4a7fpZzx0ePYLIAfOAZ2exV8Nh04dWjRyr2ykgo1ik3DaJ1Ck80O7jYyPQN1Dir
wKpWW59a3pjdABa/ZAoMoFwJh1zPAwGuiN4Higy87Ux8X+JOlTzzkP9ja9v2fgRC
DNb8VYvehUbY6bbHkqs57JcVyYLX56yphfq6Pr2D3DE6y1Ekph2G2vR8YXnqbRmY
Pw5VJ9q1SdYypGVZdMmIXseM7XerFA9YlIfIAQ7DiEW5wH9sx5QjDxlSt07l56J0
TlK6m9Fgc3koLLtVqDlK0NPx39xqVa1JUkrvPeWNKqn1FG/0tfPU6oPVjdQx3ouk
X2cv4A99MJsWSoyUMCH5r5+CHdMCscILOSOZ6OiWAHMEdqCxH0Q=
=7Eiy
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/dg-gitlab/tags/ppc-for-6.0-20210106' into staging
ppc patch queue 2021-01-06
First pull request for 2021, which has a bunch of things accumulated
over the holidays. Includes:
* A number of cleanups to sam460ex and ppc440 code from BALATON Zoltan
* Several fixes for builds with --without-default-devices from Greg Kurz
* Fixes for some DRC reset problems from Greg Kurz
* QOM conversion of the PPC 4xx UIC devices from Peter Maydell
* Some other assorted fixes and cleanups
# gpg: Signature made Wed 06 Jan 2021 03:33:19 GMT
# gpg: using RSA key 75F46586AE61A66CC44E87DC6C38CACA20D9B392
# gpg: Good signature from "David Gibson <david@gibson.dropbear.id.au>" [full]
# gpg: aka "David Gibson (Red Hat) <dgibson@redhat.com>" [full]
# gpg: aka "David Gibson (ozlabs.org) <dgibson@ozlabs.org>" [full]
# gpg: aka "David Gibson (kernel.org) <dwg@kernel.org>" [unknown]
# Primary key fingerprint: 75F4 6586 AE61 A66C C44E 87DC 6C38 CACA 20D9 B392
* remotes/dg-gitlab/tags/ppc-for-6.0-20210106: (22 commits)
ppc440_pcix: Fix up pci config access
ppc440_pcix: Fix register write trace event
ppc440_pcix: Improve comment for IRQ mapping
sam460ex: Remove FDT_PPC dependency from KConfig
ppc4xx: Move common dependency on serial to common option
pnv: Fix reverse dependency on PCI express root ports
ppc: Simplify reverse dependencies of POWERNV and PSERIES on XICS and XIVE
ppc: Fix build with --without-default-devices
spapr: Add drc_ prefix to the DRC realize and unrealize functions
spapr: Use spapr_drc_reset_all() at machine reset
spapr: Introduce spapr_drc_reset_all()
spapr: Fix reset of transient DR connectors
spapr: Call spapr_drc_reset() for all DRCs at CAS
spapr: Fix buffer overflow in spapr_numa_associativity_init()
spapr: Allow memory unplug to always succeed
spapr: Fix DR properties of the root node
spapr/xive: Make spapr_xive_pic_print_info() static
spapr: DRC lookup cannot fail
hw/ppc/ppc440_bamboo: Drop use of ppcuic_init()
hw/ppc/virtex_ml507: Drop use of ppcuic_init()
...
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
This fixes a long standing issue with MorphOS booting on sam460ex
which turns out to be because of suspicious values written to PCI
config address that apparently works on real machine but caused wrong
access on this device model. This replaces a previous work around for
this with a better fix that makes it work.
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
Message-Id: <6fd215ab2bc5f8d4455cd20ed1a2f059e4415fe5.1609636173.git.balaton@eik.bme.hu>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The trace event for pci_host_config_write() was also using the trace
event for read. Add corresponding trace and correct this.
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
Message-Id: <a6c7dcf7153cc537123ed8ceac060f2f64a883cb.1609636173.git.balaton@eik.bme.hu>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The code mapping all PCI interrupts to a single CPU IRQ works but is
not trivial so document it in a comment.
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
Message-Id: <c25c0310510672b58466e795fd701e65e8f1ff97.1609636173.git.balaton@eik.bme.hu>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Dependency on FDT_PPC was added in commit b0048f7609
("hw/ppc/Kconfig: Only select FDT helper for machines using it") but
it does not seem to be really necessary so remove it again.
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <7461a20b129a912aeacdb9ad115a55f0b84c8726.1609636173.git.balaton@eik.bme.hu>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
All machines that select SERIAL also select PPC4XX so we can just add
this common dependency there once.
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
Message-Id: <94f1eb7cfb7f315bd883d825f3ce7e0cfc2f2b69.1609636173.git.balaton@eik.bme.hu>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
qemu-system-ppc64 built with --without-default-devices crashes:
Type 'pnv-phb4-root-port' is missing its parent 'pcie-root-port-base'
Aborted (core dumped)
Have POWERNV to select PCIE_PORT. This is done through a
new PCI_POWERNV config in hw/pci-host/Kconfig since POWERNV
doesn't have a direct dependency on PCI. For this reason,
PCI_EXPRESS and MSI_NONBROKEN are also moved under
PCI_POWERNV.
Signed-off-by: Greg Kurz <groug@kaod.org>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <160883058299.253005.342913177952681375.stgit@bahia.lan>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Have PSERIES to select XICS and XIVE, and directly check PSERIES
in hw/intc/meson.build to enable build of the XICS and XIVE sPAPR
backends, like POWERNV already does. This allows to get rid of the
intermediate XICS_SPAPR and XIVE_SPAPR.
Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <160883057560.253005.4206568349917633920.stgit@bahia.lan>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Linking of the qemu-system-ppc64 fails on a POWER9 host when
--without-default-devices is passed to configure:
$ ./configure --without-default-devices \
--target-list=ppc64-softmmu && make
...
libqemu-ppc64-softmmu.fa.p/hw_ppc_e500.c.o: In function `ppce500_init_mpic_kvm':
/home/greg/Work/qemu/qemu-ppc/build/../hw/ppc/e500.c:777: undefined reference to `kvm_openpic_connect_vcpu'
libqemu-ppc64-softmmu.fa.p/hw_ppc_spapr_irq.c.o: In function `spapr_irq_check':
/home/greg/Work/qemu/qemu-ppc/build/../hw/ppc/spapr_irq.c:189: undefined reference to `xics_kvm_has_broken_disconnect'
libqemu-ppc64-softmmu.fa.p/hw_intc_spapr_xive.c.o: In function `spapr_xive_post_load':
/home/greg/Work/qemu/qemu-ppc/build/../hw/intc/spapr_xive.c:530: undefined reference to `kvmppc_xive_post_load'
... and tons of other symbols belonging to the KVM backend of the
openpic, XICS and XIVE interrupt controllers.
It turns out that OPENPIC_KVM, XICS_KVM and XIVE_KVM are marked
to depend on KVM but this has no effect when minikconf runs in
allnoconfig mode. Such reverse dependencies should rather be
handled with a 'select' statement, eg.
config OPENPIC
select OPENPIC_KVM if KVM
or even better by getting rid of the intermediate _KVM config
and directly checking CONFIG_KVM in the meson.build file:
specific_ss.add(when: ['CONFIG_KVM', 'CONFIG_OPENPIC'],
if_true: files('openpic_kvm.c'))
Go for the latter with OPENPIC, XICS and XIVE.
This went unnoticed so far because CI doesn't test the build with
--without-default-devices and KVM enabled on a POWER host.
Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <160883056791.253005.14924294027763955653.stgit@bahia.lan>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Use a less generic name for an easier experience with tools such as
cscope or grep.
Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <20201218103400.689660-6-groug@kaod.org>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Tested-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Documentation of object_child_foreach_recursive() clearly stipulates
that "it is forbidden to add or remove children from @obj from the @fn
callback". But this is exactly what we do during machine reset. The call
to spapr_drc_reset() can finalize the hot-unplug sequence of a PHB or a
PCI bridge, both of which will then in turn destroy their PCI DRCs. This
could potentially invalidate the iterator used by do_object_child_foreach().
It is pure luck that this haven't caused any issues so far.
Use spapr_drc_reset_all() since it can cope with DRC removal.
Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <20201218103400.689660-5-groug@kaod.org>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Tested-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
No need to expose the way DRCs are traversed outside of spapr_drc.c.
Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <20201218103400.689660-4-groug@kaod.org>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Tested-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Documentation of object_property_iter_init() clearly stipulates that
"it is forbidden to modify the property list while iterating". But this
is exactly what we do when resetting transient DR connectors during CAS.
The call to spapr_drc_reset() can finalize the hot-unplug sequence of a
PHB or a PCI bridge, both of which will then in turn destroy their PCI
DRCs. This could potentially invalidate the iterator. It is pure luck
that this haven't caused any issues so far.
Change spapr_drc_reset() to return true if it caused a device to be
removed. Restart from scratch in this case. This can potentially
increase the overall DRC reset time, especially with a high maxmem
which generates a lot of LMB DRCs. But this kind of setup is rare,
and so is the use case of rebooting a guest while doing hot-unplug.
Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <20201218103400.689660-3-groug@kaod.org>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Tested-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Non-transient DRCs are either in the empty or the ready state,
which means spapr_drc_reset() doesn't change their state. It
is thus not needed to do any checking. Call spapr_drc_reset()
unconditionally and squash spapr_drc_transient() into its
only user, spapr_drc_needed().
Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <20201218103400.689660-2-groug@kaod.org>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Tested-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
It is currently impossible to hot-unplug a memory device between
machine reset and CAS.
(qemu) device_del dimm1
Error: Memory hot unplug not supported for this guest
This limitation was introduced in order to provide an explicit
error path for older guests that didn't support hot-plug event
sources (and thus memory hot-unplug).
The linux kernel has been supporting these since 4.11. All recent
enough guests are thus capable of handling the removal of a memory
device at all time, including during early boot.
Lift the limitation for the latest machine type. This means that
trying to unplug memory from a guest that doesn't support it will
likely just do nothing and the memory will only get removed at
next reboot. Such older guests can still get the existing behavior
by using an older machine type.
Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <160794035064.23292.17560963281911312439.stgit@bahia.lan>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Section 13.5.2 of LoPAPR mandates various DR related indentifiers
for all hot-pluggable entities to be exposed in the "ibm,drc-indexes",
"ibm,drc-power-domains", "ibm,drc-names" and "ibm,drc-types" properties
of their parent node. These properties are created with spapr_dt_drc().
PHBs and LMBs are both children of the machine. Their DR identifiers
are thus supposed to be exposed in the afore mentioned properties of
the root node.
When PHB hot-plug support was added, an extra call to spapr_dt_drc()
was introduced: this overwrites the existing properties, previously
populated with the LMB identifiers, and they end up containing only
PHB identifiers. This went unseen so far because linux doesn't care,
but this is still not conformant with LoPAPR.
Fortunately spapr_dt_drc() is able to handle multiple DR entity types
at the same time. Use that to handle DR indentifiers for PHBs and LMBs
with a single call to spapr_dt_drc(). While here also account for PMEM
DR identifiers, which were forgotten when NVDIMM hot-plug support was
added. Also add an assert to prevent further misuse of spapr_dt_drc().
With -m 1G,maxmem=2G,slots=8 passed on the QEMU command line we get:
Without this patch:
/proc/device-tree/ibm,drc-indexes
0000001f 20000001 20000002 20000003
20000000 20000005 20000006 20000007
20000004 20000009 20000008 20000010
20000011 20000012 20000013 20000014
20000015 20000016 20000017 20000018
20000019 2000000a 2000000b 2000000c
2000000d 2000000e 2000000f 2000001a
2000001b 2000001c 2000001d 2000001e
These are the DRC indexes for the 31 possible PHBs.
With this patch:
/proc/device-tree/ibm,drc-indexes
0000002b 90000000 90000001 90000002
90000003 90000004 90000005 90000006
90000007 20000001 20000002 20000003
20000000 20000005 20000006 20000007
20000004 20000009 20000008 20000010
20000011 20000012 20000013 20000014
20000015 20000016 20000017 20000018
20000019 2000000a 2000000b 2000000c
2000000d 2000000e 2000000f 2000001a
2000001b 2000001c 2000001d 2000001e
80000004 80000005 80000006 80000007
And now we also have the 4 ((2G - 1G) / 256M) LMBs and the
8 (slots) PMEMs.
Fixes: 3998ccd092 ("spapr: populate PHB DRC entries for root DT node")
Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <160794479566.35245.17809158217760761558.stgit@bahia.lan>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
All memory DRC objects are created during machine init. It is thus safe
to assume spapr_drc_by_id() cannot return NULL when hot-plug/unplugging
memory.
Make this clear with an assertion, like the code already does a few lines
above when looping over memory DRCs. This fixes Coverity reports 1437757
and 1437758.
Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <160805381160.228955.5388294067094240175.stgit@bahia.lan>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Switch the bamboo board to directly creating and configuring the UIC,
rather than doing it via the old ppcuic_init() helper function.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20201212001537.24520-5-peter.maydell@linaro.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Switch the virtex_ml507 board to directly creating and
configuring the UIC, rather than doing it via the old
ppcuic_init() helper function.
This fixes a trivial Coverity-detected memory leak where
we were leaking the array of IRQs returned by ppcuic_init().
Fixes: Coverity CID 1421992
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20201212001537.24520-4-peter.maydell@linaro.org>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
Tested-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Currently the PPC UIC ("Universal Interrupt Controller") is implemented
as a non-QOM device in ppc4xx_devs.c. Convert it to a proper QOM device
in hw/intc.
The ppcuic_init() function is retained for the moment with its current
interface; in subsequent commits this will be tidied up to avoid the
allocation of an irq array.
This conversion adds VMState support.
It leaves the LOG_UIC() macro as-is to maximise the extent to which
this is simply code-movement rather than a rewrite (in new code it
would be better to use tracepoints).
The default property values for dcr-base and use-vectors are set to
match those use by most of our boards with a UIC.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20201212001537.24520-3-peter.maydell@linaro.org>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
Tested-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
In a following commit we will move the PPC UIC implementation to
its own file in hw/intc. To prevent checkpatch complaining about that
code-motion, fix up the minor style issues first.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20201212001537.24520-2-peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
Tested-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Missed in 3ca7639ff0 ("hw/mips/fuloong2e: Set CPU frequency
to 533 MHz"), we need to tell the kernel the correct clock.
Fixes: 3ca7639ff0 ("hw/mips/fuloong2e: Set CPU frequency to 533 MHz").
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Reviewed-by: Huacai Chen <chenhuacai@kernel.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20201224031750.52146-7-jiaxun.yang@flygoat.com>
[PMD: Reworded]
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
modetty is not handled by kernel and the parameter
here seems unreasonable.
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Message-Id: <20201224031750.52146-6-jiaxun.yang@flygoat.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
[PMD: Do not remove busclock]
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Websites are downing, but GitHub may last forever.
Loongson even doesn't recogonize 2E as their products nowadays..
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Huacai Chen <chenhuacai@kernel.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20201224031750.52146-3-jiaxun.yang@flygoat.com>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Seems useless....
Fixes: 051c190bce ("MIPS: Initial support of fulong mini pc (machine construction)")
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Huacai Chen <chenhuacai@kernel.org>
Message-Id: <20201224031750.52146-2-jiaxun.yang@flygoat.com>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
It will signed extend vaddr properly.
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20201215064200.28751-4-jiaxun.yang@flygoat.com>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
So it will sign extend adresses properly.
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20201215064200.28751-3-jiaxun.yang@flygoat.com>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Address should be unsigned anyway, otherwise it may carry
calculations wrongly.
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20201215064200.28751-2-jiaxun.yang@flygoat.com>
[PMD: Fixed typo and convert hw/mips/mipssim.c too]
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Add Loongson-3 based machine support, it use liointc as the interrupt
controler and use GPEX as the pci controller. Currently it can work with
both TCG and KVM.
As the machine model is not based on any exiting physical hardware, the
name of the machine is "loongson3-virt". It may be superseded in future
by a real machine model. If this happens, then a regular deprecation
procedure shall occur for "loongson3-virt" machine.
We now already have a full functional Linux kernel (based on Linux-5.4.x
LTS) here:
https://github.com/chenhuacai/linux
Of course the upstream kernel is also usable (the kvm host side and
guest side have both been upstream in Linux-5.9):
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
How to use QEMU/Loongson-3?
1, Download kernel source from the above URL;
2, Build a kernel with arch/mips/configs/loongson3_defconfig;
3, Boot a Loongson-3A4000 host with this kernel (for KVM mode);
4, Build QEMU-master with this patchset;
5, modprobe kvm (only necessary for KVM mode);
6, Use QEMU with TCG:
qemu-system-mips64el -M loongson3-virt,accel=tcg -cpu Loongson-3A1000 -kernel <path_to_kernel> -append ...
Use QEMU with KVM:
qemu-system-mips64el -M loongson3-virt,accel=kvm -cpu Loongson-3A4000 -kernel <path_to_kernel> -append ...
The "-cpu" parameter is optional here and QEMU will use the correct type for TCG/KVM automatically.
Co-developed-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Signed-off-by: Huacai Chen <chenhuacai@kernel.org>
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Message-Id: <20201221110538.3186646-5-chenhuacai@kernel.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
[PMD: Set TYPE_LOONGSON_MACHINE instance_size in TypeInfo,
select FW_CFG_MIPS in Kconfig]
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Implement fw_cfg_arch_key_name(), which returns the name of a
mips-specific key.
Co-developed-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Signed-off-by: Huacai Chen <chenhuacai@kernel.org>
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <1600742967-12933-7-git-send-email-chenhc@lemote.com>
[PMD: Add FW_CFG_MIPS Kconfig selector]
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
As suggested by Philippe Mathieu-Daudé, rework Loongson's liointc:
1, Move macro definitions to loongson_liointc.h;
2, Remove magic values and use macros instead;
3, Replace dead D() code by trace events.
Suggested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Huacai Chen <chenhuacai@kernel.org>
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20201221110538.3186646-2-chenhuacai@kernel.org>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
It's common to want to print a human-readable indication of a clock's
frequency. Provide a utility function in the clock API to return a
string which is a displayable representation of the frequency,
and use it in qdev-monitor.c.
Before:
(qemu) info qtree
[...]
dev: xilinx,zynq_slcr, id ""
clock-in "ps_clk" freq_hz=3.333333e+07
mmio 00000000f8000000/0000000000001000
After:
dev: xilinx,zynq_slcr, id ""
clock-in "ps_clk" freq_hz=33.3 MHz
mmio 00000000f8000000/0000000000001000
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Luc Michel <luc@lmichel.fr>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20201215150929.30311-5-peter.maydell@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Use less confusing naming for superio config register handling related
parts that makes it clearer what belongs to this part.
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <4d30a2b4b771b2ad651509885daae79d7c4fe7a8.1609584216.git.balaton@eik.bme.hu>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Rename local variable holding object state for readability and
consistency.
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <69655b23df2ecebbf0aff29726f4b4746f5b74de.1609584216.git.balaton@eik.bme.hu>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
These are not used or not needed.
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <35cefcc3518a3395a796bb6ad6fbc308adc65266.1609584216.git.balaton@eik.bme.hu>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Drop DPRINTF and use trace functions instead. Two debug messages about
unimplemented registers could be converted to qemu_log_mask() but in
reality all registers are currently unimplemented (we just store and
return values of writable regs but do nothing with them). As we
already trace register access there's no need for additional debug
messages so these are just removed and a comment is added as a reminder.
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <785854022a37035f66d89e70cb6ca1bc0e0d0163.1609584216.git.balaton@eik.bme.hu>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Remove legacy vt82c686b_pm_init() function and also rename
VT82C686B_PM type name to match other device names.
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <a70982b32f11222d335385b90749abb6cf2e2cce.1609584216.git.balaton@eik.bme.hu>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Remove some unneded, empty code and set user_creatable to false
(besides being not implemented yet, so does nothing anyway) it's also
normally part of VIA south bridge chips so no need to confuse users
showing them these devices.
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <c7a5b1ee4c02e304ff70ebfbf269544f3c1f8412.1609584216.git.balaton@eik.bme.hu>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
The via-[am]c97 code is supposed to implement the audio part of VIA
south bridge chips so it is better placed under hw/audio/. Split it
off into a separate file.
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <af083634e3b9efe67e6c4247cf0185d3fa7b1810.1609584216.git.balaton@eik.bme.hu>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
These are legacy init functions that are just equivalent to directly
calling pci_create_simple so do that instead. Also rename objects to
lower case via-ac97 and via-mc97 matching naming of other devices.
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <1c4373c8aeb6c4fb2a8df2c864b0e91a977a3d7b.1609584216.git.balaton@eik.bme.hu>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
This is really the ISA bridge part so name the type accordingly.
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <78db2ced4b41a8a775dbc6c97a90db683952c2cb.1609584216.git.balaton@eik.bme.hu>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Gerd Hoffmann