summaryrefslogtreecommitdiffstats
path: root/hw
Commit message (Collapse)AuthorAgeFilesLines
* hw/mips/gt64xxx: Trace accesses to ISD registersPhilippe Mathieu-Daudé2021-03-132-0/+4
| | | | | | | | Trace all accesses to Internal Space Decode (ISD) registers. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <20210309142630.728014-6-f4bug@amsat.org>
* hw/mips/gt64xxx: Rename trace events related to interrupt registersPhilippe Mathieu-Daudé2021-03-132-10/+10
| | | | | | | | | | We want to trace all register accesses. First rename the current gt64120_read / gt64120_write events with '_intreg' suffix, as they are restricted to interrupt registers. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <20210309142630.728014-5-f4bug@amsat.org>
* hw/mips/gt64xxx: Fix typos in qemu_log_mask() formatsPhilippe Mathieu-Daudé2021-03-131-10/+10
| | | | | | | | | | | Fix the following typos: - GT_PCI1_CFGDATA is not a timer register but a PCI one, - zero-padding flag is out of the format Fixes: 641ca2bfcd5 ("hw/mips/gt64xxx_pci: Use qemu_log_mask() instead of debug printf()") Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <20210309142630.728014-4-f4bug@amsat.org>
* hw/mips/gt64xxx: Simplify ISD MemoryRegion read/write handlersPhilippe Mathieu-Daudé2021-03-131-4/+6
| | | | | | | | | | | | | The ISD MemoryRegion is implemented for 32-bit accesses. Simplify it by setting the MemoryRegionOps::impl min/max access size fields. Since the region is registered with a size of 0x1000 bytes, we can remove the hwaddr mask. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <20210309142630.728014-3-f4bug@amsat.org>
* hw/mips/gt64xxx: Initialize ISD I/O memory region in DeviceRealize()Philippe Mathieu-Daudé2021-03-131-2/+9
| | | | | | | | | | | The ISD I/O region belongs to the TYPE_GT64120_PCI_HOST_BRIDGE, so initialize it before it is realized, not after. Rename the region as 'gt64120-isd' so it is clearer to realize it belongs to the GT64120 in the memory tree view. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <20210309142630.728014-2-f4bug@amsat.org>
* Merge remote-tracking branch 'remotes/dg-gitlab/tags/ppc-for-6.0-20210310' ↵Peter Maydell2021-03-129-249/+232Star
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | into staging ppc patch queue for 2021-03-10 Next batch of patches for the ppc target and machine types. Includes: * Several cleanups for sm501 from Peter Maydell * An update to the SLOF guest firmware * Improved handling of hotplug failures in spapr, associated cleanups to the hotplug handling code * Several etsec fixes and cleanups from Bin Meng * Assorted other fixes and cleanups # gpg: Signature made Wed 10 Mar 2021 04:08:53 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-20210310: spapr.c: send QAPI event when memory hotunplug fails spapr.c: remove duplicated assert in spapr_memory_unplug_request() target/ppc: fix icount support on Book-e vms accessing SPRs qemu_timer.c: add timer_deadline_ms() helper spapr_pci.c: add 'unplug already in progress' message for PCI unplug spapr.c: add 'unplug already in progress' message for PHB unplug hw/ppc: e500: Add missing <ranges> in the eTSEC node hw/net: fsl_etsec: Fix build error when HEX_DUMP is on spapr_drc.c: use DRC reconfiguration to cleanup DIMM unplug state spapr_drc.c: add hotunplug timeout for CPUs spapr_drc.c: introduce unplug_timeout_timer target/ppc: Fix bcdsub. emulation when result overflows docs/system: Extend PPC section spapr: rename spapr_drc_detach() to spapr_drc_unplug_request() spapr_drc.c: use spapr_drc_release() in isolate_physical/set_unusable pseries: Update SLOF firmware image spapr_drc.c: do not call spapr_drc_detach() in drc_isolate_logical() hw/display/sm501: Inline template header into C file hw/display/sm501: Expand out macros in template header hw/display/sm501: Remove dead code for non-32-bit RGB surfaces Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
| * spapr.c: send QAPI event when memory hotunplug failsDaniel Henrique Barboza2021-03-092-5/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Recent changes allowed the pSeries machine to rollback the hotunplug process for the DIMM when the guest kernel signals, via a reconfiguration of the DR connector, that it's not going to release the LMBs. Let's also warn QAPI listerners about it. One place to do it would be right after the unplug state is cleaned up, spapr_clear_pending_dimm_unplug_state(). This would mean that the function is now doing more than cleaning up the pending dimm state though. This patch does the following changes in spapr.c: - send a QAPI event to inform that we experienced a failure in the hotunplug of the DIMM; - rename spapr_clear_pending_dimm_unplug_state() to spapr_memory_unplug_rollback(). This is a better fit for what the function is now doing, and it makes callers care more about what the function goal is and less about spapr.c internals such as clearing the pending dimm unplug state. Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20210302141019.153729-3-danielhb413@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
| * spapr.c: remove duplicated assert in spapr_memory_unplug_request()Daniel Henrique Barboza2021-03-091-1/+0Star
| | | | | | | | | | | | | | | | | | | | | | | | We are asserting the existence of the first DRC LMB after sending unplug requests to all LMBs of the DIMM, where every DRC is being asserted inside the loop. This means that the first DRC is being asserted twice. Remove the duplicated assert. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20210302141019.153729-2-danielhb413@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
| * qemu_timer.c: add timer_deadline_ms() helperDaniel Henrique Barboza2021-03-091-3/+2Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The pSeries machine is using QEMUTimer internals to return the timeout in seconds for a timer object, in hw/ppc/spapr.c, function spapr_drc_unplug_timeout_remaining_sec(). Create a helper in qemu-timer.c to retrieve the deadline for a QEMUTimer object, in ms, to avoid exposing timer internals to the PPC code. CC: Paolo Bonzini <pbonzini@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20210301124133.23800-2-danielhb413@gmail.com> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
| * spapr_pci.c: add 'unplug already in progress' message for PCI unplugDaniel Henrique Barboza2021-03-091-0/+4
| | | | | | | | | | | | | | | | | | | | | | Hotunplug for all other devices are warning the user when the hotunplug is already in progress. Do the same for PCI devices in spapr_pci_unplug_request(). Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20210226163301.419727-5-danielhb413@gmail.com> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
| * spapr.c: add 'unplug already in progress' message for PHB unplugDaniel Henrique Barboza2021-03-091-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | Both CPU hotunplug and PC_DIMM unplug reports an user warning, mentioning that the hotunplug is in progress, if consecutive 'device_del' are issued in quick succession. Do the same for PHBs in spapr_phb_unplug_request(). Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20210226163301.419727-4-danielhb413@gmail.com> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
| * hw/ppc: e500: Add missing <ranges> in the eTSEC nodeBin Meng2021-03-091-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The eTSEC node should provide an empty <ranges> property in the eTSEC node, otherwise of_translate_address() in the Linux kernel fails to get the eTSEC register base, reporting: OF: ** translation for device /platform@f00000000/ethernet@0/queue-group ** OF: bus is default (na=1, ns=1) on /platform@f00000000/ethernet@0 OF: translating address: 00000000 OF: parent bus is default (na=1, ns=1) on /platform@f00000000 OF: no ranges; cannot translate Per devicetree spec v0.3 [1] chapter 2.3.8: If the property is not present in a bus node, it is assumed that no mapping exists between children of the node and the parent address space. This is why of_translate_address() aborts the address translation. Apparently U-Boot devicetree parser seems to be tolerant with missing <ranges> as this was not noticed when testing with U-Boot. The empty <ranges> property is present in all kernel shipped dtsi files for eTSEC, Let's add it to conform with the spec. [1] https://github.com/devicetree-org/devicetree-specification/releases/download/v0.3/devicetree-specification-v0.3.pdf Fixes: fdfb7f2cdb2d ("e500: Add support for eTSEC in device tree") Signed-off-by: Bin Meng <bin.meng@windriver.com> Message-Id: <1614158919-9473-1-git-send-email-bmeng.cn@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
| * hw/net: fsl_etsec: Fix build error when HEX_DUMP is onBin Meng2021-03-092-0/+2
| | | | | | | | | | | | | | | | | | "qemu-common.h" should be included to provide the forward declaration of qemu_hexdump() when HEX_DUMP is on. Signed-off-by: Bin Meng <bin.meng@windriver.com> Message-Id: <20210228050431.24647-1-bmeng.cn@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
| * spapr_drc.c: use DRC reconfiguration to cleanup DIMM unplug stateDaniel Henrique Barboza2021-03-092-0/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Handling errors in memory hotunplug in the pSeries machine is more complex than any other device type, because there are all the complications that other devices has, and more. For instance, determining a timeout for a DIMM hotunplug must consider if it's a Hash-MMU or a Radix-MMU guest, because Hash guests takes longer to hotunplug DIMMs. The size of the DIMM is also a factor, given that longer DIMMs naturally takes longer to be hotunplugged from the kernel. And there's also the guest memory usage to be considered: if there's a process that is consuming memory that would be lost by the DIMM unplug, the kernel will postpone the unplug process until the process finishes, and then initiate the regular hotunplug process. The first two considerations are manageable, but the last one is a deal breaker. There is no sane way for the pSeries machine to determine the memory load in the guest when attempting a DIMM hotunplug - and even if there was a way, the guest can start using all the RAM in the middle of the unplug process and invalidate our previous assumptions - and in result we can't even begin to calculate a timeout for the operation. This means that we can't implement a viable timeout mechanism for memory unplug in pSeries. Going back to why we would consider an unplug timeout, the reason is that we can't know if the kernel is giving up the unplug. Turns out that, sometimes, we can. Consider a failed memory hotunplug attempt where the kernel will error out with the following message: 'pseries-hotplug-mem: Memory indexed-count-remove failed, adding any removed LMBs' This happens when there is a LMB that the kernel gave up in removing, and the LMBs previously marked for removal are now being added back. This happens in the pseries kernel in [1], dlpar_memory_remove_by_ic() into dlpar_add_lmb(), and after that update_lmb_associativity_index(). In this function, the kernel is configuring the LMB DRC connector again. Note that this is a valid usage in LOPAR, as stated in section "ibm,configure-connector RTAS Call": 'A subsequent sequence of calls to ibm,configure-connector with the same entry from the “ibm,drc-indexes” or “ibm,drc-info” property will restart the configuration of devices which were not completely configured.' We can use this kernel behavior in our favor. If a DRC connector reconfiguration for a LMB that we marked as unplug pending happens, this indicates that the kernel changed its mind about the unplug and is reasserting that it will keep using all the LMBs of the DIMM. In this case, it's safe to assume that the whole DIMM device unplug was cancelled. This patch hops into rtas_ibm_configure_connector() and, in the scenario described above, clear the unplug state for the DIMM device. This will not solve all the problems we still have with memory unplug, but it will cover this case where the kernel reconfigures LMBs after a failed unplug. We are a bit more resilient, without using an unreliable timeout, and we didn't make the remaining error cases any worse. [1] arch/powerpc/platforms/pseries/hotplug-memory.c Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20210222194531.62717-6-danielhb413@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
| * spapr_drc.c: add hotunplug timeout for CPUsDaniel Henrique Barboza2021-03-092-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is a reliable way to make a CPU hotunplug fail in the pseries machine. Hotplug a CPU A, then offline all other CPUs inside the guest but A. When trying to hotunplug A the guest kernel will refuse to do it, because A is now the last online CPU of the guest. PAPR has no 'error callback' in this situation to report back to the platform, so the guest kernel will deny the unplug in silent and QEMU will never know what happened. The unplug pending state of A will remain until the guest is shutdown or rebooted. Previous attempts of fixing it (see [1] and [2]) were aimed at trying to mitigate the effects of the problem. In [1] we were trying to guess which guest CPUs were online to forbid hotunplug of the last online CPU in the QEMU layer, avoiding the scenario described above because QEMU is now failing in behalf of the guest. This is not robust because the last online CPU of the guest can change while we're in the middle of the unplug process, and our initial assumptions are now invalid. In [2] we were accepting that our unplug process is uncertain and the user should be allowed to spam the IRQ hotunplug queue of the guest in case the CPU hotunplug fails. This patch presents another alternative, using the timeout infrastructure introduced in the previous patch. CPU hotunplugs in the pSeries machine will now timeout after 15 seconds. This is a long time for a single CPU unplug to occur, regardless of guest load - although the user is *strongly* encouraged to *not* hotunplug devices from a guest under high load - and we can be sure that something went wrong if it takes longer than that for the guest to release the CPU (the same can't be said about memory hotunplug - more on that in the next patch). Timing out the unplug operation will reset the unplug state of the CPU and allow the user to try it again, regardless of the error situation that prevented the hotunplug to occur. Of all the not so pretty fixes/mitigations for CPU hotunplug errors in pSeries, timing out the operation is an admission that we have no control in the process, and must assume the worst case if the operation doesn't succeed in a sensible time frame. [1] https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg03353.html [2] https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg04400.html Reported-by: Xujun Ma <xuma@redhat.com> Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1911414 Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20210222194531.62717-5-danielhb413@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
| * spapr_drc.c: introduce unplug_timeout_timerDaniel Henrique Barboza2021-03-091-0/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The LoPAR spec provides no way for the guest kernel to report failure of hotplug/hotunplug events. This wouldn't be bad if those operations were granted to always succeed, but that's far for the reality. What ends up happening is that, in the case of a failed hotunplug, regardless of whether it was a QEMU error or a guest misbehavior, the pSeries machine is retaining the unplug state of the device in the running guest. This state is cleanup in machine reset, where it is assumed that this state represents a device that is pending unplug, and the device is hotunpluged from the board. Until the reset occurs, any hotunplug operation of the same device is forbid because there is a pending unplug state. This behavior has at least one undesirable side effect. A long standing pending unplug state is, more often than not, the result of a hotunplug error. The user had to dealt with it, since retrying to unplug the device is noy allowed, and then in the machine reset we're removing the device from the guest. This means that we're failing the user twice - failed to hotunplug when asked, then hotunplugged without notice. Solutions to this problem range between trying to predict when the hotunplug will fail and forbid the operation from the QEMU layer, from opening up the IRQ queue to allow for multiple hotunplug attempts, from telling the users to 'reboot the machine if something goes wrong'. The first solution is flawed because we can't fully predict guest behavior from QEMU, the second solution is a trial and error remediation that counts on a hope that the unplug will eventually succeed, and the third is ... well. This patch introduces a crude, but effective solution to hotunplug errors in the pSeries machine. For each unplug done, we'll timeout after some time. If a certain amount of time passes, we'll cleanup the hotunplug state from the machine. During the timeout period, any unplug operations in the same device will still be blocked. After that, we'll assume that the guest failed the operation, and allow the user to try again. If the timeout is too short we'll prevent legitimate hotunplug situations to occur, so we'll need to overestimate the regular time an unplug operation takes to succeed to account that. The true solution for the hotunplug errors in the pSeries machines is a PAPR change to allow for the guest to warn the platform about it. For now, the work done in this timeout design can be used for the new PAPR 'abort hcall' in the future, given that for both cases we'll need code to cleanup the existing unplug states of the DRCs. At this moment we're adding the basic wiring of the timer into the DRC. Next patch will use the timer to timeout failed CPU hotunplugs. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20210222194531.62717-4-danielhb413@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
| * spapr: rename spapr_drc_detach() to spapr_drc_unplug_request()Daniel Henrique Barboza2021-03-094-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | spapr_drc_detach() is not the best name for what the function does. The function does not detach the DRC, it makes an uncommited attempt to do it. It'll mark the DRC as pending unplug, via the 'unplug_request' flag, and only if the DRC state is drck->empty_state it will detach the DRC, via spapr_drc_release(). This is a contrast with its pair spapr_drc_attach(), where the function is indeed creating the DRC QOM object. If you know what spapr_drc_attach() does, you can be misled into thinking that spapr_drc_detach() is removing the DRC from QEMU internal state, which isn't true. The current role of this function is better described as a request for detach, since there's no guarantee that we're going to detach the DRC in the end. Rename the function to spapr_drc_unplug_request to reflect what is is doing. The initial idea was to change the name to spapr_drc_detach_request(), and later on change the unplug_request flag to detach_request. However, unplug_request is a migratable boolean for a long time now and renaming it is not worth the trouble. spapr_drc_unplug_request() setting drc->unplug_request is more natural than spapr_drc_detach_request setting drc->unplug_request. Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20210222194531.62717-3-danielhb413@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
| * spapr_drc.c: use spapr_drc_release() in isolate_physical/set_unusableDaniel Henrique Barboza2021-03-091-16/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When moving a physical DRC to "Available", drc_isolate_physical() will move the DRC state to STATE_PHYSICAL_POWERON and, if the DRC is marked for unplug, call spapr_drc_detach(). For physical DRCs, drck->empty_state is STATE_PHYSICAL_POWERON, meaning that we're sure that spapr_drc_detach() will end up calling spapr_drc_release() in the end. Likewise, for logical DRCs, drc_set_unusable will move the DRC to "Unusable" state, setting drc->state to STATE_LOGICAL_UNUSABLE, which is the drck->empty_state for logical DRCs. spapr_drc_detach() will call spapr_drc_release() in this case as well. In both scenarios, spapr_drc_detach() is being used as a spapr_drc_release(), wrapper, where we also set unplug_requested (which is already true, otherwise spapr_drc_detach() wouldn't be called in the first place) and check if drc->state == drck->empty_state, which we also know it's guaranteed to be true because we just set it. Just use spapr_drc_release() in these functions to be clear of our intentions in both these functions. Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20210222194531.62717-2-danielhb413@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
| * spapr_drc.c: do not call spapr_drc_detach() in drc_isolate_logical()Daniel Henrique Barboza2021-03-091-13/+0Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | drc_isolate_logical() is used to move the DRC from the "Configured" to the "Available" state, erroring out if the DRC is in the unexpected "Unisolate" state and doing nothing (with RTAS_OUT_SUCCESS) if the DRC is already in "Available" or in "Unusable" state. When moving from "Configured" to "Available", the DRC is moved to the LOGICAL_AVAILABLE state, a drc->unplug_requested check is done and, if true, spapr_drc_detach() is called. What spapr_drc_detach() does then is: - set drc->unplug_requested to true. In fact, this is the only place where unplug_request is set to true; - does nothing else if drc->state != drck->empty_state. If the DRC state is equal to drck->empty_state, spapr_drc_release() is called. For logical DRCs, drck->empty_state = LOGICAL_UNUSABLE. In short, calling spapr_drc_detach() in drc_isolate_logical() does nothing. It'll set unplug_request to true again ('again' since it was already true - otherwise the function wouldn't be called), and will return without calling spapr_drc_release() because the DRC is not in LOGICAL_UNUSABLE, since drc_isolate_logical() just moved it to LOGICAL_AVAILABLE. The only place where the logical DRC is released is when called from drc_set_unusable(), when it is moved to the "Unusable" state. As it should, according to PAPR. Even though calling spapr_drc_detach() in drc_isolate_logical() is benign, removing it will avoid further thought about the matter. So let's go ahead and do that. As a note, this logic was introduced in commit bbf5c878ab76. Since then, the DRC handling code was refactored and enhanced, and PAPR itself went through some changes in the DRC area as well. It is expected that some assumptions we had back then are now deprecated. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20210211225246.17315-2-danielhb413@gmail.com> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
| * hw/display/sm501: Inline template header into C filePeter Maydell2021-03-092-107/+81Star
| | | | | | | | | | | | | | | | | | | | We no longer need to include sm501_template.h multiple times, so we can simply inline its contents into sm501.c. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20210212180653.27588-4-peter.maydell@linaro.org> Acked-by: BALATON Zoltan <balaton@eik.bme.hu> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
| * hw/display/sm501: Expand out macros in template headerPeter Maydell2021-03-091-43/+17Star
| | | | | | | | | | | | | | | | | | | | | | Now that we only include sm501_template.h for the DEPTH==32 case, we can expand out the uses of the BPP, PIXEL_TYPE and PIXEL_NAME macros in that header. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20210212180653.27588-3-peter.maydell@linaro.org> Acked-by: BALATON Zoltan <balaton@eik.bme.hu> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
| * hw/display/sm501: Remove dead code for non-32-bit RGB surfacesPeter Maydell2021-03-091-85/+6Star
| | | | | | | | | | | | | | | | | | | | | | | | For a long time now the UI layer has guaranteed that the console surface is always 32 bits per pixel RGB. Remove the legacy dead code from the sm501 display device which was handling the possibility that the console surface was some other format. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20210212180653.27588-2-peter.maydell@linaro.org> Acked-by: BALATON Zoltan <balaton@eik.bme.hu> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* | Merge remote-tracking branch ↵Peter Maydell2021-03-1139-42/+45
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 'remotes/vivier2/tags/trivial-branch-for-6.0-pull-request' into staging Pull request # gpg: Signature made Wed 10 Mar 2021 21:56:09 GMT # gpg: using RSA key CD2F75DDC8E3A4DC2E4F5173F30C38BD3F2FBE3C # gpg: issuer "laurent@vivier.eu" # gpg: Good signature from "Laurent Vivier <lvivier@redhat.com>" [full] # gpg: aka "Laurent Vivier <laurent@vivier.eu>" [full] # gpg: aka "Laurent Vivier (Red Hat) <lvivier@redhat.com>" [full] # Primary key fingerprint: CD2F 75DD C8E3 A4DC 2E4F 5173 F30C 38BD 3F2F BE3C * remotes/vivier2/tags/trivial-branch-for-6.0-pull-request: (22 commits) sysemu: Let VMChangeStateHandler take boolean 'running' argument sysemu/runstate: Let runstate_is_running() return bool hw/lm32/Kconfig: Have MILKYMIST select LM32_DEVICES hw/lm32/Kconfig: Rename CONFIG_LM32 -> CONFIG_LM32_DEVICES hw/lm32/Kconfig: Introduce CONFIG_LM32_EVR for lm32-evr/uclinux boards qemu-common.h: Update copyright string to 2021 tests/fp/fp-test: Replace the word 'blacklist' qemu-options: Replace the word 'blacklist' seccomp: Replace the word 'blacklist' scripts/tracetool: Replace the word 'whitelist' ui: Replace the word 'whitelist' virtio-gpu: Adjust code space style exec/memory: Use struct Object typedef fuzz-test: remove unneccessary debugging flags net: Use id_generate() in the network subsystem, too MAINTAINERS: Fix the location of tools manuals vhost_user_gpu: Drop dead check for g_malloc() failure backends/dbus-vmstate: Fix short read error handling target/hexagon/gen_tcg_funcs: Fix a typo hw/elf_ops: Fix a typo ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
| * | sysemu: Let VMChangeStateHandler take boolean 'running' argumentPhilippe Mathieu-Daudé2021-03-0924-24/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The 'running' argument from VMChangeStateHandler does not require other value than 0 / 1. Make it a plain boolean. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Acked-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20210111152020.1422021-3-philmd@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
| * | hw/lm32/Kconfig: Have MILKYMIST select LM32_DEVICESPhilippe Mathieu-Daudé2021-03-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Milkymist board requires more than the PTIMER. Directly select the LM32_DEVICES. This fixes: /usr/bin/ld: libqemu-lm32-softmmu.fa.p/target_lm32_gdbstub.c.o: in function `lm32_cpu_gdb_read_register': target/lm32/gdbstub.c:46: undefined reference to `lm32_pic_get_im' target/lm32/gdbstub.c:48: undefined reference to `lm32_pic_get_ip' libqemu-lm32-softmmu.fa.p/target_lm32_op_helper.c.o: in function `helper_wcsr_im': target/lm32/op_helper.c:107: undefined reference to `lm32_pic_set_im' libqemu-lm32-softmmu.fa.p/target_lm32_op_helper.c.o: in function `helper_wcsr_ip': target/lm32/op_helper.c:114: undefined reference to `lm32_pic_set_ip' libqemu-lm32-softmmu.fa.p/target_lm32_op_helper.c.o: in function `helper_wcsr_jtx': target/lm32/op_helper.c:120: undefined reference to `lm32_juart_set_jtx' libqemu-lm32-softmmu.fa.p/target_lm32_op_helper.c.o: in function `helper_wcsr_jrx': target/lm32/op_helper.c:125: undefined reference to `lm32_juart_set_jrx' libqemu-lm32-softmmu.fa.p/target_lm32_translate.c.o: in function `lm32_cpu_dump_state': target/lm32/translate.c:1161: undefined reference to `lm32_pic_get_ip' target/lm32/translate.c:1161: undefined reference to `lm32_pic_get_im' Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210221225626.2589247-4-f4bug@amsat.org> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
| * | hw/lm32/Kconfig: Rename CONFIG_LM32 -> CONFIG_LM32_DEVICESPhilippe Mathieu-Daudé2021-03-094-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We want to be able to use the 'LM32' config for architecture specific features. As CONFIG_LM32 is only used to select peripherals, rename it CONFIG_LM32_DEVICES. Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210221225626.2589247-3-f4bug@amsat.org> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
| * | hw/lm32/Kconfig: Introduce CONFIG_LM32_EVR for lm32-evr/uclinux boardsPhilippe Mathieu-Daudé2021-03-092-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We want to be able to use the 'LM32' config for architecture specific features. Introduce CONFIG_LM32_EVR to select the lm32-evr / lm32-uclinux boards. Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210221225626.2589247-2-f4bug@amsat.org> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
| * | virtio-gpu: Adjust code space stylelijiejun2021-03-091-2/+1Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | Fix code style. Operator needs align with eight spaces, and delete line space. Signed-off-by: lijiejun <a_lijiejun@163.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <1615292050-108748-1-git-send-email-a_lijiejun@163.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
| * | exec/memory: Use struct Object typedefPhilippe Mathieu-Daudé2021-03-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We forward-declare Object typedef in "qemu/typedefs.h" since commit ca27b5eb7cd ("qom/object: Move Object typedef to 'qemu/typedefs.h'"). Use it everywhere to make the code simpler. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Acked-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Message-Id: <20210225182003.3629342-1-philmd@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
| * | vhost_user_gpu: Drop dead check for g_malloc() failureMarkus Armbruster2021-03-091-1/+0Star
| | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <20210126124240.2081959-3-armbru@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
| * | scsi: Silence gcc warningEric Blake2021-03-091-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On Fedora 33, gcc 10.2.1 notes that scsi_cdb_length(buf) can set len==-1, which in turn overflows g_malloc(): [5/5] Linking target qemu-system-x86_64 In function ‘scsi_disk_new_request_dump’, inlined from ‘scsi_new_request’ at ../hw/scsi/scsi-disk.c:2608:9: ../hw/scsi/scsi-disk.c:2582:19: warning: argument 1 value ‘18446744073709551612’ exceeds maximum object size 9223372036854775807 [-Walloc-size-larger-than=] 2582 | line_buffer = g_malloc(len * 5 + 1); | ^ Silence it with a decent assertion, since we only convert a buffer to bytes when we have a valid cdb length. Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20210209152350.207958-1-eblake@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
| * | Various spelling fixesMichael Tokarev2021-03-096-6/+6
| |/ | | | | | | | | | | | | | | | | | | | | An assorted set of spelling fixes in various places. Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> Reviewed-by: Stefan Weil <sw@weilnetz.de> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20210309111510.79495-1-mjt@msgid.tls.msk.ru> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
* | Merge remote-tracking branch ↵Peter Maydell2021-03-1114-1910/+377Star
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 'remotes/stsquad/tags/pull-testing-docs-xen-updates-100321-2' into staging Testing, guest-loader and other misc tweaks - add warning text to quickstart example - add CFI tests to CI - use --arch-only for docker pre-requisites - fix .editorconfig for emacs - add guest-loader for Xen-like hypervisor testing - move generic-loader docs into manual proper - move semihosting out of hw/ # gpg: Signature made Wed 10 Mar 2021 15:35:31 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-docs-xen-updates-100321-2: semihosting: Move hw/semihosting/ -> semihosting/ semihosting: Move include/hw/semihosting/ -> include/semihosting/ tests/avocado: add boot_xen tests docs: add some documentation for the guest-loader docs: move generic-loader documentation into the main manual hw/core: implement a guest-loader to support static hypervisor guests device_tree: add qemu_fdt_setprop_string_array helper hw/riscv: migrate fdt field to generic MachineState hw/board: promote fdt from ARM VirtMachineState to MachineState .editorconfig: update the automatic mode setting for Emacs tests/docker: Use --arch-only when building Debian cross image gitlab-ci.yml: Add jobs to test CFI flags gitlab-ci.yml: Allow custom # of parallel linkers tests/docker: add a test-tcg for building then running check-tcg docs/system: add a gentle prompt for the complexity to come Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
| * | semihosting: Move hw/semihosting/ -> semihosting/Philippe Mathieu-Daudé2021-03-108-1728/+0Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the exception of hw/core/, the hw/ directory only contains device models used in system emulation. Semihosting is also used by user emulation. As a generic feature, move it out of hw/ directory. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20210226131356.3964782-3-f4bug@amsat.org> Message-Id: <20210305135451.15427-3-alex.bennee@linaro.org>
| * | semihosting: Move include/hw/semihosting/ -> include/semihosting/Philippe Mathieu-Daudé2021-03-104-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We want to move the semihosting code out of hw/ in the next patch. This patch contains the mechanical steps, created using: $ git mv include/hw/semihosting/ include/ $ sed -i s,hw/semihosting,semihosting, $(git grep -l hw/semihosting) Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20210226131356.3964782-2-f4bug@amsat.org> Message-Id: <20210305135451.15427-2-alex.bennee@linaro.org>
| * | hw/core: implement a guest-loader to support static hypervisor guestsAlex Bennée2021-03-103-0/+181
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Hypervisors, especially type-1 ones, need the firmware/bootcode to put their initial guest somewhere in memory and pass the information to it via platform data. The guest-loader is modelled after the generic loader for exactly this sort of purpose: $QEMU $ARGS -kernel ~/xen.git/xen/xen \ -append "dom0_mem=1G,max:1G loglvl=all guest_loglvl=all" \ -device guest-loader,addr=0x42000000,kernel=Image,bootargs="root=/dev/sda2 ro console=hvc0 earlyprintk=xen" \ -device guest-loader,addr=0x47000000,initrd=rootfs.cpio 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: <20210303173642.3805-5-alex.bennee@linaro.org>
| * | hw/riscv: migrate fdt field to generic MachineStateAlex Bennée2021-03-101-10/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a mechanical change to make the fdt available through MachineState. 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: <20210303173642.3805-3-alex.bennee@linaro.org>
| * | hw/board: promote fdt from ARM VirtMachineState to MachineStateAlex Bennée2021-03-101-171/+185
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The use of FDT's is quite common across our various platforms. To allow the guest loader to tweak it we need to make it available in the generic state. This creates the field and migrates the initial user to use the generic field. Other boards will be updated in later patches. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20210303173642.3805-2-alex.bennee@linaro.org>
* | | Merge remote-tracking branch 'remotes/legoater/tags/pull-aspeed-20210309' ↵Peter Maydell2021-03-114-13/+565
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | into staging Aspeed patches : * New model for the Aspeed LPC controller * Misc cleanups # gpg: Signature made Tue 09 Mar 2021 11:54:25 GMT # gpg: using RSA key A0F66548F04895EBFE6B0B6051A343C7CFFBECA1 # gpg: Good signature from "Cédric Le Goater <clg@kaod.org>" [undefined] # gpg: WARNING: This key is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: A0F6 6548 F048 95EB FE6B 0B60 51A3 43C7 CFFB ECA1 * remotes/legoater/tags/pull-aspeed-20210309: hw/misc: Model KCS devices in the Aspeed LPC controller hw/misc: Add a basic Aspeed LPC controller model hw/arm: ast2600: Correct the iBT interrupt ID hw/arm: ast2600: Set AST2600_MAX_IRQ to value from datasheet hw/arm: ast2600: Force a multiple of 32 of IRQs for the GIC hw/arm/aspeed: Fix location of firmware images in documentation arm/ast2600: Fix SMP booting with -kernel Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
| * | | hw/misc: Model KCS devices in the Aspeed LPC controllerAndrew Jeffery2021-03-093-4/+407
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Keyboard-Controller-Style devices for IPMI purposes are exposed via LPC IO cycles from the BMC to the host. Expose support on the BMC side by implementing the usual MMIO behaviours, and expose the ability to inspect the KCS registers in "host" style by accessing QOM properties associated with each register. The model caters to the IRQ style of both the AST2600 and the earlier SoCs (AST2400 and AST2500). The AST2600 allocates an IRQ for each LPC sub-device, while there is a single IRQ shared across all subdevices on the AST2400 and AST2500. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20210302014317.915120-6-andrew@aj.id.au> Signed-off-by: Cédric Le Goater <clg@kaod.org>
| * | | hw/misc: Add a basic Aspeed LPC controller modelCédric Le Goater2021-03-094-1/+157
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a very minimal framework to access registers which are used to configure the AHB memory mapping of the flash chips on the LPC HC Firmware address space. Signed-off-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Message-Id: <20210302014317.915120-5-andrew@aj.id.au> Signed-off-by: Cédric Le Goater <clg@kaod.org>
| * | | hw/arm: ast2600: Correct the iBT interrupt IDAndrew Jeffery2021-03-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The AST2600 allocates distinct GIC IRQs for the LPC subdevices such as the iBT device. Previously on the AST2400 and AST2500 the LPC subdevices shared a single LPC IRQ. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20210302014317.915120-4-andrew@aj.id.au> Signed-off-by: Cédric Le Goater <clg@kaod.org>
| * | | hw/arm: ast2600: Set AST2600_MAX_IRQ to value from datasheetAndrew Jeffery2021-03-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The datasheet says we have 197 IRQs allocated, and we need more than 128 to describe IRQs from LPC devices. Raise the value now to allow modelling of the LPC devices. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20210302014317.915120-3-andrew@aj.id.au> Signed-off-by: Cédric Le Goater <clg@kaod.org>
| * | | hw/arm: ast2600: Force a multiple of 32 of IRQs for the GICAndrew Jeffery2021-03-091-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This appears to be a requirement of the GIC model. The AST2600 allocates 197 GIC IRQs, which we will adjust shortly. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20210302014317.915120-2-andrew@aj.id.au> Signed-off-by: Cédric Le Goater <clg@kaod.org>
| * | | arm/ast2600: Fix SMP booting with -kernelJoel Stanley2021-03-091-7/+0Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ast2600 machines do not have PSCI firmware, so this property should have never been set. Removing this node fixes SMP booting Linux kernels that have PSCI enabled, as Linux fails to find PSCI in the device tree and falls back to the soc-specific method for enabling secondary CPUs. The comment is out of date as Qemu has supported -kernel booting since 9bb6d14081ce ("aspeed: Add boot stub for smp booting"), in v5.1. Fixes: f25c0ae1079d ("aspeed/soc: Add AST2600 support") Signed-off-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Tested-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20210303010505.635621-1-joel@jms.id.au> Signed-off-by: Cédric Le Goater <clg@kaod.org>
* | | | Merge remote-tracking branch 'remotes/nvme/tags/nvme-next-pull-request' into ↵Peter Maydell2021-03-108-393/+1359
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | staging hw/block/nvme updates * NVMe subsystem support (`-device nvme-subsys`) (Minwoo Im) * Namespace (De|At)tachment support (Minwoo Im) * Simple Copy command support (Klaus Jensen) * Flush broadcast support (Gollu Appalanaidu) * QEMUIOVector/QEMUSGList duality refactoring (Klaus Jensen) plus various fixes from Minwoo, Gollu, Dmitry and me. v2: - add `nqn` nvme-subsys device parameter instead of using `id`. (Paolo) # gpg: Signature made Tue 09 Mar 2021 11:44:17 GMT # gpg: using RSA key 522833AA75E2DCE6A24766C04DE1AF316D4F0DE9 # gpg: Good signature from "Klaus Jensen <its@irrelevant.dk>" [unknown] # gpg: aka "Klaus Jensen <k.jensen@samsung.com>" [unknown] # gpg: WARNING: This key is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: DDCA 4D9C 9EF9 31CC 3468 4272 63D5 6FC5 E55D A838 # Subkey fingerprint: 5228 33AA 75E2 DCE6 A247 66C0 4DE1 AF31 6D4F 0DE9 * remotes/nvme/tags/nvme-next-pull-request: (38 commits) hw/block/nvme: support Identify NS Attached Controller List hw/block/nvme: support changed namespace asynchronous event hw/block/nvme: support namespace attachment command hw/block/nvme: refactor nvme_select_ns_iocs hw/block/nvme: support allocated namespace type hw/block/nvme: fix allocated namespace list to 256 hw/block/nvme: fix namespaces array to 1-based hw/block/nvme: support namespace detach hw/block/nvme: refactor nvme_dma hw/block/nvme: remove the req dependency in map functions hw/block/nvme: try to deal with the iov/qsg duality hw/block/nvme: fix strerror printing hw/block/nvme: remove block accounting for write zeroes hw/block/nvme: remove redundant len member in compare context hw/block/nvme: report non-mdts command size limit for dsm hw/block/nvme: add trace event for zone read check hw/block/nvme: fix potential compilation error hw/block/nvme: add identify trace event hw/block/nvme: remove unnecessary endian conversion hw/block/nvme: align zoned.zasl with mdts ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
| * | | | hw/block/nvme: support Identify NS Attached Controller ListMinwoo Im2021-03-092-0/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Support Identify command for Namespace attached controller list. This command handler will traverse the controller instances in the given subsystem to figure out whether the specified nsid is attached to the controllers or not. The 4096bytes Identify data will return with the first entry (16bits) indicating the number of the controller id entries. So, the data can hold up to 2047 entries for the controller ids. Signed-off-by: Minwoo Im <minwoo.im.dev@gmail.com> Reviewed-by: Keith Busch <kbusch@kernel.org> Reviewed-by: Klaus Jensen <k.jensen@samsung.com> Tested-by: Klaus Jensen <k.jensen@samsung.com> [k.jensen: rebased for dma refactor] Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
| * | | | hw/block/nvme: support changed namespace asynchronous eventMinwoo Im2021-03-093-0/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If namespace inventory is changed due to some reasons (e.g., namespace attachment/detachment), controller can send out event notifier to the host to manage namespaces. This patch sends out the AEN to the host after either attach or detach namespaces from controllers. To support clear of the event from the controller, this patch also implemented Get Log Page command for Changed Namespace List log type. To return namespace id list through the command, when namespace inventory is updated, id is added to the per-controller list (changed_ns_list). To indicate the support of this async event, this patch set OAES(Optional Asynchronous Events Supported) in Identify Controller data structure. Signed-off-by: Minwoo Im <minwoo.im.dev@gmail.com> Reviewed-by: Keith Busch <kbusch@kernel.org> Reviewed-by: Klaus Jensen <k.jensen@samsung.com> Tested-by: Klaus Jensen <k.jensen@samsung.com> Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
| * | | | hw/block/nvme: support namespace attachment commandMinwoo Im2021-03-094-1/+76
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch supports Namespace Attachment command for the pre-defined nvme-ns device nodes. Of course, attach/detach namespace should only be supported in case 'subsys' is given. This is because if we detach a namespace from a controller, somebody needs to manage the detached, but allocated namespace in the NVMe subsystem. As command effect for the namespace attachment command is registered, the host will be notified that namespace inventory is changed so that host will rescan the namespace inventory after this command. For example, kernel driver manages this command effect via passthru IOCTL. Signed-off-by: Minwoo Im <minwoo.im.dev@gmail.com> Reviewed-by: Keith Busch <kbusch@kernel.org> Reviewed-by: Klaus Jensen <k.jensen@samsung.com> Tested-by: Klaus Jensen <k.jensen@samsung.com> [k.jensen: rebased for dma refactor] Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
| * | | | hw/block/nvme: refactor nvme_select_ns_iocsMinwoo Im2021-03-091-15/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch has no functional changes. This patch just refactored nvme_select_ns_iocs() to iterate the attached namespaces of the controlller and make it invoke __nvme_select_ns_iocs(). Signed-off-by: Minwoo Im <minwoo.im.dev@gmail.com> Reviewed-by: Keith Busch <kbusch@kernel.org> Reviewed-by: Klaus Jensen <k.jensen@samsung.com> Tested-by: Klaus Jensen <k.jensen@samsung.com> Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2024-12-18 13:45:54 +0100