aboutsummaryrefslogtreecommitdiff
path: root/hw
AgeCommit message (Collapse)Author
2016-11-01nvdimm acpi: prebuild nvdimm devices for available slotsXiao Guangrong
For each NVDIMM present or intended to be supported by platform, platform firmware also exposes an ACPI Namespace Device under the root device So it builds nvdimm devices for all slots to support vNVDIMM hotplug Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Xiao Guangrong <guangrong.xiao@linux.intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-11-01nvdimm acpi: use common macros instead of magic namesXiao Guangrong
There are some names repeatedly used in acpi code, define them as macros to refine the code Suggested-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Xiao Guangrong <guangrong.xiao@linux.intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-11-01acpi nvdimm: rename result_size to dsm_out_buf_sizXiao Guangrong
Rename it as dsm_out_buf_siz is more descriptive Suggested-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Xiao Guangrong <guangrong.xiao@linux.intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-11-01nvdimm acpi: compile nvdimm acpi code arch-independentlyXiao Guangrong
As the arch dependent info, TARGET_PAGE_SIZE, has been dropped from nvdimm acpi code, it can be compiled arch-independently Signed-off-by: Xiao Guangrong <guangrong.xiao@linux.intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-11-01acpi nvdimm: fix Arg6 usageXiao Guangrong
As the function only has 5 args, we use local7 instead of it Suggested-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Xiao Guangrong <guangrong.xiao@linux.intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-11-01acpi nvdimm: fix ARG3 conflictXiao Guangrong
As ARG3 is a reserved name, we rename it to FARG Suggested-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Xiao Guangrong <guangrong.xiao@linux.intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-11-01acpi nvdimm: fix device physical address baseXiao Guangrong
According to ACPI 6.0 spec, "Memory Device Physical Address Region Base" in memdev is defined as "This field provides the Device Physical Address base of the region". This field should be zero in our case Signed-off-by: Xiao Guangrong <guangrong.xiao@linux.intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-11-01acpi nvdimm: fix OperationRegion definitionXiao Guangrong
Based on ACPI spec: RegionOffset := TermArg => Integer However, Named object is not a TermArg. This patch moves OperationRegion to NCAL() and uses localX as its RegionOffset Suggested-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Xiao Guangrong <guangrong.xiao@linux.intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-11-01acpi nvdimm: fix wrong buffer size returned by DSM methodXiao Guangrong
Currently, 'RLEN' is the totally buffer size written by QEMU and it is ACPI internally used only. The buffer size returned to guest should not include 'RLEN' itself Signed-off-by: Xiao Guangrong <guangrong.xiao@linux.intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-11-01virtio-crypto: using bh to handle dataq's requestsGonglei
Make crypto operations are executed asynchronously, so that other QEMU threads and monitor couldn't be blocked at the virtqueue handling context. Signed-off-by: Gonglei <arei.gonglei@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-11-01cryptodev: introduce an unified wrapper for crypto operationGonglei
We use an opaque point to the VirtIOCryptoReq which can support different packets based on different algorithms. Signed-off-by: Gonglei <arei.gonglei@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-11-01virtio-crypto: add data queue processing handlerGonglei
Introduces VirtIOCryptoReq structure to store crypto request so that we can easily support asynchronous crypto operation in the future. At present, we only support cipher and algorithm chaining. Signed-off-by: Gonglei <arei.gonglei@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-11-01virtio-crypto: add control queue handlerGonglei
Realize the symmetric algorithm control queue handler, including plain cipher and chainning algorithms. Currently the control queue is used to create and close session for symmetric algorithm. Signed-off-by: Gonglei <arei.gonglei@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-11-01virtio-crypto: set capacity of algorithms supportedGonglei
Expose the capacity of algorithms supported by virtio crypto device to the frontend driver using pci configuration space. Signed-off-by: Gonglei <arei.gonglei@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-11-01virtio-crypto-pci: add virtio crypto pci supportGonglei
This patch adds virtio-crypto-pci, which is the pci proxy for the virtio crypto device. Signed-off-by: Gonglei <arei.gonglei@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-11-01virtio-crypto: add virtio crypto device emulationGonglei
Introduce the virtio crypto realization, I'll finish the core code in the following patches. The thoughts came from virtio net realization. For more information see: http://qemu-project.org/Features/VirtioCrypto Signed-off-by: Gonglei <arei.gonglei@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-10-30virtio: inline set_host_notifier_internalPaolo Bonzini
This is only called from virtio_bus_set_host_notifier. Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-10-30virtio: inline virtio_queue_set_host_notifier_fd_handlerPaolo Bonzini
Of the three possible parameter combinations for virtio_queue_set_host_notifier_fd_handler: - assign=true/set_handler=true is only called from virtio_device_start_ioeventfd - assign=false/set_handler=false is called from set_host_notifier_internal but it only does something when reached from virtio_device_stop_ioeventfd_impl; otherwise there is no EventNotifier set on qemu_get_aio_context(). - assign=true/set_handler=false is called from set_host_notifier_internal, but it is not doing anything: with the new start_ioeventfd and stop_ioeventfd methods, there is never an EventNotifier set on qemu_get_aio_context() at this point. This is enforced by the assertion in virtio_bus_set_host_notifier. Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-10-30virtio: use virtio_bus_set_host_notifier to start/stop ioeventfdPaolo Bonzini
ioeventfd_disabled was the only reason for the default implementation of virtio_device_start_ioeventfd not to use virtio_bus_set_host_notifier. This is now fixed, and the sole entry point to set up ioeventfd can be virtio_bus_set_host_notifier. Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-10-30virtio: remove ioeventfd_disabled altogetherPaolo Bonzini
Now that there is not anymore a switch from the generic ioeventfd handler to the dataplane handler, virtio_bus_set_host_notifier(assign=true) is always called with !bus->ioeventfd_started, hence virtio_bus_stop_ioeventfd does nothing in this case. Move the invocation to vhost.c, which is the only place that needs it. Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-10-30virtio: remove set_handler argument from set_host_notifier_internalPaolo Bonzini
Make virtio_device_start_ioeventfd_impl use the same logic as dataplane to set up the host notifier. This removes the need for the set_handler argument in set_host_notifier_internal. This is a first step towards using virtio_bus_set_host_notifier as the sole entry point to set up ioeventfds. At least now the functions have the same interface, but they still differ in that virtio_bus_set_host_notifier sets ioeventfd_disabled. Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-10-30Revert "virtio: Introduce virtio_add_queue_aio"Paolo Bonzini
This reverts commit 872dd82c83745a603d2e07a03d34313eb6467ae4. virtio_add_queue_aio is unused. Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-10-30virtio-scsi: always use dataplane path if ioeventfd is activePaolo Bonzini
Override start_ioeventfd and stop_ioeventfd to start/stop the whole dataplane logic. This has some positive side effects: - no need anymore for virtio_add_queue_aio (i.e. a revert of commit 1c627137c10ee2dcf59e0383ade8a9abfa2d4355) - no need anymore to switch from generic ioeventfd handlers to dataplane It detects some errors better: $ qemu-system-x86_64 -object iothread,id=io \ -device virtio-scsi-pci,ioeventfd=off,iothread=io qemu-system-x86_64: -device virtio-scsi-pci,ioeventfd=off,iothread=io: ioeventfd is required for iothread while previously it would have started just fine. Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-10-30virtio-blk: always use dataplane path if ioeventfd is activePaolo Bonzini
Override start_ioeventfd and stop_ioeventfd to start/stop the whole dataplane logic. This has some positive side effects: - no need anymore for virtio_add_queue_aio (i.e. a revert of commit 0ff841f6d138904d514efa1d885bcaf54583852d) - no need anymore to switch from generic ioeventfd handlers to dataplane It detects some errors better: $ qemu-system-x86_64 -object iothread,id=io \ -drive id=null,file=null-aio://,if=none,format=raw \ -device virtio-blk-pci,ioeventfd=off,iothread=io,drive=null qemu-system-x86_64: -device virtio-blk-pci,ioeventfd=off,iothread=io,drive=null: ioeventfd is required for iothread while previously it would have started just fine. Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-10-30virtio: introduce virtio_device_ioeventfd_enabledPaolo Bonzini
This will be used to forbid iothread configuration when the proxy does not allow using ioeventfd. To simplify the implementation, change the direction of the ioeventfd_disabled callback too. Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-10-30virtio: add start_ioeventfd and stop_ioeventfd to VirtioDeviceClassPaolo Bonzini
Allow customization of the start and stop of ioeventfd. This will allow direct start of dataplane without passing through the default ioeventfd handlers, which in turn allows using the dataplane logic instead of virtio_add_queue_aio. It will also enable some code simplification, because the sole entry point to ioeventfd setup will be virtio_bus_set_host_notifier. Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-10-30virtio: move ioeventfd_started flag to VirtioBusStatePaolo Bonzini
This simplifies the code and removes the ioeventfd_started and ioeventfd_set_started callback. The only difference is in how virtio-ccw handles an error---it doesn't disable ioeventfd forever anymore. It was the only backend to do so, and if desired this behavior should be implemented in virtio-bus.c. Instead of ioeventfd_started, the ioeventfd_assign callback now determines whether the virtio bus supports host notifiers. Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-10-30virtio: move ioeventfd_disabled flag to VirtioBusStatePaolo Bonzini
This simplifies the code and removes the ioeventfd_set_disabled callback. Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-10-30virtio: disable ioeventfd as early as possiblePaolo Bonzini
Avoid "tricking" virtio-blk-dataplane into thinking that ioeventfd will be available when it is not. This bug has always been there, but it will break TCG+ioeventfd=on once the dataplane code will be always used when ioeventfd=on. Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-10-30virtio/migration: Migrate balloon to VMStateDr. David Alan Gilbert
Replace the load/save with a vmsd. Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-10-30virtio/migration: Add VMStateDescription to VirtioDeviceClassDr. David Alan Gilbert
Provide a vmsd pointer for VirtIO devices to use instead of the load/save methods. We'll eventually kill off the load/save methods. Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-10-28Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-2.8-20161028' ↵Peter Maydell
into staging ppc patch queue 2016-10-28 This pull request supersedes and extends the one from 2016-10-26 (which had a build bug). Highlights: * SLOF (pseries guest firmware) update * Enable a number of extra testcases on ppc / pseries * Added the 'powernv' machine type - Almost enough to be minimally usable - But still missing necessary interrupt controller updates * Cleanup and consolidation of NVRAM handling on several platforms with related firmware * Substantial cleanup to device tree construction * Some more POWER9 instruction emulation * Cleanup to handling of pseries option vectors and CAS reboot handling (host/guest feature negotiation mechanism) * Significant cleanups to handling of PCI devices in test cases * New hotplug event infrastructure * Memory hot unplug support for pseries * Several bug fixes The NVRAM cleanup affects some Sun sparc platforms as well as ppc ones, but have been tested by the sparc maintainer (Mark Cave-Ayland). The test additions also include substantial general changes to the test framework that aren't strictly ppc related. They don't seem to break tests on other platforms, they're for the benefit of enabling tests on ppc and there isn't a specific maintainer for them, so they're included in this tree. # gpg: Signature made Fri 28 Oct 2016 02:37:19 BST # gpg: using RSA key 0x6C38CACA20D9B392 # gpg: Good signature from "David Gibson <david@gibson.dropbear.id.au>" # gpg: aka "David Gibson (Red Hat) <dgibson@redhat.com>" # gpg: aka "David Gibson (ozlabs.org) <dgibson@ozlabs.org>" # gpg: aka "David Gibson (kernel.org) <dwg@kernel.org>" # Primary key fingerprint: 75F4 6586 AE61 A66C C44E 87DC 6C38 CACA 20D9 B392 * remotes/dgibson/tags/ppc-for-2.8-20161028: (73 commits) ppc: allow certain HV interrupts to be delivered to guests spapr: Memory hot-unplug support spapr: use count+index for memory hotplug spapr: Add DRC count indexed hotplug identifier type spapr: add hotplug interrupt machine options spapr_events: add support for dedicated hotplug event source spapr: update spapr hotplug documentation target-ppc: Add xvcmpnesp, xvcmpnedp instructions target-ppc: add xscmp[eq,gt,ge,ne]dp instructions tests: Add pseries machine to the prom-env-test, too spapr_nvram: Pre-initialize the NVRAM to support the -prom-env parameter libqos: Change PCI accessors to take opaque BAR handle tests: Don't assume structure of PCI IO base in ahci-test tests: Use qpci_mem{read,write} in ivshmem-test libqos: Add 64-bit PCI IO accessors tests: Clean up IO handling in ide-test libqos: Implement mmio accessors in terms of mem{read,write} libqos: Add streaming accessors for PCI MMIO tests: Adjust tco-test to use qpci_legacy_iomap() libqos: Better handling of PCI legacy IO ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-10-28Merge remote-tracking branch 'remotes/jnsnow/tags/ide-pull-request' into stagingPeter Maydell
# gpg: Signature made Thu 27 Oct 2016 22:15:57 BST # gpg: using RSA key 0x7DEF8106AAFC390E # gpg: Good signature from "John Snow (John Huston) <jsnow@redhat.com>" # Primary key fingerprint: FAEB 9711 A12C F475 812F 18F2 88A9 064D 1835 61EB # Subkey fingerprint: F9B7 ABDB BCAC DF95 BE76 CBD0 7DEF 8106 AAFC 390E * remotes/jnsnow/tags/ide-pull-request: qemu-iotests: Test creating floppy drives fdc: Move qdev properties to FloppyDrive fdc: Add a floppy drive qdev fdc: Add a floppy qbus macio: switch over to new byte-aligned DMA helpers dma-helpers: explicitly pass alignment into DMA helpers Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-10-28Merge remote-tracking branch 'remotes/kraxel/tags/pull-vga-20161027-1' into ↵Peter Maydell
staging virtio-gpu: fix memory leak in virtio_gpu_resource_create_2d # gpg: Signature made Thu 27 Oct 2016 15:32:38 BST # gpg: using RSA key 0x4CB6D8EED3E87138 # gpg: Good signature from "Gerd Hoffmann (work) <kraxel@redhat.com>" # gpg: aka "Gerd Hoffmann <gerd@kraxel.org>" # gpg: aka "Gerd Hoffmann (private) <kraxel@gmail.com>" # Primary key fingerprint: A032 8CFF B93A 17A7 9901 FE7D 4CB6 D8EE D3E8 7138 * remotes/kraxel/tags/pull-vga-20161027-1: virtio-gpu: fix memory leak in virtio_gpu_resource_create_2d Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-10-28spapr: Memory hot-unplug supportBharata B Rao
Add support to hot remove pc-dimm memory devices. Since we're introducing a machine-level unplug_request hook, we also had handling for CPU unplug there as well to ensure CPU unplug continues to work as it did before. Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com> * add hooks to CAS/cmdline enablement of hotplug ACR support * add hook for CPU unplug Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2016-10-28spapr: use count+index for memory hotplugMichael Roth
Commit 0a417869: spapr: Move memory hotplug to RTAS_LOG_V6_HP_ID_DRC_COUNT type dropped per-DRC/per-LMB hotplugs event in favor of a bulk add via a single LMB count value. This was to avoid overrunning the guest EPOW event queue with hotplug events. This works fine, but relies on the guest exhaustively scanning for pluggable LMBs to satisfy the requested count by issuing rtas-get-sensor(DR_ENTITY_SENSE, ...) calls until all the LMBs associated with the DIMM are identified. With newer support for dedicated hotplug event source, this queue exhaustion is no longer as much of an issue due to implementation details on the guest side, but we still try to avoid excessive hotplug events by now supporting both a count and a starting index to avoid unecessary work. This patch makes use of that approach when the capability is available. Cc: bharata@linux.vnet.ibm.com Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2016-10-28spapr: Add DRC count indexed hotplug identifier typeBharata B Rao
Add support for DRC count indexed hotplug ID type which is primarily needed for memory hot unplug. This type allows for specifying the number of DRs that should be plugged/unplugged starting from a given DRC index. Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com> * updated rtas_event_log_v6_hp to reflect count/index field ordering used in PAPR hotplug ACR Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2016-10-28spapr: add hotplug interrupt machine optionsMichael Roth
This adds machine options of the form: -machine pseries,modern-hotplug-events=true -machine pseries,modern-hotplug-events=false If false, QEMU will force the use of "legacy" style hotplug events, which are surfaced through EPOW events instead of a dedicated hot plug event source, and lack certain features necessary, mainly, for memory unplug support. If true, QEMU will enable support for "modern" dedicated hot plug event source. Note that we will still default to "legacy" style unless the guest advertises support for the "modern" hotplug events via ibm,client-architecture-support hcall during early boot. For pseries-2.7 and earlier we default to false, for newer machine types we default to true. Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2016-10-28spapr_events: add support for dedicated hotplug event sourceMichael Roth
Hotplug events were previously delivered using an EPOW interrupt and were queued by linux guests into a circular buffer. For traditional EPOW events like shutdown/resets, this isn't an issue, but for hotplug events there are cases where this buffer can be exhausted, resulting in the loss of hotplug events, resets, etc. Newer-style hotplug event are delivered using a dedicated event source. We enable this in supported guests by adding standard an additional event source in the guest device-tree via /event-sources, and, if the guest advertises support for the newer-style hotplug events, using the corresponding interrupt to signal the available of hotplug/unplug events. Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2016-10-28spapr_nvram: Pre-initialize the NVRAM to support the -prom-env parameterThomas Huth
In case we do not load the NVRAM contents from a file and the user specified the "-prom-env" parameter, use the new CHRP NVRAM helper functions to pre-initialize the NVRAM partitions, so that the SLOF firmware now can pick up the environment variables from the -prom-env parameter, too. Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2016-10-28adb: change handler only when recognizedHervé Poussineau
ADB devices must take new handler into account only when they recognize it. This lets operating systems probe for valid/invalid handles, to know device capabilities. Add a FIXME in keyboard handler, which should use a different translation table depending of the selected handler. Signed-off-by: Hervé Poussineau <hpoussin@reactos.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2016-10-28spapr: improve ibm,architecture-vec-5 property handlingMichael Roth
ibm,architecture-vec-5 is supposed to encode all option vector 5 bits negotiated between platform/guest. Currently we hardcode this property in the boot-time device tree to advertise a single negotiated capability, "Form 1" NUMA Affinity, regardless of whether or not CAS has been invoked or that capability has actually been negotiated. Improve this by generating ibm,architecture-vec-5 based on the full set of option vector 5 capabilities negotiated via CAS. Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2016-10-28spapr: add option vector handling in CAS-generated resetsMichael Roth
In some cases, ibm,client-architecture-support calls can fail. This could happen in the current code for situations where the modified device tree segment exceeds the buffer size provided by the guest via the call parameters. In these cases, QEMU will reset, allowing an opportunity to regenerate the device tree from scratch via boot-time handling. There are potentially other scenarios as well, not currently reachable in the current code, but possible in theory, such as cases where device-tree properties or nodes need to be removed. We currently don't handle either of these properly for option vector capabilities however. Instead of carrying the negotiated capability beyond the reset and creating the boot-time device tree accordingly, we start from scratch, generating the same boot-time device tree as we did prior to the CAS-generated and the same device tree updates as we did before. This could (in theory) cause us to get stuck in a reset loop. This hasn't been observed, but depending on the extensiveness of CAS-induced device tree updates in the future, could eventually become an issue. Address this by pulling capability-related device tree updates resulting from CAS calls into a common routine, spapr_dt_cas_updates(), and adding an sPAPROptionVector* parameter that allows us to test for newly-negotiated capabilities. We invoke it as follows: 1) When ibm,client-architecture-support gets called, we call spapr_dt_cas_updates() with the set of capabilities added since the previous call to ibm,client-architecture-support. For the initial boot, or a system reset generated by something other than the CAS call itself, this set will consist of *all* options supported both the platform and the guest. For calls to ibm,client-architecture-support immediately after a CAS-induced reset, we call spapr_dt_cas_updates() with only the set of capabilities added since the previous call, since the other capabilities will have already been addressed by the boot-time device-tree this time around. In the unlikely event that capabilities are *removed* since the previous CAS, we will generate a CAS-induced reset. In the unlikely event that we cannot fit the device-tree updates into the buffer provided by the guest, well generate a CAS-induced reset. 2) When a CAS update results in the need to reset the machine and include the updates in the boot-time device tree, we call the spapr_dt_cas_updates() using the full set of negotiated capabilities as part of the reset path. At initial boot, or after a reset generated by something other than the CAS call itself, this set will be empty, resulting in what should be the same boot-time device-tree as we generated prior to this patch. For CAS-induced reset, this routine will be called with the full set of capabilities negotiated by the platform/guest in the previous CAS call, which should result in CAS updates from previous call being accounted for in the initial boot-time device tree. Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> [dwg: Changed an int -> bool conversion to be more explicit] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2016-10-28spapr_hcall: use spapr_ovec_* interfaces for CAS optionsMichael Roth
Currently we access individual bytes of an option vector via ldub_phys() to test for the presence of a particular capability within that byte. Currently this is only done for the "dynamic reconfiguration memory" capability bit. If that bit is present, we pass a boolean value to spapr_h_cas_compose_response() to generate a modified device tree segment with the additional properties required to enable this functionality. As more capability bits are added, will would need to modify the code to add additional option vector accesses and extend the param list for spapr_h_cas_compose_response() to include similar boolean values for these parameters. Avoid this by switching to spapr_ovec_* helpers so we can do all the parsing in one shot and then test for these additional bits within spapr_h_cas_compose_response() directly. Cc: Bharata B Rao <bharata@linux.vnet.ibm.com> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Bharata B Rao <bharata@linux.vnet.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2016-10-28spapr_ovec: initial implementation of option vector helpersMichael Roth
PAPR guests advertise their capabilities to the platform by passing an ibm,architecture-vec structure via an ibm,client-architecture-support hcall as described by LoPAPR v11, B.6.2.3. during early boot. Using this information, the platform enables the capabilities it supports, then encodes a subset of those enabled capabilities (the 5th option vector of the ibm,architecture-vec structure passed to ibm,client-architecture-support) into the guest device tree via "/chosen/ibm,architecture-vec-5". The logical format of these these option vectors is a bit-vector, where individual bits are addressed/documented based on the byte-wise offset from the beginning of the bit-vector, followed by the bit-wise index starting from the byte-wise offset. Thus the bits of each of these bytes are stored in reverse order. Additionally, the first byte of each option vector is encodes the length of the option vector, so byte offsets begin at 1, and bit offset at 0. This is not very intuitive for the purposes of mapping these bits to a particular documented capability, so this patch introduces a set of abstractions that encapsulate the work of parsing/encoding these options vectors and testing for individual capabilities. Cc: Bharata B Rao <bharata@linux.vnet.ibm.com> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> [dwg: Tweaked double-include protection to not trigger a checkpatch false positive] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2016-10-28pseries: Remove spapr_create_fdt_skel()David Gibson
For historical reasons construction of the guest device tree in spapr is divided between spapr_create_fdt_skel() which is called at init time, and spapr_build_fdt() which runs at reset time. Over time, more and more things have needed to be moved to reset time. Previous cleanups mean the only things left in spapr_create_fdt_skel() are the properties of the root node itself. Finish consolidating these two parts of device tree construction, by moving this to the start of spapr_build_fdt(), and removing spapr_create_fdt_skel() entirely. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2016-10-28pseries: Consolidate construction of /vdevice device tree nodeDavid Gibson
Construction of the /vdevice node (and its children) is divided between spapr_create_fdt_skel() (at init time), which creates the base node, and spapr_populate_vdevice() (at reset time) which creates the nodes for each individual virtual device. This consolidates both into a single function called from spapr_build_fdt(). Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2016-10-28pseries: Move /hypervisor node construction to fdt_build_fdt()David Gibson
Currently the /hypervisor device tree node is constructed in spapr_create_fdt_skel(). As part of consolidating device tree construction to reset time, move it to a function called from spapr_build_fdt(). Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2016-10-28pseries: Move /event-sources construction to spapr_build_fdt()David Gibson
The /event-sources device tree node is built from spapr_create_fdt_skel(). As part of consolidating device tree construction to reset time, this moves it to spapr_build_fdt(). Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2016-10-28pseries: Consolidate construction of /rtas device tree nodeDavid Gibson
For historical reasons construction of the /rtas node in the device tree (amongst others) is split into several places. In particular it's split between spapr_create_fdt_skel(), spapr_build_fdt() and spapr_rtas_device_tree_setup(). In fact, as well as adding the actual RTAS tokens to the device tree, spapr_rtas_device_tree_setup() just adds the ibm,lrdr-capacity property, which despite going in the /rtas node, doesn't have a lot to do with RTAS. This patch consolidates the code constructing /rtas together into a new spapr_dt_rtas() function. spapr_rtas_device_tree_setup() is renamed to spapr_dt_rtas_tokens() and now only adds the token properties. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Michael Roth <mdroth@linux.vnet.ibm.com>
generated by cgit v1.2.3 (git 2.26.2) at 2025-01-09 10:07:41 +0000