aboutsummaryrefslogtreecommitdiff
path: root/hw/ppc
AgeCommit message (Collapse)AuthorFilesLines
2019-03-12PPC: E500: Add FSL I2C controller and integrate RTC with itAndrew Randrianasulu1-0/+54
Original commit message: This patch adds an emulation model for i2c controller found on most of the FSL SoCs. It also integrates the RTC (ds1338) that sits on the i2c Bus with e500 machine model. Patch was originally written by Amit Singh Tomar <amit.tomar@freescale.com> see http://patchwork.ozlabs.org/patch/431475/ I only fixed it enough for application on top of current qemu master 20b084c4b1401b7f8fbc385649d48c67b6f43d44, and hopefully fixed checkpatch errors Tested by booting Linux kernel 4.20.12. Now e500 machine doesn't need network time protocol daemon because it will have working RTC (before all timestamps on files were from 2016) Signed-off-by: Amit Singh Tomar <amit.tomar@freescale.com> Signed-off-by: Andrew Randrianasulu <randrianasulu@gmail.com> Message-Id: <20190306102812.28972-1-randrianasulu@gmail.com> [dwg: Add Kconfig stanza to define the new symbol, update MAINTAINERS] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-12target/ppc/spapr: Enable H_PAGE_INIT in-kernel handlingSuraj Jitindar Singh1-0/+3
The H_CALL H_PAGE_INIT can be used to zero or copy a page of guest memory. Enable the in-kernel H_PAGE_INIT handler. The in-kernel handler takes half the time to complete compared to handling the H_CALL in userspace. Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com> Message-Id: <20190306060608.19935-1-sjitindarsingh@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-12target/ppc/spapr: Clear partition table entry when allocating hash tableSuraj Jitindar Singh2-4/+9
If we allocate a hash page table then we know that the guest won't be using process tables, so set the partition table entry maintained for the guest to zero. If this isn't done, then the guest radix bit will remain set in the entry. This means that when the guest calls H_REGISTER_PROCESS_TABLE there will be a mismatch between then flags and the value in spapr->patb_entry, and the call will fail. The guest will then panic: Failed to register process table (rc=-4) kernel BUG at arch/powerpc/platforms/pseries/lpar.c:959 The result being that it isn't possible to boot a hash guest on a P9 system. Also fix a bug in the flags parsing in h_register_process_table() which was introduced by the same patch, and simplify the handling to make it less likely that errors will be introduced in the future. The effect would have been setting the host radix bit LPCR_HR for a hash guest using process tables, which currently isn't supported and so couldn't have been triggered. Fixes: 00fd075e18 "target/ppc/spapr: Set LPCR:HR when using Radix mode" Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com> Message-Id: <20190305022102.17610-1-sjitindarsingh@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-12target/ppc/spapr: Enable mitigations by default for pseries-4.0 machine typeSuraj Jitindar Singh1-3/+6
There are currently 3 mitigations the availability of which is controlled by the spapr-caps mechanism, cap-cfpc, cap-sbbc, and cap-ibs. Enable these mitigations by default for the pseries-4.0 machine type. By now machine firmware should have been upgraded to allow these settings. Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com> Message-Id: <20190301044609.9626-3-sjitindarsingh@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-12target/ppc/tcg: make spapr_caps apply cap-[cfpc/sbbc/ibs] non-fatal for tcgSuraj Jitindar Singh1-9/+26
The spapr_caps cap-cfpc, cap-sbbc and cap-ibs are used to control the availability of certain mitigations to the guest. These haven't been implemented under TCG, it is unlikely they ever will be, and it is unclear as to whether they even need to be. As such, make failure to apply these capabilities under TCG non-fatal. Instead we print a warning message to the user but still allow the guest to continue. Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com> Message-Id: <20190301044609.9626-2-sjitindarsingh@gmail.com> [dwg: Small style fix] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-12target/ppc/spapr: Add SPAPR_CAP_CCF_ASSISTSuraj Jitindar Singh3-0/+32
Introduce a new spapr_cap SPAPR_CAP_CCF_ASSIST to be used to indicate the requirement for a hw-assisted version of the count cache flush workaround. The count cache flush workaround is a software workaround which can be used to flush the count cache on context switch. Some revisions of hardware may have a hardware accelerated flush, in which case the software flush can be shortened. This cap is used to set the availability of such hardware acceleration for the count cache flush routine. The availability of such hardware acceleration is indicated by the H_CPU_CHAR_BCCTR_FLUSH_ASSIST flag being set in the characteristics returned from the KVM_PPC_GET_CPU_CHAR ioctl. Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com> Message-Id: <20190301031912.28809-2-sjitindarsingh@gmail.com> [dwg: Small style fixes] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-12target/ppc/spapr: Add workaround option to SPAPR_CAP_IBSSuraj Jitindar Singh2-11/+15
The spapr_cap SPAPR_CAP_IBS is used to indicate the level of capability for mitigations for indirect branch speculation. Currently the available values are broken (default), fixed-ibs (fixed by serialising indirect branches) and fixed-ccd (fixed by diabling the count cache). Introduce a new value for this capability denoted workaround, meaning that software can work around the issue by flushing the count cache on context switch. This option is available if the hypervisor sets the H_CPU_BEHAV_FLUSH_COUNT_CACHE flag in the cpu behaviours returned from the KVM_PPC_GET_CPU_CHAR ioctl. Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com> Message-Id: <20190301031912.28809-1-sjitindarsingh@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-12target/ppc/spapr: Enable the large decrementer for pseries-4.0Suraj Jitindar Singh2-1/+7
Enable the large decrementer by default for the pseries-4.0 machine type. It is disabled again by default_caps_with_cpu() for pre-POWER9 cpus since they don't support the large decrementer. Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com> Message-Id: <20190301024317.22137-4-sjitindarsingh@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-12target/ppc: Implement large decrementer support for KVMSuraj Jitindar Singh1-3/+19
Implement support to allow KVM guests to take advantage of the large decrementer introduced on POWER9 cpus. To determine if the host can support the requested large decrementer size, we check it matches that specified in the ibm,dec-bits device-tree property. We also need to enable it in KVM by setting the LPCR_LD bit in the LPCR. Note that to do this we need to try and set the bit, then read it back to check the host allowed us to set it, if so we can use it but if we were unable to set it the host cannot support it and we must not use the large decrementer. Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20190301024317.22137-3-sjitindarsingh@gmail.com> [dwg: Small style fixes] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-12target/ppc: Implement large decrementer support for TCGSuraj Jitindar Singh3-27/+103
Prior to POWER9 the decrementer was a 32-bit register which decremented with each tick of the timebase. From POWER9 onwards the decrementer can be set to operate in a mode called large decrementer where it acts as a n-bit decrementing register which is visible as a 64-bit register, that is the value of the decrementer is sign extended to 64 bits (where n is implementation dependant). The mode in which the decrementer operates is controlled by the LPCR_LD bit in the logical paritition control register (LPCR). >From POWER9 onwards the HDEC (hypervisor decrementer) was enlarged to h-bits, also sign extended to 64 bits (where h is implementation dependant). Note this isn't configurable and is always enabled. On POWER9 the large decrementer and hdec are both 56 bits, as represented by the lrg_decr_bits cpu class property. Since they are the same size we only add one property for now, which could be extended in the case they ever differ in the future. We also add the lrg_decr_bits property for POWER5+/7/8 since it is used to determine the size of the hdec, which is only generated on the POWER5+ processor and later. On these processors it is 32 bits. Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20190301024317.22137-2-sjitindarsingh@gmail.com> [dwg: Small style fixes] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-12target/ppc/spapr: Add SPAPR_CAP_LARGE_DECREMENTERSuraj Jitindar Singh2-0/+20
Add spapr_cap SPAPR_CAP_LARGE_DECREMENTER to be used to control the availability of the large decrementer for a guest. Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com> Message-Id: <20190301024317.22137-1-sjitindarsingh@gmail.com> [dwg: Trivial style fix] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-12Revert "spapr: support memory unplug for qtest"Greg Kurz1-6/+0
Commit b8165118f52c broke CPU hotplug tests for old machine types: $ QTEST_QEMU_BINARY=ppc64-softmmu/qemu-system-ppc64 ./tests/cpu-plug-test -m=slow /ppc64/cpu-plug/pseries-3.1/device-add/2x3x1&maxcpus=6: OK /ppc64/cpu-plug/pseries-2.12-sxxm/device-add/2x3x1&maxcpus=6: OK /ppc64/cpu-plug/pseries-3.0/device-add/2x3x1&maxcpus=6: OK /ppc64/cpu-plug/pseries-2.10/device-add/2x3x1&maxcpus=6: OK /ppc64/cpu-plug/pseries-2.11/device-add/2x3x1&maxcpus=6: OK /ppc64/cpu-plug/pseries-2.12/device-add/2x3x1&maxcpus=6: OK /ppc64/cpu-plug/pseries-2.9/device-add/2x3x1&maxcpus=6: OK /ppc64/cpu-plug/pseries-2.7/device-add/2x3x1&maxcpus=6: ** ERROR:/home/thuth/devel/qemu/hw/ppc/spapr_events.c:313:rtas_event_log_to_source: assertion failed: (source->enabled) Broken pipe /home/thuth/devel/qemu/tests/libqtest.c:143: kill_qemu() detected QEMU death from signal 6 (Aborted) (core dumped) Aborted (core dumped) The approach of faking the availability of OV5_HP_EVT causes the code to assume the hotplug event source is enabled, which is wrong for older machines. We've now fixed CAS under qtest with a different approach. Therefore, this reverts commit b8165118f52ce5ee88565d3cec83d30374efdc96. A subsequent patch will address the problem of CAS under qtest from a different angle. Reported-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <155146875097.147873.1732264036668112686.stgit@bahia.lan> Tested-by: Michael Roth <mdroth@linux.vnet.ibm.com> Reviewed-by: Michael Roth <mdroth@linux.vnet.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-12spapr: Simulate CAS for qtestGreg Kurz1-0/+11
The RTAS event hotplug code for machine types 2.8 and newer depends on the CAS negotiated ov5 in order to work properly. However, there's no CAS when running under qtest. There has been a tentative to trick the code by faking the OV5_HP_EVT bit, but it turned out to break other assumptions in the code and the change got reverted. Go for a more general approach and simulate a CAS when running under qtest. For simplicity, this pseudo CAS simple simulates the case where the guest supports the same features as the machine. It is done at reset time, just before we reset the DRCs, which could potentially exercise the unplug code. This allows to test unplug on spapr with both older and newer machine types. Suggested-by: Michael Roth <mdroth@linux.vnet.ibm.com> Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <155146875704.147873.10563808578795890265.stgit@bahia.lan> Tested-by: Michael Roth <mdroth@linux.vnet.ibm.com> Reviewed-by: Michael Roth <mdroth@linux.vnet.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-08Merge remote-tracking branch ↵Peter Maydell1-1/+0
'remotes/huth-gitlab/tags/pull-request-2019-03-08' into staging - qtest fixes - Some generic clean-ups by Philippe - macOS CI testing via cirrus-ci.com # gpg: Signature made Fri 08 Mar 2019 08:58:47 GMT # gpg: using RSA key 2ED9D774FE702DB5 # gpg: Good signature from "Thomas Huth <th.huth@gmx.de>" [full] # gpg: aka "Thomas Huth <thuth@redhat.com>" [full] # gpg: aka "Thomas Huth <huth@tuxfamily.org>" [full] # gpg: aka "Thomas Huth <th.huth@posteo.de>" [unknown] # Primary key fingerprint: 27B8 8847 EEE0 2501 18F3 EAB9 2ED9 D774 FE70 2DB5 * remotes/huth-gitlab/tags/pull-request-2019-03-08: cirrus.yml: Add macOS continuous integration task tests/bios-tables: Improve portability by searching bash in the $PATH vhost-user-test: fix leaks tests: Do not use "\n" in g_test_message() strings hw/devices: Remove unused TC6393XB_RAM definition hw: Remove unused 'hw/devices.h' include tests: Move qdict-test-data.txt to tests/data/qobject/ Signed-off-by: Peter Maydell <peter.maydell@linaro.org> # Conflicts: # tests/vhost-user-test.c
2019-03-07hw: Remove unused 'hw/devices.h' includePhilippe Mathieu-Daudé1-1/+0
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: BALATON Zoltan <balaton@eik.bme.hu> Tested-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2019-03-07ppc: Express dependencies of the embedded machines with kconfigThomas Huth1-0/+19
This makes it much easier if the users want to disable some of the embedded machines for their builds. Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-03-07ppc: Express dependencies of the Sam460EX machines with kconfigThomas Huth1-0/+11
Most of the dependencies are now directly selected by the SAM460EX switch. We can drop CONFIG_VGA_CIRRUS since this device is already selected automatically when CONFIG_PCI_DEVICES is set. Reviewed-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-03-07ppc: Express dependencies of the Mac machines with kconfigThomas Huth1-0/+15
This will make it for example easier if the users want to disable one of the two machines for their builds. Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-03-07ppc: Express dependencies of the 'prep' and '40p' machines with kconfigThomas Huth1-0/+10
Select the required devices in hw/ppc/Kconfig instead, so that ppc-softmmu.mak only contains the user-selectable PREP switch. Plug-in devices like NE2000_ISA are pulled in automatically by the Kconfig build system now. Cc: Hervé Poussineau <hpoussin@reactos.org> Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-03-07ppc64: Express dependencies of 'pseries' and 'powernv' machines with kconfigThomas Huth1-2/+20
The POWERNV switch should always select ISA_IPMI_BT, then the other IPMI options are turned on automatically now. CONFIG_DIMM should always be selected by the pseries machine, which in turn depends on CONFIG_MEM_DEVICE since DIMM implements this interface. CONFIG_VIRTIO_VGA can be dropped from default-configs/ppc64-softmmu.mak completely since this device is already automatically enabled via hw/display/Kconfig now. Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-03-07build: switch to KconfigPaolo Bonzini1-0/+4
The make_device_config.sh script is replaced by minikconf, which is modified to support the same command line as its predecessor. The roots of the parsing are default-configs/*.mak, Kconfig.host and hw/Kconfig. One difference with make_device_config.sh is that all symbols have to be defined in a Kconfig file, including those coming from the configure script. This is the reason for the Kconfig.host file introduced in the previous patch. Whenever a file in default-configs/*.mak used $(...) to refer to a config-host.mak symbol, this is replaced by a Kconfig dependency; this part must be done already in this patch for bisectability. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Yang Zhong <yang.zhong@intel.com> Acked-by: Thomas Huth <thuth@redhat.com> Message-Id: <20190123065618.3520-28-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-03-07kconfig: introduce kconfig filesPaolo Bonzini1-0/+44
The Kconfig files were generated mostly with this script: for i in `grep -ho CONFIG_[A-Z0-9_]* default-configs/* | sort -u`; do set fnord `git grep -lw $i -- 'hw/*/Makefile.objs' ` shift if test $# = 1; then cat >> $(dirname $1)/Kconfig << EOF config ${i#CONFIG_} bool EOF git add $(dirname $1)/Kconfig else echo $i $* fi done sed -i '$d' hw/*/Kconfig for i in hw/*; do if test -d $i && ! test -f $i/Kconfig; then touch $i/Kconfig git add $i/Kconfig fi done Whenever a symbol is referenced from multiple subdirectories, the script prints the list of directories that reference the symbol. These symbols have to be added manually to the Kconfig files. Kconfig.host and hw/Kconfig were created manually. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Yang Zhong <yang.zhong@intel.com> Message-Id: <20190123065618.3520-27-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-03-06qdev: Let the hotplug_handler_unplug() caller delete the deviceDavid Hildenbrand2-4/+8
When unplugging a device, at one point the device will be destroyed via object_unparent(). This will, one the one hand, unrealize the removed device hierarchy, and on the other hand, destroy/free the device hierarchy. When chaining hotplug handlers, we want to overwrite a bus hotplug handler by the machine hotplug handler, to be able to perform some part of the plug/unplug and to forward the calls to the bus hotplug handler. For now, the bus hotplug handler would trigger an object_unparent(), not allowing us to perform some unplug action on a device after we forwarded the call to the bus hotplug handler. The device would be gone at that point. machine_unplug_handler(dev) /* eventually do unplug stuff */ bus_unplug_handler(dev) /* dev is gone, we can't do more unplug stuff */ So move the object_unparent() to the original caller of the unplug. For now, keep the unrealize() at the original places of the object_unparent(). For implicitly chained hotplug handlers (e.g. pc code calling acpi hotplug handlers), the object_unparent() has to be done by the outermost caller. So when calling hotplug_handler_unplug() from inside an unplug handler, nothing is to be done. hotplug_handler_unplug(dev) -> calls machine_unplug_handler() machine_unplug_handler(dev) { /* eventually do unplug stuff */ bus_unplug_handler(dev) -> calls unrealize(dev) /* we can do more unplug stuff but device already unrealized */ } object_unparent(dev) In the long run, every unplug action should be factored out of the unrealize() function into the unplug handler (especially for PCI). Then we can get rid of the additonal unrealize() calls and object_unparent() will properly unrealize the device hierarchy after the device has been unplugged. hotplug_handler_unplug(dev) -> calls machine_unplug_handler() machine_unplug_handler(dev) { /* eventually do unplug stuff */ bus_unplug_handler(dev) -> only unplugs, does not unrealize /* we can do more unplug stuff */ } object_unparent(dev) -> will unrealize The original approach was suggested by Igor Mammedov for the PCI part, but I extended it to all hotplug handlers. I consider this one step into the right direction. To summarize: - object_unparent() on synchronous unplugs is done by common code -- "Caller of hotplug_handler_unplug" - object_unparent() on asynchronous unplugs ("unplug requests") has to be done manually -- "Caller of hotplug_handler_unplug" Reviewed-by: Igor Mammedov <imammedo@redhat.com> Acked-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20190228122849.4296-2-david@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2019-03-05hw/boards: Add a MachineState parameter to kvm_type callbackEric Auger3-4/+3
On ARM, the kvm_type will be resolved by querying the KVMState. Let's add the MachineState handle to the callback so that we can retrieve the KVMState handle. in kvm_init, when the callback is called, the kvm_state variable is not yet set. Signed-off-by: Eric Auger <eric.auger@redhat.com> Acked-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-id: 20190304101339.25970-5-eric.auger@redhat.com [ppc parts] Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-03-01Merge remote-tracking branch ↵Peter Maydell1-1/+1
'remotes/cminyard/tags/i2c-for-release-20190228' into staging This has been out there long enough, I need to get this in. This was changed a little bit since my post on Feb 20 (to which there were no comments) due to changes I had to work around: Change b296b664abc73253 "smbus: Add a helper to generate SPD EEPROM data" added a function to include/hw/i2c/smbus.h, which I had to move to include/hw/smbus_eeprom.h. There were some changes to hw/i2c/Makefile.objs that I had to fix up. Beyond that, no changes. Thanks, -corey # gpg: Signature made Thu 28 Feb 2019 18:05:49 GMT # gpg: using RSA key FD0D5CE67CE0F59A6688268661F38C90919BFF81 # gpg: Good signature from "Corey Minyard <cminyard@mvista.com>" [unknown] # gpg: aka "Corey Minyard <minyard@acm.org>" [unknown] # gpg: aka "Corey Minyard <corey@minyard.net>" [unknown] # gpg: aka "Corey Minyard <minyard@mvista.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: FD0D 5CE6 7CE0 F59A 6688 2686 61F3 8C90 919B FF81 * remotes/cminyard/tags/i2c-for-release-20190228: i2c: Verify that the count passed in to smbus_eeprom_init() is valid i2c:smbus_eeprom: Add a reset function to smbus_eeprom i2c:smbus_eeprom: Add vmstate handling to the smbus eeprom i2c:smbus_eeprom: Add a size constant for the smbus_eeprom size i2c:smbus_eeprom: Add normal type name and cast to smbus_eeprom.c i2c:smbus_slave: Add an SMBus vmstate structure i2c:pm_smbus: Fix state transfer migration: Add a VMSTATE_BOOL_TEST() macro i2c:pm_smbus: Fix pm_smbus handling of I2C block read boards.h: Ignore migration for SMBus devices on older machines i2c:smbus: Make white space in switch statements consistent i2c:smbus_eeprom: Get rid of the quick command i2c:smbus: Simplify read handling i2c:smbus: Simplify write operation i2c:smbus: Correct the working of quick commands i2c: Don't check return value from i2c_recv() arm:i2c: Don't mask return from i2c_recv() i2c: have I2C receive operation return uint8_t i2c: Split smbus into parts Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-02-27i2c: Split smbus into partsCorey Minyard1-1/+1
smbus.c and smbus.h had device side code, master side code, and smbus.h has some smbus_eeprom.c definitions. Split them into separate files. Signed-off-by: Corey Minyard <cminyard@mvista.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2019-02-26ppc/pnv: use IEC binary prefixes to represent sizesMurilo Opsfelder Araujo1-2/+2
Using IEC binary prefixes from qemu/units.h provides a more human-friendly value to size constants. Suggested-by: Eric Blake <eblake@redhat.com> Signed-off-by: Murilo Opsfelder Araujo <muriloo@linux.ibm.com> Message-Id: <20190225170155.1972-4-muriloo@linux.ibm.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-02-26ppc/pnv: add INITRD_MAX_SIZE constantMurilo Opsfelder Araujo1-1/+2
The current 0x10000000 value is actually 256MiB, not 128MB as the comment suggests. Move it to a constant and fix the comment (no change in the size value). Signed-off-by: Murilo Opsfelder Araujo <muriloo@linux.ibm.com> Message-Id: <20190225170155.1972-3-muriloo@linux.ibm.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-02-26ppc/pnv: increase kernel size limit to 256MiBMurilo Opsfelder Araujo1-1/+2
Building kernel with CONFIG_DEBUG_INFO_REDUCED can generate a ~90MB image and building with CONFIG_DEBUG_INFO can generate a ~225M one, both exceeds the current limit of 32MiB. Increasing kernel size limit to 256MiB should fit for now. Signed-off-by: Murilo Opsfelder Araujo <muriloo@linux.ibm.com> Message-Id: <20190225170155.1972-2-muriloo@linux.ibm.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-02-26hw/ppc: Use object_initialize_child for correct reference countingThomas Huth3-11/+11
Both functions, object_initialize() and object_property_add_child() increase the reference counter of the new object, so one of the references has to be dropped afterwards to get the reference counting right. Otherwise the child object will not be properly cleaned up when the parent gets destroyed. Thus let's use now object_initialize_child() instead to get the reference counting here right. Suggested-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <1550748288-30598-1-git-send-email-thuth@redhat.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-02-26spapr: enable PHB hotplug for default pseries machine typeMichael Roth1-0/+2
The 'dr_phb_enabled' field of that class can be set as part of machine-specific init code. It will be used to conditionally enable creation of DRC objects and device-tree description to facilitate hotplug of PHBs. Since we can't migrate this state to older machine types, default the option to true and disable it for older machine types. Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <155059673433.1466090.6188091133769611501.stgit@bahia.lab.toulouse-stg.fr.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-02-26spapr: add hotplug hooks for PHB hotplugGreg Kurz3-16/+130
Hotplugging PHBs is a machine-level operation, but PHBs reside on the main system bus, so we register spapr machine as the handler for the main system bus. Provide the usual pre-plug, plug and unplug-request handlers. Move the checking of the PHB index to the pre-plug handler. It is okay to do that and assert in the realize function because the pre-plug handler is always called, even for the oldest machine types we support. Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> (Fixed interrupt controller phandle in "interrupt-map" and TCE table size in "ibm,dma-window" FDT fragment, Greg Kurz) Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <155059672926.1466090.13612804072190051439.stgit@bahia.lab.toulouse-stg.fr.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-02-26spapr_pci: add ibm, my-drc-index property for PHB hotplugMichael Roth1-0/+9
This is needed to denote a boot-time PHB as being hot-pluggable. Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <155059672420.1466090.15147504040270659866.stgit@bahia.lab.toulouse-stg.fr.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-02-26spapr_pci: provide node start offset via spapr_populate_pci_dt()Michael Roth2-2/+5
PHB hotplug re-uses PHB device tree generation code and passes it to a guest via RTAS. Doing this requires knowledge of where exactly in the device tree the node describing the PHB begins. Provide this via a new optional pointer that can be used to store the PHB node's start offset. Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <155059671912.1466090.10891589403973703473.stgit@bahia.lab.toulouse-stg.fr.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-02-26spapr_events: add support for phb hotplug eventsMichael Roth1-0/+3
Extend the existing EPOW event format we use for PCI devices to emit PHB plug/unplug events. Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <155059671405.1466090.535964535260503283.stgit@bahia.lab.toulouse-stg.fr.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-02-26spapr: populate PHB DRC entries for root DT nodeNathan Fontenot1-0/+8
This add entries to the root OF node to advertise our PHBs as being DR-capable in accordance with PAPR specification. Signed-off-by: Nathan Fontenot <nfont@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: Greg Kurz <groug@kaod.org> Message-Id: <155059670897.1466090.10843921337591637414.stgit@bahia.lab.toulouse-stg.fr.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-02-26spapr: create DR connectors for PHBsMichael Roth2-0/+30
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <155059670389.1466090.10015601248906623076.stgit@bahia.lab.toulouse-stg.fr.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-02-26spapr_pci: add PHB unrealizeGreg Kurz1-4/+82
To support PHB hotplug we need to clean up lingering references, memory, child properties, etc. prior to the PHB object being finalized. Generally this will be called as a result of calling object_unparent() on the PHB object, which in turn would normally be called as the result of an unplug() operation. When the PHB is finalized, child objects will be unparented in turn, and finalized if the PHB was the only reference holder. so we don't bother to explicitly unparent child objects of the PHB, with the notable exception of DRCs. This is needed to avoid a QEMU crash when unplugging a PHB and resetting the machine before the guest could handle the event. The DRCs are removed from the QOM tree by pci_unregister_root_bus() and we must make sure we're not leaving stale aliases under the global /dr-connector path. The formula that gives the number of DMA windows is moved to an inline function in the hw/pci-host/spapr.h header because it will have other users. The unrealize function is able to cope with partially realized PHBs. It is hence used to implement proper rollback on the realize error path. Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <155059669881.1466090.13515030705986041517.stgit@bahia.lab.toulouse-stg.fr.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-02-26spapr_irq: Expose the phandle of the interrupt controllerGreg Kurz1-0/+21
This will be used by PHB hotplug in order to create the "interrupt-map" property of the PHB node. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <155059669374.1466090.12943228478046223856.stgit@bahia.lab.toulouse-stg.fr.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-02-26spapr: Expose the name of the interrupt controller nodeGreg Kurz1-1/+20
This will be needed by PHB hotplug in order to access the "phandle" property of the interrupt controller node. Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <155059668867.1466090.6339199751719123386.stgit@bahia.lab.toulouse-stg.fr.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-02-26spapr/drc: Drop spapr_drc_attach() fdt argumentGreg Kurz3-15/+4
All DRC subtypes have been converted to generate the FDT fragment at configure connector time instead of attach time. The fdt and fdt_offset arguments of spapr_drc_attach() aren't needed anymore. Drop them and make the implementation of the dt_populate() method mandatory. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <155059667853.1466090.16527852453054217565.stgit@bahia.lab.toulouse-stg.fr.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-02-26spapr/pci: Generate FDT fragment at configure connector timeGreg Kurz2-7/+13
Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <155059667346.1466090.326696113231137772.stgit@bahia.lab.toulouse-stg.fr.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-02-26spapr: Generate FDT fragment for CPUs at configure connector timeGreg Kurz2-29/+24
Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <155059666839.1466090.3833376527523126752.stgit@bahia.lab.toulouse-stg.fr.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-02-26spapr: Generate FDT fragment for LMBs at configure connector timeGreg Kurz2-15/+19
Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <155059666331.1466090.6766540766297333313.stgit@bahia.lab.toulouse-stg.fr.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-02-26spapr_drc: Allow FDT fragment to be added laterGreg Kurz1-5/+31
The current logic is to provide the FDT fragment when attaching a device to a DRC. This works perfectly fine for our current hotplug support, but soon we will add support for PHB hotplug which has some constraints, that CPU, PCI and LMB devices don't seem to have. The first constraint is that the "ibm,dma-window" property of the PHB node requires the IOMMU to be configured, ie, spapr_tce_table_enable() has been called, which happens during PHB reset. It is okay in the case of hotplug since the device is reset before the hotplug handler is called. On the contrary with coldplug, the hotplug handler is called first and device is only reset during the initial system reset. Trying to create the FDT fragment on the hotplug path in this case, would result in somthing like this: ibm,dma-window = < 0x80000000 0x00 0x00 0x00 0x00 >; This will cause linux in the guest to panic, by simply removing and re-adding the PHB using the drmgr command: page = alloc_pages_node(nid, GFP_KERNEL, get_order(sz)); if (!page) panic("iommu_init_table: Can't allocate %ld bytes\n", sz); The second and maybe more problematic constraint is that the "interrupt-map" property needs to reference the interrupt controller node using the very same phandle that SLOF has already exposed to the guest. QEMU requires SLOF to call the private KVMPPC_H_UPDATE_DT hcall at some point to know about this phandle. With the latest QEMU and SLOF, this happens when SLOF gets quiesced. This means that if the PHB gets hotplugged after CAS but before SLOF quiesce, then we're sure that the phandle is not known when the hotplug handler is called. The FDT is only needed when the guest first invokes RTAS to configure the connector actually, long after SLOF quiesce. Let's postpone the creation of FDT fragments for PHBs to rtas_ibm_configure_connector(). Since we only need this for PHBs, introduce a new method in the base DRC class for that. DRC subtypes will be converted to use it in subsequent patches. Allow spapr_drc_attach() to be passed a NULL fdt argument if the method is available. When all DRC subtypes have been converted, the fdt argument will eventually disappear. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <155059665823.1466090.18358845122627355537.stgit@bahia.lab.toulouse-stg.fr.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-02-26target/ppc: Rename PATB/PATBE -> PATEBenjamin Herrenschmidt2-19/+27
That "b" means "base address" and thus shouldn't be in the name of actual entries and related constants. This patch keeps the synthetic patb_entry field of the spapr virtual hypervisor unchanged until I figure out if that has an impact on the migration stream. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20190215170029.15641-11-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-02-26target/ppc: Fix ordering of hash MMU accessesBenjamin Herrenschmidt1-2/+19
With mttcg, we can have MMU lookups happening at the same time as the guest modifying the page tables. Since the HPTEs of the hash table MMU contains two words (or double worlds on 64-bit), we need to make sure we read them in the right order, with the correct memory barrier. Additionally, when using emulated SPAPR mode, the hypercalls writing to the hash table must also perform the udpates in the right order. Note: This part is still not entirely correct Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20190215170029.15641-7-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-02-26target/ppc/spapr: Set LPCR:HR when using Radix modeBenjamin Herrenschmidt3-42/+51
The HW relies on LPCR:HR along with the PATE to determine whether to use Radix or Hash mode. In fact it uses LPCR:HR more commonly than the PATE. For us, it's also more efficient to do so, especially since unlike the HW we do not maintain a cache of the current PATE and HV PATE in a generic place. Prepare the grounds for that by ensuring that LPCR:HR is set properly on SPAPR machines. Another option would have been to use a callback to get the PATE but this gets messy when implementing bare metal support, it's much simpler (and faster) to use LPCR. Since existing migration streams may not have it, fix it up in spapr_post_load() as well based on the pseudo-PATE entry that we keep. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20190215170029.15641-2-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-02-26spapr: support memory unplug for qtestDavid Hildenbrand1-0/+6
Fake availability of OV5_HP_EVT, so we can test memory unplug in qtest. Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org> Acked-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20190218092202.26683-3-david@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-02-26ppc: add host-serial and host-model machine attributes (CVE-2019-8934)Prasad J Pandit1-6/+70
On ppc hosts, hypervisor shares following system attributes - /proc/device-tree/system-id - /proc/device-tree/model with a guest. This could lead to information leakage and misuse.[*] Add machine attributes to control such system information exposure to a guest. [*] https://wiki.openstack.org/wiki/OSSN/OSSN-0028 Reported-by: Daniel P. Berrangé <berrange@redhat.com> Fix-suggested-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org> Message-Id: <20190218181349.23885-1-ppandit@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
generated by cgit v1.1 at 2025-01-28 07:08:29 +0000