- Jul 02, 2021
-
-
Philippe Mathieu-Daudé authored
When using the Magnum ARC firmware we can see accesses to the UART1 being rejected, because the device is not mapped: $ qemu-system-mips64el -M magnum -d guest_errors,unimp -bios NTPROM.RAW Invalid access at addr 0x80007004, size 1, region '(null)', reason: rejected Invalid access at addr 0x80007001, size 1, region '(null)', reason: rejected Invalid access at addr 0x80007002, size 1, region '(null)', reason: rejected Invalid access at addr 0x80007003, size 1, region '(null)', reason: rejected Invalid access at addr 0x80007004, size 1, region '(null)', reason: rejected Since both UARTs are present (soldered on the board) regardless of whether there are character devices connected, map them unconditionally. (This code pre-dated commit 12051d82 which made it safe to pass NULL in as a chardev to serial devices.) Signed-off-by:
Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by:
Peter Maydell <peter.maydell@linaro.org> Message-Id: <20210629053704.2584504-1-f4bug@amsat.org>
-
Mark Cave-Ayland authored
The MIPS magnum machines are available in both big endian (mips64) and little endian (mips64el) configurations. Ensure that the dp893x big_endian property is set accordingly using logic similar to that used for the MIPS malta machines. Signed-off-by:
Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Tested-by:
Finn Thain <fthain@linux-m68k.org> Reviewed-by:
Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210625065401.30170-11-mark.cave-ayland@ilande.co.uk> Signed-off-by:
Philippe Mathieu-Daudé <f4bug@amsat.org>
-
Mark Cave-Ayland authored
The checksum used by MacOS to validate the PROM content is an exclusive-OR rather than a sum over the corresponding bytes. In addition the MAC address must be stored in bit-reversed format as indicated in comments in Linux's macsonic.c. With the PROM contents fixed MacOS starts to probe the device registers when AppleTalk is enabled in the Control Panel. Signed-off-by:
Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Tested-by:
Finn Thain <fthain@linux-m68k.org> Message-Id: <20210625065401.30170-8-mark.cave-ayland@ilande.co.uk> Signed-off-by:
Philippe Mathieu-Daudé <f4bug@amsat.org>
-
Mark Cave-Ayland authored
According to the datasheet the dp8393x chipset does not contain any NVRAM capable of storing a MAC address or checksum. Now that both the MIPS jazz and m68k q800 boards generate the PROM region and checksum themselves, remove the generated PROM from the dp8393x device itself. Signed-off-by:
Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Tested-by:
Finn Thain <fthain@linux-m68k.org> Reviewed-by:
Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210625065401.30170-6-mark.cave-ayland@ilande.co.uk> Signed-off-by:
Philippe Mathieu-Daudé <f4bug@amsat.org>
-
Mark Cave-Ayland authored
This is in preparation for each board to have its own separate bit storage format and checksum for storing the MAC address. Signed-off-by:
Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Tested-by:
Finn Thain <fthain@linux-m68k.org> Reviewed-by:
Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210625065401.30170-5-mark.cave-ayland@ilande.co.uk> Signed-off-by:
Philippe Mathieu-Daudé <f4bug@amsat.org>
-
Mark Cave-Ayland authored
This is in preparation for each board to have its own separate bit storage format and checksum for storing the MAC address. Signed-off-by:
Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Tested-by:
Finn Thain <fthain@linux-m68k.org> Reviewed-by:
Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210625065401.30170-4-mark.cave-ayland@ilande.co.uk> Signed-off-by:
Philippe Mathieu-Daudé <f4bug@amsat.org>
-
Mark Cave-Ayland authored
Signed-off-by:
Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by:
Philippe Mathieu-Daudé <f4bug@amsat.org> Tested-by:
Finn Thain <fthain@linux-m68k.org> Message-Id: <20210625065401.30170-3-mark.cave-ayland@ilande.co.uk> Signed-off-by:
Philippe Mathieu-Daudé <f4bug@amsat.org>
-
Mark Cave-Ayland authored
Also fix a simple comment typo of "constrainst" to "constraints". Signed-off-by:
Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by:
Philippe Mathieu-Daudé <f4bug@amsat.org> Tested-by:
Finn Thain <fthain@linux-m68k.org> Message-Id: <20210625065401.30170-2-mark.cave-ayland@ilande.co.uk> Signed-off-by:
Philippe Mathieu-Daudé <f4bug@amsat.org>
-
Mark Cave-Ayland authored
Currently when QEMU attempts to migrate the MIPS magnum machine it crashes due to a mistake in the g364fb VMStateDescription configuration which expects a G364SysBusState and not a G364State. Resolve the issue by adding a new VMStateDescription for G364SysBusState and embedding the existing vmstate_g364fb VMStateDescription inside it using VMSTATE_STRUCT. Signed-off-by:
Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Fixes: 97a3f6ff ("g364fb: convert to qdev") Reviewed-by:
Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210625163554.14879-3-mark.cave-ayland@ilande.co.uk> Signed-off-by:
Philippe Mathieu-Daudé <f4bug@amsat.org>
-
Mark Cave-Ayland authored
Since the migration stream is already broken, we can use this opportunity to change the framebuffer so that it is migrated as a RAM memory region rather than as an array of bytes. In particular this helps the output of the analyze-migration.py tool which no longer contains a huge array representing the framebuffer contents. Signed-off-by:
Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by:
Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210625163554.14879-2-mark.cave-ayland@ilande.co.uk> Signed-off-by:
Philippe Mathieu-Daudé <f4bug@amsat.org>
-
Philippe Mathieu-Daudé authored
When running the official PMON firmware for the Fuloong 2E, we see 8-bit and 16-bit accesses to PCI config space: $ qemu-system-mips64el -M fuloong2e -bios pmon_2e.bin \ -trace -trace bonito\* -trace pci_cfg\* pci_cfg_write vt82c686b-pm 05:4 @0x90 <- 0xeee1 bonito_spciconf_small_access PCI config address is smaller then 32-bit, addr: 0x4d2, size: 2 pci_cfg_write vt82c686b-pm 05:4 @0xd2 <- 0x1 pci_cfg_write vt82c686b-pm 05:4 @0x4 <- 0x1 pci_cfg_write vt82c686b-isa 05:0 @0x4 <- 0x7 bonito_spciconf_small_access PCI config address is smaller then 32-bit, addr: 0x81, size: 1 pci_cfg_read vt82c686b-isa 05:0 @0x81 -> 0x0 bonito_spciconf_small_access PCI config address is smaller then 32-bit, addr: 0x81, size: 1 pci_cfg_write vt82c686b-isa 05:0 @0x81 <- 0x80 bonito_spciconf_small_access PCI config address is smaller then 32-bit, addr: 0x83, size: 1 pci_cfg_write vt82c686b-isa 05:0 @0x83 <- 0x89 bonito_spciconf_small_access PCI config address is smaller then 32-bit, addr: 0x85, size: 1 pci_cfg_write vt82c686b-isa 05:0 @0x85 <- 0x3 bonito_spciconf_small_access PCI config address is smaller then 32-bit, addr: 0x5a, size: 1 pci_cfg_write vt82c686b-isa 05:0 @0x5a <- 0x7 bonito_spciconf_small_access PCI config address is smaller then 32-bit, addr: 0x85, size: 1 pci_cfg_write vt82c686b-isa 05:0 @0x85 <- 0x1 Also this is what the Linux kernel does since it supports the Bonito north bridge: https://elixir.bootlin.com/linux/v2.6.15/source/arch/mips/pci/ops-bonito64.c#L85 So it seems safe to assume the datasheet is incomplete or outdated regarding the address constraints. This problem was exposed by commit 911629e6 ("vt82c686: Fix SMBus IO base and configuration registers"). Reported-by:
BALATON Zoltan <balaton@eik.bme.hu> Suggested-by:
Jiaxun Yang <jiaxun.yang@flygoat.com> Signed-off-by:
Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210624202747.1433023-4-f4bug@amsat.org> Tested-by:
BALATON Zoltan <balaton@eik.bme.hu>
-
Maxim Uvarov authored
qemu has 2 type of functions: shutdown and reboot. Shutdown function has to be used for machine shutdown. Otherwise we cause a reset with a bogus "cause" value, when we intended a shutdown. Signed-off-by:
Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by:
Peter Maydell <peter.maydell@linaro.org> Message-id: 20210625111842.3790-3-maxim.uvarov@linaro.org [PMM: tweaked commit message] Signed-off-by:
Peter Maydell <peter.maydell@linaro.org>
-
Nolan Leake authored
This is just enough to make reboot and poweroff work. Works for linux, u-boot, and the arm trusted firmware. Not tested, but should work for plan9, and bare-metal/hobby OSes, since they seem to generally do what linux does for reset. The watchdog timer functionality is not yet implemented. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/64 Signed-off-by:
Nolan Leake <nolan@sigbus.net> Reviewed-by:
Philippe Mathieu-Daudé <f4bug@amsat.org> Tested-by:
Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20210625210209.1870217-1-nolan@sigbus.net [PMM: tweaked commit title; fixed region size to 0x200; moved header file to include/] Signed-off-by:
Peter Maydell <peter.maydell@linaro.org>
-
Philippe Mathieu-Daudé authored
Per the datasheet section "5.7.5. Accessing PCI configuration space" the address must be 32-bit aligned. Trace eventual accesses not aligned to 32-bit. Signed-off-by:
Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210624202747.1433023-3-f4bug@amsat.org>
-
- Jun 30, 2021
-
-
Kevin Wolf authored
Commit dabefdd6 removed code that was supposed to try reconnecting during .realize(), but actually just crashed and had several design problems. This adds the feature back without the crash in simple cases while also fixing some design problems: Reconnection is now only tried if there was a problem with the connection and not an error related to the content (which would fail again the same way in the next attempt). Reconnection is limited to three attempts (four with the initial attempt) so that we won't end up in an infinite loop if a problem is permanent. If the backend restarts three times in the very short time window of device initialisation, we have bigger problems and erroring out is the right course of action. In the case that a connection error occurs and we reconnect, the error message is printed using error_report_err(), but otherwise ignored. Signed-off-by:
Kevin Wolf <kwolf@redhat.com> Message-Id: <20210609154658.350308-8-kwolf@redhat.com> Reviewed-by:
Raphael Norwitz <raphael.norwitz@nutanix.com> Signed-off-by:
Kevin Wolf <kwolf@redhat.com>
-
Kevin Wolf authored
This function is the part that we will want to retry if the connection is lost during initialisation, so factor it out to keep the following patch simpler. The error path for vhost_dev_get_config() forgot disconnecting the chardev, add this while touching the code. Signed-off-by:
Kevin Wolf <kwolf@redhat.com> Message-Id: <20210609154658.350308-7-kwolf@redhat.com> Reviewed-by:
Stefano Garzarella <sgarzare@redhat.com> Reviewed-by:
Raphael Norwitz <raphael.norwitz@nutanix.com> Signed-off-by:
Kevin Wolf <kwolf@redhat.com>
-
Kevin Wolf authored
Instead of just returning 0/-1 and letting the caller make up a meaningless error message, add an Error parameter to allow reporting the real error and switch to 0/-errno so that different kind of errors can be distinguished in the caller. config_len in vhost_user_get_config() is defined by the device, so if it's larger than VHOST_USER_MAX_CONFIG_SIZE, this is a programming error. Turn the corresponding check into an assertion. Signed-off-by:
Kevin Wolf <kwolf@redhat.com> Message-Id: <20210609154658.350308-6-kwolf@redhat.com> Reviewed-by:
Stefano Garzarella <sgarzare@redhat.com> Reviewed-by:
Raphael Norwitz <raphael.norwitz@nutanix.com> Signed-off-by:
Kevin Wolf <kwolf@redhat.com>
-
Kevin Wolf authored
Instead of letting the caller make up a meaningless error message, add an Error parameter to allow reporting the real error. Signed-off-by:
Kevin Wolf <kwolf@redhat.com> Message-Id: <20210609154658.350308-5-kwolf@redhat.com> Reviewed-by:
Stefano Garzarella <sgarzare@redhat.com> Reviewed-by:
Raphael Norwitz <raphael.norwitz@nutanix.com> Signed-off-by:
Kevin Wolf <kwolf@redhat.com>
-
Kevin Wolf authored
Instead of just returning 0/-1 and letting the caller make up a meaningless error message, switch to 0/-errno so that different kinds of errors can be distinguished in the caller. This involves changing a few more callbacks in VhostOps to return 0/-errno: .vhost_set_owner(), .vhost_get_features() and .vhost_virtqueue_set_busyloop_timeout(). The implementations of these functions are trivial as they generally just send a message to the backend. Signed-off-by:
Kevin Wolf <kwolf@redhat.com> Message-Id: <20210609154658.350308-4-kwolf@redhat.com> Reviewed-by:
Stefano Garzarella <sgarzare@redhat.com> Reviewed-by:
Raphael Norwitz <raphael.norwitz@nutanix.com> Signed-off-by:
Kevin Wolf <kwolf@redhat.com>
-
Kevin Wolf authored
Instead of just returning 0/-1 and letting the caller make up a meaningless error message, add an Error parameter to allow reporting the real error and switch to 0/-errno so that different kind of errors can be distinguished in the caller. Specifically, in vhost-user, EPROTO is used for all errors that relate to the connection itself, whereas other error codes are used for errors relating to the content of the connection. This will allow us later to automatically reconnect when the connection goes away, without ending up in an endless loop if it's a permanent error in the configuration. Signed-off-by:
Kevin Wolf <kwolf@redhat.com> Message-Id: <20210609154658.350308-3-kwolf@redhat.com> Reviewed-by:
Stefano Garzarella <sgarzare@redhat.com> Reviewed-by:
Raphael Norwitz <raphael.norwitz@nutanix.com> Signed-off-by:
Kevin Wolf <kwolf@redhat.com>
-
Kevin Wolf authored
This allows callers to return better error messages instead of making one up while the real error ends up on stderr. Most callers can immediately make use of this because they already have an Error parameter themselves. The others just keep printing the error with error_report_err(). Signed-off-by:
Kevin Wolf <kwolf@redhat.com> Message-Id: <20210609154658.350308-2-kwolf@redhat.com> Reviewed-by:
Stefano Garzarella <sgarzare@redhat.com> Reviewed-by:
Raphael Norwitz <raphael.norwitz@nutanix.com> Signed-off-by:
Kevin Wolf <kwolf@redhat.com>
-
- Jun 29, 2021
-
-
Klaus Jensen authored
Jakub noticed[1] that, when using pin-based interrupts, the device will unconditionally deasssert when any CQEs are acknowledged. However, the pin should not be deasserted if other completion queues still holds unacknowledged CQEs. The bug is an artifact of commit ca247d35 ("hw/block/nvme: fix pin-based interrupt behavior") which fixed one bug but introduced another. This is the third time someone tries to fix pin-based interrupts (see commit 5e9aa92e ("hw/block: Fix pin-based interrupt behaviour of NVMe"))... Third time's the charm, so fix it, again, by keeping track of how many CQs have unacknowledged CQEs and only deassert when all are cleared. [1]: <20210610114624.304681-1-jakub.jermar@kernkonzept.com> Cc: qemu-stable@nongnu.org Fixes: ca247d35 ("hw/block/nvme: fix pin-based interrupt behavior") Reported-by:
Jakub Jermář <jakub.jermar@kernkonzept.com> Signed-off-by:
Klaus Jensen <k.jensen@samsung.com> Reviewed-by:
Keith Busch <kbusch@kernel.org>
-
Klaus Jensen authored
Qiang Liu reported that an access on an unknown address is triggered in memory_region_set_enabled because a check on CAP.PMRS is missing for the PMRCTL register write when no PMR is configured. Cc: qemu-stable@nongnu.org Fixes: 75c3c9de ("hw/block/nvme: disable PMR at boot up") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/362 Signed-off-by:
Klaus Jensen <k.jensen@samsung.com> Reviewed-by:
Keith Busch <kbusch@kernel.org>
-
Gollu Appalanaidu authored
In the documentation of the '-detached' param "be" and "not" has been used side by side, fix that. Signed-off-by:
Gollu Appalanaidu <anaidu.gollu@samsung.com> Reviewed-by:
Klaus Jensen <k.jensen@samsung.com> Signed-off-by:
Klaus Jensen <k.jensen@samsung.com>
-
Gollu Appalanaidu authored
Add the controller identifiers list CNS 0x13, available list of ctrls in NVM Subsystem that may or may not be attached to namespaces. In Identify Ctrl List of the CNS 0x12 and 0x13 no endian conversion for the nsid field. These two CNS values shows affect when there exists a Subsystem. Added condition if there is no Subsystem return invalid field in command. Signed-off-by:
Gollu Appalanaidu <anaidu.gollu@samsung.com> Reviewed-by:
Klaus Jensen <k.jensen@samsung.com> Signed-off-by:
Klaus Jensen <k.jensen@samsung.com>
-
Klaus Jensen authored
This partially reverts commit 98f84f5a. Since all "multi aio" commands are now reimplemented to properly track the nested aiocbs, we can revert the "hack" that was introduced to make sure all requests we're properly drained upon sq deletion. The revert is partial since we keep the assert that no outstanding requests remain on the submission queue after the explicit cancellation. Signed-off-by:
Klaus Jensen <k.jensen@samsung.com> Reviewed-by:
Keith Busch <kbusch@kernel.org>
-
Klaus Jensen authored
Prior to this patch, the aios associated with broadcast format are submitted anonymously (no aiocb reference saved from the blk_aio call). Fix this by formatting the namespaces one after another, saving a reference to the aiocb for each. Signed-off-by:
Klaus Jensen <k.jensen@samsung.com> Reviewed-by:
Keith Busch <kbusch@kernel.org>
-
Klaus Jensen authored
Prior to this patch, the aios associated with zone reset are submitted anonymously (no reference saved to the aiocb from the blk_aio call). Fix this by resetting the zones one after another, saving a reference to the aiocb for each reset. Signed-off-by:
Klaus Jensen <k.jensen@samsung.com> Reviewed-by:
Keith Busch <kbusch@kernel.org>
-
Klaus Jensen authored
Before this patch the code would issue several aios simultaneously without saving a reference to the aiocb. Without the aiocb reference the individual copies cannot be canceled. Fix this by issuing copies of the ranges one after another. Signed-off-by:
Klaus Jensen <k.jensen@samsung.com> Reviewed-by:
Keith Busch <kbusch@kernel.org>
-
Klaus Jensen authored
Some commands report additional useful information in dw0 and dw1 of the completion queue entry. Add them to the trace. Signed-off-by:
Klaus Jensen <k.jensen@samsung.com> Reviewed-by:
Keith Busch <kbusch@kernel.org>
-
Klaus Jensen authored
The nvme_check_prinfo() and nvme_dif_check() functions operate on the 16 bit "control" member of the NvmeCmd. These functions do not otherwise operate on an NvmeCmd or an NvmeRequest, so change them to expect the actual 4 bit PRINFO field and add constants that work on this field as well. Signed-off-by:
Klaus Jensen <k.jensen@samsung.com> Reviewed-by:
Keith Busch <kbusch@kernel.org>
-
Klaus Jensen authored
Make nvme_get_zone_by_slba() return NULL if the slba is out of range. This allows the function to be used without guarding the call with a call to nvme_check_bounds(), in preparation for the next patch. Add asserts after calling nvme_get_zone_by_slba() instead. Signed-off-by:
Klaus Jensen <k.jensen@samsung.com> Reviewed-by:
Keith Busch <kbusch@kernel.org>
-
Klaus Jensen authored
Prepare nvme_dif_pract_generate_dif() and nvme_dif_check() to be callable in smaller increments by making the reftag a pointer parameter updated by the function. Signed-off-by:
Klaus Jensen <k.jensen@samsung.com> Reviewed-by:
Keith Busch <kbusch@kernel.org>
-
Klaus Jensen authored
Prior to this patch, a loop was used to issue multiple "fire and forget" aios for each range in the command. Without a reference to the aiocb returned from the blk_aio_pdiscard calls, the aios cannot be canceled. Fix this by processing the ranges one after another. As a bonus, this fixes how metadata is cleared (i.e. we only zero it out if the data was succesfully discarded). Signed-off-by:
Klaus Jensen <k.jensen@samsung.com> Reviewed-by:
Keith Busch <kbusch@kernel.org>
-
Klaus Jensen authored
Pull the gist of nvme_check_dulbe() into a helper function. This is in preparation for dsm refactoring. Signed-off-by:
Klaus Jensen <k.jensen@samsung.com> Reviewed-by:
Keith Busch <kbusch@kernel.org>
-
Klaus Jensen authored
Prior to this patch, a broadcast flush would result in submitting multiple "fire and forget" aios (no reference saved to the aiocbs returned from the blk_aio_flush calls). Fix this by issuing the flushes one after another. Signed-off-by:
Klaus Jensen <k.jensen@samsung.com> Reviewed-by:
Keith Busch <kbusch@kernel.org>
-
Heinrich Schuchardt authored
On machines with version > 6.0 replace a missing EUI-64 by a generated value. Signed-off-by:
Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by:
Klaus Jensen <k.jensen@samsung.com>
-
Heinrich Schuchardt authored
The EUI-64 field is the only identifier for NVMe namespaces in UEFI device paths. Add a new namespace property "eui64", that provides the user the option to specify the EUI-64. Signed-off-by:
Heinrich Schuchardt <xypron.glpk@gmx.de> Acked-by:
Klaus Jensen <k.jensen@samsung.com> Reviewed-by:
Klaus Jensen <k.jensen@samsung.com>
-
Gollu Appalanaidu authored
As per the TP 4056d Namespace types CNS 0x00 and CNS 0x11 CSI field shouldn't use but it is being used for these two Identify command CNS values, fix that. Remove 'nvme_csi_has_nvm_support()' helper as suggested by Klaus we can safely assume NVM command set support for all namespaces. Suggested-by:
Klaus Jensen <k.jensen@samsung.com> Signed-off-by:
Gollu Appalanaidu <anaidu.gollu@samsung.com> Reviewed-by:
Klaus Jensen <k.jensen@samsung.com> Signed-off-by:
Klaus Jensen <k.jensen@samsung.com>
-
Niklas Cassel authored
In the Zoned Namespace Command Set Specification, chapter 2.5.1 Managing resources "The controller may transition zones in the ZSIO:Implicitly Opened state to the ZSC:Closed state for resource management purposes." The word may in this sentence means that automatically transitioning an implicitly opened zone to closed is completely optional. Add a new parameter so that the user can control if this automatic transitioning should be performed or not. Being able to control this can help with verifying that e.g. a user-space program behaves properly even without this optional ZNS feature. The default value is set to true, in order to not change the existing behavior. Signed-off-by:
Niklas Cassel <niklas.cassel@wdc.com> [k.jensen: moved parameter to controller] Signed-off-by:
Klaus Jensen <k.jensen@samsung.com>
-