- 27 2月, 2020 1 次提交
-
-
由 Eric Auger 提交于
This patchs adds the skeleton for the virtio-iommu device. Signed-off-by: NEric Auger <eric.auger@redhat.com> Reviewed-by: NPeter Xu <peterx@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Message-Id: <20200214132745.23392-2-eric.auger@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
- 25 2月, 2020 2 次提交
-
-
由 Pan Nengyuan 提交于
use the new virtio_delete_queue function to cleanup. Signed-off-by: NPan Nengyuan <pannengyuan@huawei.com> Message-Id: <20200224041336.30790-3-pannengyuan@huawei.com> Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
由 Pan Nengyuan 提交于
use the new virtio_delete_queue function to cleanup. Signed-off-by: NPan Nengyuan <pannengyuan@huawei.com> Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com> Cc: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20200225075554.10835-3-pannengyuan@huawei.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
- 22 2月, 2020 1 次提交
-
-
由 Guenter Roeck 提交于
Instantiate EHCI and OHCI controllers on Allwinner A10. OHCI ports are modeled as companions of the respective EHCI ports. With this patch applied, USB controllers are discovered and instantiated when booting the cubieboard machine with a recent Linux kernel. ehci-platform 1c14000.usb: EHCI Host Controller ehci-platform 1c14000.usb: new USB bus registered, assigned bus number 1 ehci-platform 1c14000.usb: irq 26, io mem 0x01c14000 ehci-platform 1c14000.usb: USB 2.0 started, EHCI 1.00 ehci-platform 1c1c000.usb: EHCI Host Controller ehci-platform 1c1c000.usb: new USB bus registered, assigned bus number 2 ehci-platform 1c1c000.usb: irq 31, io mem 0x01c1c000 ehci-platform 1c1c000.usb: USB 2.0 started, EHCI 1.00 ohci-platform 1c14400.usb: Generic Platform OHCI controller ohci-platform 1c14400.usb: new USB bus registered, assigned bus number 3 ohci-platform 1c14400.usb: irq 27, io mem 0x01c14400 ohci-platform 1c1c400.usb: Generic Platform OHCI controller ohci-platform 1c1c400.usb: new USB bus registered, assigned bus number 4 ohci-platform 1c1c400.usb: irq 32, io mem 0x01c1c400 usb 2-1: new high-speed USB device number 2 using ehci-platform usb-storage 2-1:1.0: USB Mass Storage device detected scsi host1: usb-storage 2-1:1.0 usb 3-1: new full-speed USB device number 2 using ohci-platform input: QEMU QEMU USB Mouse as /devices/platform/soc/1c14400.usb/usb3/3-1/3-1:1.0/0003:0627:0001.0001/input/input0 Reviewed-by: NGerd Hoffmann <kraxel@redhat.com> Signed-off-by: NGuenter Roeck <linux@roeck-us.net> Tested-by: NNiek Linnenbank <nieklinnenbank@gmail.com> Message-id: 20200217204812.9857-4-linux@roeck-us.net Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
- 21 2月, 2020 5 次提交
-
-
由 Greg Kurz 提交于
We currently don't support hotplug of devices between boot and CAS. If this happens a CAS reboot is triggered. We detect this during CAS using the spapr_drc_needed() function which is essentially a VMStateDescription .needed callback. Even if the condition for CAS reboot happens to be the same as for DRC migration, it looks wrong to piggyback a migration helper for this. Introduce a helper with slightly more explicit name and use it in both CAS and DRC migration code. Since a subsequent patch will enhance this helper to cover the case of hot unplug, let's go for spapr_drc_transient(). While here convert spapr_hotplugged_dev_before_cas() to the "transient" wording as well. This doesn't change any behaviour. Signed-off-by: NGreg Kurz <groug@kaod.org> Message-Id: <158169248180.3465937.9531405453362718771.stgit@bahia.lan> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Alexey Kardashevskiy 提交于
This allows moving the kernel in the guest memory. The option is useful for step debugging (as Linux is linked at 0x0); it also allows loading grub which is normally linked to run at 0x20000. This uses the existing kernel address by default. Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru> Message-Id: <20200203032943.121178-6-aik@ozlabs.ru> Reviewed-by: NFabiano Rosas <farosas@linux.ibm.com> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Shivaprasad G Bhat 提交于
This patch implements few of the necessary hcalls for the nvdimm support. PAPR semantics is such that each NVDIMM device is comprising of multiple SCM(Storage Class Memory) blocks. The guest requests the hypervisor to bind each of the SCM blocks of the NVDIMM device using hcalls. There can be SCM block unbind requests in case of driver errors or unplug(not supported now) use cases. The NVDIMM label read/writes are done through hcalls. Since each virtual NVDIMM device is divided into multiple SCM blocks, the bind, unbind, and queries using hcalls on those blocks can come independently. This doesn't fit well into the qemu device semantics, where the map/unmap are done at the (whole)device/object level granularity. The patch doesnt actually bind/unbind on hcalls but let it happen at the device_add/del phase itself instead. The guest kernel makes bind/unbind requests for the virtual NVDIMM device at the region level granularity. Without interleaving, each virtual NVDIMM device is presented as a separate guest physical address range. So, there is no way a partial bind/unbind request can come for the vNVDIMM in a hcall for a subset of SCM blocks of a virtual NVDIMM. Hence it is safe to do bind/unbind everything during the device_add/del. Signed-off-by: NShivaprasad G Bhat <sbhat@linux.ibm.com> Message-Id: <158131059899.2897.11515211602702956854.stgit@lep8c.aus.stglabs.ibm.com> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Shivaprasad G Bhat 提交于
Add support for NVDIMM devices for sPAPR. Piggyback on existing nvdimm device interface in QEMU to support virtual NVDIMM devices for Power. Create the required DT entries for the device (some entries have dummy values right now). The patch creates the required DT node and sends a hotplug interrupt to the guest. Guest is expected to undertake the normal DR resource add path in response and start issuing PAPR SCM hcalls. The device support is verified based on the machine version unlike x86. This is how it can be used .. Ex : For coldplug, the device to be added in qemu command line as shown below -object memory-backend-file,id=memnvdimm0,prealloc=yes,mem-path=/tmp/nvdimm0,share=yes,size=1073872896 -device nvdimm,label-size=128k,uuid=75a3cdd7-6a2f-4791-8d15-fe0a920e8e9e,memdev=memnvdimm0,id=nvdimm0,slot=0 For hotplug, the device to be added from monitor as below object_add memory-backend-file,id=memnvdimm0,prealloc=yes,mem-path=/tmp/nvdimm0,share=yes,size=1073872896 device_add nvdimm,label-size=128k,uuid=75a3cdd7-6a2f-4791-8d15-fe0a920e8e9e,memdev=memnvdimm0,id=nvdimm0,slot=0 Signed-off-by: NShivaprasad G Bhat <sbhat@linux.ibm.com> Signed-off-by: NBharata B Rao <bharata@linux.ibm.com> [Early implementation] Message-Id: <158131058078.2897.12767731856697459923.stgit@lep8c.aus.stglabs.ibm.com> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Shivaprasad G Bhat 提交于
For ppc64, PAPR requires the nvdimm device to have UUID property set in the device tree. Add an option to get it from the user. Signed-off-by: NShivaprasad G Bhat <sbhat@linux.ibm.com> Reviewed-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NIgor Mammedov <imammedo@redhat.com> Message-Id: <158131056931.2897.14057087440721445976.stgit@lep8c.aus.stglabs.ibm.com> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
- 13 2月, 2020 2 次提交
-
-
由 Guenter Roeck 提交于
Initialize EHCI controllers on AST2400 and AST2500 using the existing TYPE_PLATFORM_EHCI. After this change, booting ast2500-evb into Linux successfully instantiates a USB interface. ehci-platform 1e6a3000.usb: EHCI Host Controller ehci-platform 1e6a3000.usb: new USB bus registered, assigned bus number 1 ehci-platform 1e6a3000.usb: irq 21, io mem 0x1e6a3000 ehci-platform 1e6a3000.usb: USB 2.0 started, EHCI 1.00 usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.05 usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: EHCI Host Controller Signed-off-by: NGuenter Roeck <linux@roeck-us.net> Reviewed-by: NCédric Le Goater <clg@kaod.org> Reviewed-by: NJoel Stanley <joel@jms.id.au> Reviewed-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20200206183437.3979-1-linux@roeck-us.net Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Roman Kapl 提交于
Uses the i.MX2 rudimentary watchdog driver. Signed-off-by: NRoman Kapl <rka@sysgo.com> Message-id: 20200207095529.11309-1-rka@sysgo.com Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> [PMM: removed accidental duplicate #include line] Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
- 11 2月, 2020 2 次提交
-
-
由 Anup Patel 提交于
We extend QEMU RISC-V virt machine by adding Goldfish RTC device to it. This will allow Guest Linux to sync it's local date/time with Host date/time via RTC device. Signed-off-by: NAnup Patel <anup.patel@wdc.com> Reviewed-by: NPalmer Dabbelt <palmer@sifive.com> Acked-by: NPalmer Dabbelt <palmer@sifive.com> Reviewed-by: NAlistair Francis <alistair.francis@wdc.com> Signed-off-by: NPalmer Dabbelt <palmerdabbelt@google.com>
-
由 Anup Patel 提交于
This patch adds model for Google Goldfish virtual platform RTC device. We will be adding Goldfish RTC device to the QEMU RISC-V virt machine for providing real date-time to Guest Linux. The corresponding Linux driver for Goldfish RTC device is already available in upstream Linux. For now, VM migration support is available but untested for Goldfish RTC device. It will be hardened in-future when we implement VM migration for KVM RISC-V. Signed-off-by: NAnup Patel <anup.patel@wdc.com> Reviewed-by: NAlistair Francis <alistair.francis@wdc.com> Signed-off-by: NPalmer Dabbelt <palmerdabbelt@google.com>
-
- 06 2月, 2020 1 次提交
-
-
由 Julia Suvorova 提交于
Signed-off-by: NJulia Suvorova <jusual@redhat.com> Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com> Message-Id: <20200205185123.210209-1-jusual@redhat.com> Signed-off-by: NLaurent Vivier <laurent@vivier.eu>
-
- 03 2月, 2020 5 次提交
-
-
由 Aravinda Prasad 提交于
This patch includes migration support for machine check handling. Especially this patch blocks VM migration requests until the machine check error handling is complete as these errors are specific to the source hardware and is irrelevant on the target hardware. Signed-off-by: NAravinda Prasad <arawinda.p@gmail.com> [Do not set FWNMI cap in post_load, now its done in .apply hook] Signed-off-by: NGanesh Goudar <ganeshgr@linux.ibm.com> Message-Id: <20200130184423.20519-7-ganeshgr@linux.ibm.com> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Aravinda Prasad 提交于
This patch adds support in QEMU to handle "ibm,nmi-register" and "ibm,nmi-interlock" RTAS calls. The machine check notification address is saved when the OS issues "ibm,nmi-register" RTAS call. This patch also handles the case when multiple processors experience machine check at or about the same time by handling "ibm,nmi-interlock" call. In such cases, as per PAPR, subsequent processors serialize waiting for the first processor to issue the "ibm,nmi-interlock" call. The second processor that also received a machine check error waits till the first processor is done reading the error log. The first processor issues "ibm,nmi-interlock" call when the error log is consumed. Signed-off-by: NAravinda Prasad <arawinda.p@gmail.com> [Register fwnmi RTAS calls in core_rtas_register_types() where other RTAS calls are registered] Signed-off-by: NGanesh Goudar <ganeshgr@linux.ibm.com> Message-Id: <20200130184423.20519-6-ganeshgr@linux.ibm.com> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Aravinda Prasad 提交于
Upon a machine check exception (MCE) in a guest address space, KVM causes a guest exit to enable QEMU to build and pass the error to the guest in the PAPR defined rtas error log format. This patch builds the rtas error log, copies it to the rtas_addr and then invokes the guest registered machine check handler. The handler in the guest takes suitable action(s) depending on the type and criticality of the error. For example, if an error is unrecoverable memory corruption in an application inside the guest, then the guest kernel sends a SIGBUS to the application. For recoverable errors, the guest performs recovery actions and logs the error. Signed-off-by: NAravinda Prasad <arawinda.p@gmail.com> [Assume SLOF has allocated enough room for rtas error log] Signed-off-by: NGanesh Goudar <ganeshgr@linux.ibm.com> Reviewed-by: NDavid Gibson <david@gibson.dropbear.id.au> Message-Id: <20200130184423.20519-5-ganeshgr@linux.ibm.com> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Aravinda Prasad 提交于
Memory error such as bit flips that cannot be corrected by hardware are passed on to the kernel for handling. If the memory address in error belongs to guest then the guest kernel is responsible for taking suitable action. Patch [1] enhances KVM to exit guest with exit reason set to KVM_EXIT_NMI in such cases. This patch handles KVM_EXIT_NMI exit. [1] https://www.spinics.net/lists/kvm-ppc/msg12637.html (e20bbd3d and related commits) Signed-off-by: NAravinda Prasad <arawinda.p@gmail.com> Signed-off-by: NGanesh Goudar <ganeshgr@linux.ibm.com> Reviewed-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NGreg Kurz <groug@kaod.org> Message-Id: <20200130184423.20519-4-ganeshgr@linux.ibm.com> [dwg: #ifdefs to fix compile for 32-bit target] Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Aravinda Prasad 提交于
Introduce fwnmi an spapr capability and add a helper function which tries to enable it, which would be used by following patch of the series. This patch by itself does not change the existing behavior. Signed-off-by: NAravinda Prasad <arawinda.p@gmail.com> [eliminate cap_ppc_fwnmi, add fwnmi cap to migration state and reprhase the commit message] Signed-off-by: NGanesh Goudar <ganeshgr@linux.ibm.com> Reviewed-by: NDavid Gibson <david@gibson.dropbear.id.au> Message-Id: <20200130184423.20519-3-ganeshgr@linux.ibm.com> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
- 02 2月, 2020 5 次提交
-
-
由 Cédric Le Goater 提交于
This is a model of the PCIe Host Bridge (PHB3) found on a POWER8 processor. It includes the PowerBus logic interface (PBCQ), IOMMU support, a single PCIe Gen.3 Root Complex, and support for MSI and LSI interrupt sources as found on a POWER8 system using the XICS interrupt controller. The POWER8 processor comes in different flavors: Venice, Murano, Naple, each having a different number of PHBs. To make things simpler, the models provides 3 PHB3 per chip. Some platforms, like the Firestone, can also couple PHBs on the first chip to provide more bandwidth but this is too specific to model in QEMU. XICS requires some adjustment to support the PHB3 MSI. The changes are provided here but they could be decoupled in prereq patches. Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: NCédric Le Goater <clg@kaod.org> Message-Id: <20200127144506.11132-3-clg@kaod.org> [dwg: Use device_class_set_props()] Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Benjamin Herrenschmidt 提交于
These changes introduces models for the PCIe Host Bridge (PHB4) of the POWER9 processor. It includes the PowerBus logic interface (PBCQ), IOMMU support, a single PCIe Gen.4 Root Complex, and support for MSI and LSI interrupt sources as found on a POWER9 system using the XIVE interrupt controller. POWER9 processor comes with 3 PHB4 PEC (PCI Express Controller) and each PEC can have several PHBs. By default, * PEC0 provides 1 PHB (PHB0) * PEC1 provides 2 PHBs (PHB1 and PHB2) * PEC2 provides 3 PHBs (PHB3, PHB4 and PHB5) Each PEC has a set "global" registers and some "per-stack" (per-PHB) registers. Those are organized in two XSCOM ranges, the "Nest" range and the "PCI" range, each range contains both some "PEC" registers and some "per-stack" registers. No default device layout is provided and PCI devices can be added on any of the available PCIe Root Port (pcie.0 .. 2 of a Power9 chip) with address 0x0 as the firwware (skiboot) only accepts a single device per root port. To run a simple system with a network and a storage adapters, use a command line options such as : -device e1000e,netdev=net0,mac=C0:FF:EE:00:00:02,bus=pcie.0,addr=0x0 -netdev bridge,id=net0,helper=/usr/libexec/qemu-bridge-helper,br=virbr0,id=hostnet0 -device megasas,id=scsi0,bus=pcie.1,addr=0x0 -drive file=$disk,if=none,id=drive-scsi0-0-0-0,format=qcow2,cache=none -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=2 If more are needed, include a bridge. Multi chip is supported, each chip adding its set of PHB4 controllers and its PCI busses. The model doesn't emulate the EEH error handling. This model is not ready for hotplug yet. Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org> [ clg: - numerous cleanups - commit log - fix for broken LSI support - PHB pic printinfo - large QOM rework ] Signed-off-by: NCédric Le Goater <clg@kaod.org> Message-Id: <20200127144506.11132-2-clg@kaod.org> [dwg: Use device_class_set_props()] Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Stefan Berger 提交于
For devices that cannot be statically initialized, implement a get_dt_compatible() callback that allows us to ask the device for the 'compatible' value. Signed-off-by: NStefan Berger <stefanb@linux.ibm.com> Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: NDavid Gibson <david@gibson.dropbear.id.au> Message-Id: <20200121152935.649898-3-stefanb@linux.ibm.com> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Cédric Le Goater 提交于
When the "hb-mode" option is activated on the powernv machine, the firmware is mapped at 0x8000000 and the HRMOR of the HW threads are set to the same address. The PNOR mapping on the FW address space of the LPC bus is left enabled to let the firmware load any other images required to boot the host. Signed-off-by: NCédric Le Goater <clg@kaod.org> Message-Id: <20200127144154.10170-4-clg@kaod.org> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Thomas Huth 提交于
It's been deprecated since QEMU v3.1. The 40p machine should be used nowadays instead. Reviewed-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Acked-by: NHervé Poussineau <hpoussin@reactos.org> Signed-off-by: NThomas Huth <thuth@redhat.com> Message-Id: <20200114114617.28854-1-thuth@redhat.com> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
- 31 1月, 2020 10 次提交
-
-
由 Andrew Jones 提交于
kvm-no-adjvtime is a KVM specific CPU property and a first of its kind. To accommodate it we also add kvm_arm_add_vcpu_properties() and a KVM specific CPU properties description to the CPU features document. Signed-off-by: NAndrew Jones <drjones@redhat.com> Message-id: 20200120101023.16030-7-drjones@redhat.com Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Damien Hedde 提交于
Deprecate device_legacy_reset(), qdev_reset_all() and qbus_reset_all() to be replaced by new functions device_cold_reset() and bus_cold_reset() which uses resettable API. Also introduce resettable_cold_reset_fn() which may be used as a replacement for qdev_reset_all_fn and qbus_reset_all_fn(). Following patches will be needed to look at legacy reset call sites and switch to resettable api. The legacy functions will be removed when unused. Signed-off-by: NDamien Hedde <damien.hedde@greensocs.com> Reviewed-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Tested-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20200123132823.1117486-9-damien.hedde@greensocs.com Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Damien Hedde 提交于
This commit make use of the resettable API to reset the device being hotplugged when it is realized. Also it ensures it is put in a reset state coherent with the parent it is plugged into. Note that there is a difference in the reset. Instead of resetting only the hotplugged device, we reset also its subtree (switch to resettable API). This is not expected to be a problem because sub-buses are just realized too. If a hotplugged device has any sub-buses it is logical to reset them too at this point. The recently added should_be_hidden and PCI's partially_hotplugged mechanisms do not interfere with realize operation: + In the should_be_hidden use case, device creation is delayed. + The partially_hotplugged mechanism prevents a device to be unplugged and unrealized from qdev POV and unrealized. Signed-off-by: NDamien Hedde <damien.hedde@greensocs.com> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Reviewed-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Tested-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20200123132823.1117486-8-damien.hedde@greensocs.com Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Damien Hedde 提交于
Add a function resettable_change_parent() to do the required plumbing when changing the parent a of Resettable object. We need to make sure that the reset state of the object remains coherent with the reset state of the new parent. We make the 2 following hypothesis: + when an object is put in a parent under reset, the object goes in reset. + when an object is removed from a parent under reset, the object leaves reset. The added function avoids any glitch if both old and new parent are already in reset. Signed-off-by: NDamien Hedde <damien.hedde@greensocs.com> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Reviewed-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Tested-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20200123132823.1117486-6-damien.hedde@greensocs.com Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Damien Hedde 提交于
This commit adds support of Resettable interface to buses and devices: + ResettableState structure is added in the Bus/Device state + Resettable methods are implemented. + device/bus_is_in_reset function defined This commit allows to transition the objects to the new multi-phase interface without changing the reset behavior at all. Object single reset method can be split into the 3 different phases but the 3 phases are still executed in a row for a given object. From the qdev/qbus reset api point of view, nothing is changed. qdev_reset_all() and qbus_reset_all() are not modified as well as device_legacy_reset(). Transition of an object must be done from parent class to child class. Care has been taken to allow the transition of a parent class without requiring the child classes to be transitioned at the same time. Note that SysBus and SysBusDevice class do not need any transition because they do not override the legacy reset method. Signed-off-by: NDamien Hedde <damien.hedde@greensocs.com> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Tested-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20200123132823.1117486-5-damien.hedde@greensocs.com Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Damien Hedde 提交于
This commit defines an interface allowing multi-phase reset. This aims to solve a problem of the actual single-phase reset (built in DeviceClass and BusClass): reset behavior is dependent on the order in which reset handlers are called. In particular doing external side-effect (like setting an qemu_irq) is problematic because receiving object may not be reset yet. The Resettable interface divides the reset in 3 well defined phases. To reset an object tree, all 1st phases are executed then all 2nd then all 3rd. See the comments in include/hw/resettable.h for a more complete description. The interface defines 3 phases to let the future possibility of holding an object into reset for some time. The qdev/qbus reset in DeviceClass and BusClass will be modified in following commits to use this interface. A mechanism is provided to allow executing a transitional reset handler in place of the 2nd phase which is executed in children-then-parent order inside a tree. This will allow to transition devices and buses smoothly while keeping the exact current qdev/qbus reset behavior for now. Documentation will be added in a following commit. Signed-off-by: NDamien Hedde <damien.hedde@greensocs.com> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Reviewed-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Tested-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20200123132823.1117486-4-damien.hedde@greensocs.com Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Damien Hedde 提交于
Provide a temporary device_legacy_reset function doing what device_reset does to prepare for the transition with Resettable API. All occurrence of device_reset in the code tree are also replaced by device_legacy_reset. The new resettable API has different prototype and semantics (resetting child buses as well as the specified device). Subsequent commits will make the changeover for each call site individually; once that is complete device_legacy_reset() will be removed. Signed-off-by: NDamien Hedde <damien.hedde@greensocs.com> Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Acked-by: NDavid Gibson <david@gibson.dropbear.id.au> Acked-by: NCornelia Huck <cohuck@redhat.com> Tested-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20200123132823.1117486-2-damien.hedde@greensocs.com Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Cédric Le Goater 提交于
The overhead for the OpenBMC firmware images using the a custom U-Boot is around 2 seconds, which is fine, but with a U-Boot from mainline, it takes an extra 50 seconds or so to reach Linux. A quick survey on the number of reads performed on the flash memory region gives the following figures : OpenBMC U-Boot 922478 (~ 3.5 MBytes) Mainline U-Boot 20569977 (~ 80 MBytes) QEMU must be trashing the TCG TBs and reloading text very often. Some addresses are read more than 250.000 times. Until we find a solution to improve boot time, execution from MMIO is not activated by default. Setting this option also breaks migration compatibility. Signed-off-by: NCédric Le Goater <clg@kaod.org> Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20200114103433.30534-5-clg@kaod.org Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Andrew Jeffery 提交于
Initialise another SDHCI model instance for the AST2600's eMMC controller and use the SDHCI's num_slots value introduced previously to determine whether we should create an SD card instance for the new slot. Signed-off-by: NAndrew Jeffery <andrew@aj.id.au> Reviewed-by: NCédric Le Goater <clg@kaod.org> Reviewed-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: NCédric Le Goater <clg@kaod.org> Message-id: 20200114103433.30534-3-clg@kaod.org [ clg : - removed ternary operator from sdhci_attach_drive() - renamed SDHCI objects with a '-controller' prefix ] Signed-off-by: NCédric Le Goater <clg@kaod.org> Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Andrew Jeffery 提交于
The AST2600 includes a second cut-down version of the SD/MMC controller found in the AST2500, named the eMMC controller. It's cut down in the sense that it only supports one slot rather than two, but it brings the total number of slots supported by the AST2600 to three. The existing code assumed that the SD controller always provided two slots. Rework the SDHCI object to expose the number of slots as a property to be set by the SoC configuration. Signed-off-by: NAndrew Jeffery <andrew@aj.id.au> Reviewed-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: NCédric Le Goater <clg@kaod.org> Signed-off-by: NCédric Le Goater <clg@kaod.org> Message-id: 20200114103433.30534-2-clg@kaod.org [PMM: fixed up to use device_class_set_props()] Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
- 30 1月, 2020 1 次提交
-
-
由 Aleksandar Markovic 提交于
While loading the executable, some platforms (like AVR) need to detect CPU type that executable is built for - and, with this patch, this is enabled by reading the field 'e_flags' of the ELF header of the executable in question. The change expands functionality of the following functions: - load_elf() - load_elf_as() - load_elf_ram() - load_elf_ram_sym() The argument added to these functions is called 'pflags' and is of type 'uint32_t*' (that matches 'pointer to 'elf_word'', 'elf_word' being the type of the field 'e_flags', in both 32-bit and 64-bit variants of ELF header). Callers are allowed to pass NULL as that argument, and in such case no lookup to the field 'e_flags' will happen, and no information will be returned, of course. CC: Richard Henderson <rth@twiddle.net> CC: Peter Maydell <peter.maydell@linaro.org> CC: Edgar E. Iglesias <edgar.iglesias@gmail.com> CC: Michael Walle <michael@walle.cc> CC: Thomas Huth <huth@tuxfamily.org> CC: Laurent Vivier <laurent@vivier.eu> CC: Philippe Mathieu-Daudé <f4bug@amsat.org> CC: Aleksandar Rikalo <aleksandar.rikalo@rt-rk.com> CC: Aurelien Jarno <aurelien@aurel32.net> CC: Jia Liu <proljc@gmail.com> CC: David Gibson <david@gibson.dropbear.id.au> CC: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> CC: BALATON Zoltan <balaton@eik.bme.hu> CC: Christian Borntraeger <borntraeger@de.ibm.com> CC: Thomas Huth <thuth@redhat.com> CC: Artyom Tarasenko <atar4qemu@gmail.com> CC: Fabien Chouteau <chouteau@adacore.com> CC: KONRAD Frederic <frederic.konrad@adacore.com> CC: Max Filippov <jcmvbkbc@gmail.com> Reviewed-by: NAleksandar Rikalo <aleksandar.rikalo@rt-rk.com> Signed-off-by: NMichael Rolnik <mrolnik@gmail.com> Signed-off-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: NAleksandar Markovic <amarkovic@wavecomp.com> Message-Id: <1580079311-20447-24-git-send-email-aleksandar.markovic@rt-rk.com>
-
- 28 1月, 2020 2 次提交
-
-
由 Sven Schnelle 提交于
Signed-off-by: NSven Schnelle <svens@stackframe.org> Message-Id: <20191220211512.3289-5-svens@stackframe.org> Signed-off-by: NRichard Henderson <richard.henderson@linaro.org>
-
由 Helge Deller 提交于
LASI is a built-in multi-I/O chip which supports serial, parallel, network (Intel i82596 Apricot), sound and other functionalities. LASI has been used in many HP PARISC machines. This patch adds the necessary parts to allow Linux and HP-UX to detect LASI and the network card. Signed-off-by: NHelge Deller <deller@gmx.de> Signed-off-by: NSven Schnelle <svens@stackframe.org> Message-Id: <20191220211512.3289-3-svens@stackframe.org> Signed-off-by: NRichard Henderson <richard.henderson@linaro.org>
-
- 25 1月, 2020 3 次提交
-
-
由 Marc-André Lureau 提交于
Use class properties facilities to add properties to the class during device_class_set_props(). qdev_property_add_static() must be adapted as PropertyInfo now operates with classes (and not instances), so we must set_default_value() on the ObjectProperty, before calling its init() method on the object instance. Also, PropertyInfo.create() is now exclusively used for class properties. Fortunately, qdev_property_add_static() is only used in target/arm/cpu.c so far, which doesn't use "link" properties (that require create()). Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20200110153039.1379601-22-marcandre.lureau@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Paolo Bonzini 提交于
Ensure that conflicts in the future will cause a syntax error. Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Marc-André Lureau 提交于
The following patch will need to handle properties registration during class_init time. Let's use a device_class_set_props() setter. spatch --macro-file scripts/cocci-macro-file.h --sp-file ./scripts/coccinelle/qdev-set-props.cocci --keep-comments --in-place --dir . @@ typedef DeviceClass; DeviceClass *d; expression val; @@ - d->props = val + device_class_set_props(d, val) Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20200110153039.1379601-20-marcandre.lureau@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-