aboutsummaryrefslogtreecommitdiff
path: root/include
AgeCommit message (Collapse)Author
2020-03-17Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into stagingPeter Maydell
* Bugfixes all over the place * get/set_uint cleanups (Felipe) * Lock guard support (Stefan) * MemoryRegion ownership cleanup (Philippe) * AVX512 optimization for buffer_is_zero (Robert) # gpg: Signature made Tue 17 Mar 2020 15:01:54 GMT # gpg: using RSA key BFFBD25F78C7AE83 # gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>" [full] # gpg: aka "Paolo Bonzini <pbonzini@redhat.com>" [full] # Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4 E2F7 7E15 100C CD36 69B1 # Subkey fingerprint: F133 3857 4B66 2389 866C 7682 BFFB D25F 78C7 AE83 * remotes/bonzini/tags/for-upstream: (62 commits) hw/arm: Let devices own the MemoryRegion they create hw/arm: Remove unnecessary memory_region_set_readonly() on ROM alias hw/ppc/ppc405: Use memory_region_init_rom() with read-only regions hw/arm/stm32: Use memory_region_init_rom() with read-only regions hw/char: Let devices own the MemoryRegion they create hw/riscv: Let devices own the MemoryRegion they create hw/dma: Let devices own the MemoryRegion they create hw/display: Let devices own the MemoryRegion they create hw/core: Let devices own the MemoryRegion they create scripts/cocci: Patch to let devices own their MemoryRegions scripts/cocci: Patch to remove unnecessary memory_region_set_readonly() scripts/cocci: Patch to detect potential use of memory_region_init_rom hw/sparc: Use memory_region_init_rom() with read-only regions hw/sh4: Use memory_region_init_rom() with read-only regions hw/riscv: Use memory_region_init_rom() with read-only regions hw/ppc: Use memory_region_init_rom() with read-only regions hw/pci-host: Use memory_region_init_rom() with read-only regions hw/net: Use memory_region_init_rom() with read-only regions hw/m68k: Use memory_region_init_rom() with read-only regions hw/display: Use memory_region_init_rom() with read-only regions ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-03-17gdbstub: extend GByteArray to read register helpersAlex Bennée
Instead of passing a pointer to memory now just extend the GByteArray to all the read register helpers. They can then safely append their data through the normal way. We don't bother with this abstraction for write registers as we have already ensured the buffer being copied from is the correct size. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Acked-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Damien Hedde <damien.hedde@greensocs.com> Message-Id: <20200316172155.971-15-alex.bennee@linaro.org>
2020-03-17gdbstub: add helper for 128 bit registersAlex Bennée
Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20200316172155.971-11-alex.bennee@linaro.org>
2020-03-17hw/ide: Move MAX_IDE_DEVS define to hw/ide/internal.hBALATON Zoltan
We can move this define now that less files use it to internal.h to further reduce dependency on hw/ide.h. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-id: e68675d2f6252f229cf788b7cd163bb76fa3e26b.1584457537.git.balaton@eik.bme.hu Signed-off-by: John Snow <jsnow@redhat.com>
2020-03-17hw/ide: Do ide_drive_get() within pci_ide_create_devs()BALATON Zoltan
The pci_ide_create_devs() function takes a hd_table parameter but all callers just pass what ide_drive_get() returns so we can do it locally simplifying callers and removing hd_table parameter. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-id: e9713fdded4d212fa68ed03b844e531934226a6f.1584457537.git.balaton@eik.bme.hu Signed-off-by: John Snow <jsnow@redhat.com>
2020-03-17hw/ide: Remove now unneded #include "hw/pci/pci.h" from hw/ide.hBALATON Zoltan
After previous patches we don't need hw/pci/pci.h any more in hw/ide.h. Some files depended on implicit inclusion by this header which are also fixed up here. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-id: 444a5e34331bf1f7880541b8d46e0353f470f5a6.1584457537.git.balaton@eik.bme.hu Signed-off-by: John Snow <jsnow@redhat.com>
2020-03-17hw/ide: Get rid of piix4_init functionBALATON Zoltan
This removes pci_piix4_ide_init() function similar to clean up done to other ide devices. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-id: fe46b6536abbae77695f6d1c711a04a3f4b5481d.1584457537.git.balaton@eik.bme.hu Signed-off-by: John Snow <jsnow@redhat.com>
2020-03-17hw/ide: Get rid of piix3_init functionsBALATON Zoltan
This removes pci_piix3_ide_init() and pci_piix3_xen_ide_init() functions similar to clean up done to other ide devices. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-id: adddfa21552783020d64e1314318cab6d24362c3.1584457537.git.balaton@eik.bme.hu Signed-off-by: John Snow <jsnow@redhat.com>
2020-03-17lockable: add QemuRecMutex supportStefan Hajnoczi
The polymorphic locking macros don't support QemuRecMutex yet. Add it so that lock guards can be used with QemuRecMutex. Convert TCG plugins functions that benefit from these macros. Manual qemu_rec_mutex_lock/unlock() callers are left unmodified in cases where clarity would not improve by switching to the macros. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-17lockable: add lock guardsStefan Hajnoczi
This patch introduces two lock guard macros that automatically unlock a lock object (QemuMutex and others): void f(void) { QEMU_LOCK_GUARD(&mutex); if (!may_fail()) { return; /* automatically unlocks mutex */ } ... } and: WITH_QEMU_LOCK_GUARD(&mutex) { if (!may_fail()) { return; /* automatically unlocks mutex */ } } /* automatically unlocks mutex here */ ... Convert qemu-timer.c functions that benefit from these macros as an example. Manual qemu_mutex_lock/unlock() callers are left unmodified in cases where clarity would not improve by switching to the macros. Many other QemuMutex users remain in the codebase that might benefit from lock guards. Over time they can be converted, if that is desirable. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> [Use QEMU_MAKE_LOCKABLE_NONNULL. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-17lockable: add QEMU_MAKE_LOCKABLE_NONNULLPaolo Bonzini
This will be needed for lock guards, because if the lock is NULL the dummy for loop of the lock guard never runs. This can cause confusion and dummy warnings in the compiler, but even if it did not, aborting with a NULL pointer dereference is a less surprising behavior. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-17hw/arm/fsl-imx6: Wire up USB controllersGuenter Roeck
With this patch, the USB controllers on 'sabrelite' are detected and can be used to boot the system. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Message-id: 20200313014551.12554-6-linux@roeck-us.net Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-03-17hw/arm/fsl-imx6ul: Wire up USB controllersGuenter Roeck
IMX6UL USB controllers are quite similar to IMX7 USB controllers. Wire them up the same way. The only real difference is that wiring up phy devices is necessary to avoid phy reset timeouts in the Linux kernel. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Message-id: 20200313014551.12554-5-linux@roeck-us.net Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-03-17hw/arm/fsl-imx6ul: Fix USB interrupt numbersGuenter Roeck
USB1 and USB2 interrupt numbers were swapped. USB_PHY2 interrupt number is 45. That didn't really matter up to now since the interrupts were not used, but it needs to be fixed to be able to wire up the USB controllers. Fixes: 31cbf933f0e ("i.MX6UL: Add i.MX6UL SOC") Signed-off-by: Guenter Roeck <linux@roeck-us.net> Message-id: 20200313014551.12554-3-linux@roeck-us.net Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-03-17hw/usb: Add basic i.MX USB Phy supportGuenter Roeck
Add basic USB PHY support as implemented in i.MX23, i.MX28, i.MX6, and i.MX7 SoCs. The only support really needed - at least to boot Linux - is support for soft reset, which needs to reset various registers to their initial value. Otherwise, just record register values. Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Message-id: 20200313014551.12554-2-linux@roeck-us.net Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-03-17ppc/spapr: Add FWNMI System Reset stateNicholas Piggin
The FWNMI option must deliver system reset interrupts to their registered address, and there are a few constraints on the handler addresses specified in PAPR. Add the system reset address state and checks. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Message-Id: <20200316142613.121089-4-npiggin@gmail.com> Reviewed-by: Greg Kurz <groug@kaod.org> Reviwed-by: Mahesh Salgaonkar <mahesh@linux.ibm.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-03-17ppc/spapr: Change FWNMI namesNicholas Piggin
The option is called "FWNMI", and it involves more than just machine checks, also machine checks can be delivered without the FWNMI option, so re-name various things to reflect that. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Message-Id: <20200316142613.121089-3-npiggin@gmail.com> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-03-17spapr: Rename DT functions to newer naming conventionDavid Gibson
In the spapr code we've been gradually moving towards a convention that functions which create pieces of the device tree are called spapr_dt_*(). This patch speeds that along by renaming most of the things that don't yet match that so that they do. For now we leave the *_dt_populate() functions which are actual methods used in the DRCClass::dt_populate method. While we're there we remove a few comments that don't really say anything useful. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org>
2020-03-17spapr/rtas: Reserve space for RTAS blob and logAlexey Kardashevskiy
At the moment SLOF reserves space for RTAS and instantiates the RTAS blob which is 20 bytes binary blob calling an hypercall. The rest of the RTAS area is a log which SLOF has no idea about but QEMU does. This moves RTAS sizing to QEMU and this overrides the size from SLOF. The only remaining problem is that SLOF copies the number of bytes it reserved (2KB for now) so QEMU needs to reserve at least this much; SLOF will be fixed separately to check that rtas-size from QEMU is enough for those 20 bytes for the H_RTAS hcall. Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Message-Id: <20200316011841.99970-1-aik@ozlabs.ru> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-03-17ppc/spapr: Move GPRs setup to one placeAlexey Kardashevskiy
At the moment "pseries" starts in SLOF which only expects the FDT blob pointer in r3. As we are going to introduce a OpenFirmware support in QEMU, we will be booting OF clients directly and these expect a stack pointer in r1, Linux looks at r3/r4 for the initramdisk location (although vmlinux can find this from the device tree but zImage from distro kernels cannot). This extends spapr_cpu_set_entry_state() to take more registers. This should cause no behavioral change. Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Message-Id: <20200310050733.29805-2-aik@ozlabs.ru> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-03-16ide/via: Get rid of via_ide_init()BALATON Zoltan
Follow example of CMD646 and remove via_ide_init function and do it directly in board code instead. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Tested-by: BALATON Zoltan <balaton@eik.bme.hu> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Message-id: 20200313082444.2439-3-mark.cave-ayland@ilande.co.uk Signed-off-by: John Snow <jsnow@redhat.com>
2020-03-17spapr: Don't clamp RMA to 16GiB on new machine typesDavid Gibson
In spapr_machine_init() we clamp the size of the RMA to 16GiB and the comment saying why doesn't make a whole lot of sense. In fact, this was done because the real mode handling code elsewhere limited the RMA in TCG mode to the maximum value configurable in LPCR[RMLS], 16GiB. But, * Actually LPCR[RMLS] has been able to encode a 256GiB size for a very long time, we just didn't implement it properly in the softmmu * LPCR[RMLS] shouldn't really be relevant anyway, it only was because we used to abuse the RMOR based translation mode in order to handle the fact that we're not modelling the hypervisor parts of the cpu We've now removed those limitations in the modelling so the 16GiB clamp no longer serves a function. However, we can't just remove the limit universally: that would break migration to earlier qemu versions, where the 16GiB RMLS limit still applies, no matter how bad the reasons for it are. So, we replace the 16GiB clamp, with a clamp to a limit defined in the machine type class. We set it to 16 GiB for machine types 4.2 and earlier, but set it to 0 meaning unlimited for the new 5.0 machine type. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2020-03-17spapr: Don't attempt to clamp RMA to VRMA constraintDavid Gibson
The Real Mode Area (RMA) is the part of memory which a guest can access when in real (MMU off) mode. Of course, for a guest under KVM, the MMU isn't really turned off, it's just in a special translation mode - Virtual Real Mode Area (VRMA) - which looks like real mode in guest mode. The mechanics of how this works when using the hash MMU (HPT) put a constraint on the size of the RMA, which depends on the size of the HPT. So, the latter part of spapr_setup_hpt_and_vrma() clamps the RMA we advertise to the guest based on this VRMA limit. There are several things wrong with this: 1) spapr_setup_hpt_and_vrma() doesn't actually clamp, it takes the minimum of Node 0 memory size and the VRMA limit. That will *often* work the same as clamping, but there can be other constraints on RMA size which supersede Node 0 memory size. We have real bugs caused by this (currently worked around in the guest kernel) 2) Some callers of spapr_setup_hpt_and_vrma() are in a situation where we're past the point that we can actually advertise an RMA limit to the guest 3) But most fundamentally, the VRMA limit depends on host configuration (page size) which shouldn't be visible to the guest, but this partially exposes it. This can cause problems with migration in certain edge cases, although we will mostly get away with it. In practice, this clamping is almost never applied anyway. With 64kiB pages and the normal rules for sizing of the HPT, the theoretical VRMA limit will be 4x(guest memory size) and so never hit. It will hit with 4kiB pages, where it will be (guest memory size)/4. However all mainstream distro kernels for POWER have used a 64kiB page size for at least 10 years. So, simply replace this logic with a check that the RMA we've calculated based only on guest visible configuration will fit within the host implied VRMA limit. This can break if running HPT guests on a host kernel with 4kiB page size. As noted that's very rare. There also exist several possible workarounds: * Change the host kernel to use 64kiB pages * Use radix MMU (RPT) guests instead of HPT * Use 64kiB hugepages on the host to back guest memory * Increase the guest memory size so that the RMA hits one of the fixed limits before the RMA limit. This is relatively easy on POWER8 which has a 16GiB limit, harder on POWER9 which has a 1TiB limit. * Use a guest NUMA configuration which artificially constrains the RMA within the VRMA limit (the RMA must always fit within Node 0). Previously, on KVM, we also temporarily reduced the rma_size to 256M so that the we'd load the kernel and initrd safely, regardless of the VRMA limit. This was a) confusing, b) could significantly limit the size of images we could load and c) introduced a behavioural difference between KVM and TCG. So we remove that as well. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru> Reviewed-by: Greg Kurz <groug@kaod.org>
2020-03-17spapr: Handle pending hot plug/unplug requests at CASGreg Kurz
If a hot plug or unplug request is pending at CAS, we currently trigger a CAS reboot, which severely increases the guest boot time. This is because SLOF doesn't handle hot plug events and we had no way to fix the FDT that gets presented to the guest. We can do better thanks to recent changes in QEMU and SLOF: - we now return a full FDT to SLOF during CAS - SLOF was fixed to correctly detect any device that was either added or removed since boot time and to update its internal DT accordingly. The right solution is to process all pending hot plug/unplug requests during CAS: convert hot plugged devices to cold plugged devices and remove the hot unplugged ones, which is exactly what spapr_drc_reset() does. Also clear all hot plug events that are currently queued since they're no longer relevant. Note that SLOF cannot currently populate hot plugged PCI bridges or PHBs at CAS. Until this limitation is lifted, SLOF will reset the machine when this scenario occurs : this will allow the FDT to be fully processed when SLOF is started again (ie. the same effect as the CAS reboot that would occur anyway without this patch). Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <158257222352.4102917.8984214333937947307.stgit@bahia.lan> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-03-16qom/object: enable setter for uint typesFelipe Franciosi
Traditionally, the uint-specific property helpers only offer getters. When adding object (or class) uint types, one must therefore use the generic property helper if a setter is needed (and probably duplicate some code writing their own getters/setters). This enhances the uint-specific property helper APIs by adding a bitwise-or'd 'flags' field and modifying all clients of that API to set this paramater to OBJ_PROP_FLAG_READ. This maintains the current behaviour whilst allowing others to also set OBJ_PROP_FLAG_WRITE (or use the more convenient OBJ_PROP_FLAG_READWRITE) in the future (which will automatically install a setter). Other flags may be added later. Signed-off-by: Felipe Franciosi <felipe@nutanix.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16WHPX: TSC get and set should be dependent on VM stateSunil Muthuswamy
Currently, TSC is set as part of the VM runtime state. Setting TSC at runtime is heavy and additionally can have side effects on the guest, which are not very resilient to variances in the TSC. This patch uses the VM state to determine whether to set TSC or not. Some minor enhancements for getting TSC values as well that considers the VM state. Additionally, while setting the TSC, the partition is suspended to reduce the variance in the TSC value across vCPUs. Signed-off-by: Sunil Muthuswamy <sunilmut@microsoft.com> Message-Id: <SN4PR2101MB08804D23439166E81FF151F7C0EA0@SN4PR2101MB0880.namprd21.prod.outlook.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16util: add util function buffer_zero_avx512()Robert Hoo
And intialize buffer_is_zero() with it, when Intel AVX512F is available on host. This function utilizes Intel AVX512 fundamental instructions which is faster than its implementation with AVX2 (in my unit test, with 4K buffer, on CascadeLake SP, ~36% faster, buffer_zero_avx512() V.S. buffer_zero_avx2()). Signed-off-by: Robert Hoo <robert.hu@linux.intel.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16misc: Replace zero-length arrays with flexible array member (manual)Philippe Mathieu-Daudé
Description copied from Linux kernel commit from Gustavo A. R. Silva (see [3]): --v-- description start --v-- The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member [1], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being unadvertenly introduced [2] to the Linux codebase from now on. --^-- description end --^-- Do the similar housekeeping in the QEMU codebase (which uses C99 since commit 7be41675f7cb). All these instances of code were found with the help of the following command (then manual analysis, without modifying structures only having a single flexible array member, such QEDTable in block/qed.h): git grep -F '[0];' [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=76497732932f [3] https://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux.git/commit/?id=17642a2fbd2c1 Inspired-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16misc: Replace zero-length arrays with flexible array member (automatic)Philippe Mathieu-Daudé
Description copied from Linux kernel commit from Gustavo A. R. Silva (see [3]): --v-- description start --v-- The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member [1], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being unadvertenly introduced [2] to the Linux codebase from now on. --^-- description end --^-- Do the similar housekeeping in the QEMU codebase (which uses C99 since commit 7be41675f7cb). All these instances of code were found with the help of the following Coccinelle script: @@ identifier s, m, a; type t, T; @@ struct s { ... t m; - T a[0]; + T a[]; }; @@ identifier s, m, a; type t, T; @@ struct s { ... t m; - T a[0]; + T a[]; } QEMU_PACKED; [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=76497732932f [3] https://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux.git/commit/?id=17642a2fbd2c1 Inspired-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-12Merge remote-tracking branch ↵Peter Maydell
'remotes/pmaydell/tags/pull-target-arm-20200312' into staging target-arm queue: * Fix various bugs that might result in an assert() due to incorrect hflags for M-profile CPUs * Fix Aspeed SMC Controller user-mode select handling * Report correct (with-tag) address in fault address register when TBI is enabled * cubieboard: make sure SOC object isn't leaked * fsl-imx25: Wire up eSDHC controllers * fsl-imx25: Wire up USB controllers * New board model: orangepi-pc (OrangePi PC) * ARM/KVM: if user doesn't select GIC version and the host kernel can only provide GICv3, use that, rather than defaulting to "fail because GICv2 isn't possible" * kvm: Only do KVM_SET_VCPU_EVENTS at the last stage of sync # gpg: Signature made Thu 12 Mar 2020 16:43:46 GMT # gpg: using RSA key E1A5C593CD419DE28E8315CF3C2525ED14360CDE # gpg: issuer "peter.maydell@linaro.org" # gpg: Good signature from "Peter Maydell <peter.maydell@linaro.org>" [ultimate] # gpg: aka "Peter Maydell <pmaydell@gmail.com>" [ultimate] # gpg: aka "Peter Maydell <pmaydell@chiark.greenend.org.uk>" [ultimate] # Primary key fingerprint: E1A5 C593 CD41 9DE2 8E83 15CF 3C25 25ED 1436 0CDE * remotes/pmaydell/tags/pull-target-arm-20200312: (36 commits) target/arm: kvm: Inject events at the last stage of sync hw/arm/virt: kvm: allow gicv3 by default if v2 cannot work hw/arm/virt: kvm: Restructure finalize_gic_version() target/arm/kvm: Let kvm_arm_vgic_probe() return a bitmap hw/arm/virt: Introduce finalize_gic_version() hw/arm/virt: Introduce VirtGICType enum type hw/arm/virt: Document 'max' value in gic-version property description docs: add Orange Pi PC document tests/boot_linux_console: Test booting NetBSD via U-Boot on OrangePi PC tests/boot_linux_console: Add a SLOW test booting Ubuntu on OrangePi PC tests/boot_linux_console: Add a SD card test for the OrangePi PC board tests/boot_linux_console: Add initrd test for the Orange Pi PC board tests/boot_linux_console: Add a quick test for the OrangePi PC board hw/arm/allwinner: add RTC device support hw/arm/allwinner-h3: add SDRAM controller device hw/arm/allwinner-h3: add Boot ROM support hw/arm/allwinner-h3: add EMAC ethernet device hw/arm/allwinner: add SD/MMC host controller hw/arm/allwinner: add Security Identifier device hw/arm/allwinner: add CPU Configuration module ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-03-12Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into stagingPeter Maydell
Block layer patches: - Relax restrictions for blockdev-snapshot (allows libvirt to do live storage migration with blockdev-mirror) - luks: Delete created files when block_crypto_co_create_opts_luks fails - Fix memleaks in qmp_object_add # gpg: Signature made Wed 11 Mar 2020 15:38:59 GMT # gpg: using RSA key 7F09B272C88F2FD6 # gpg: Good signature from "Kevin Wolf <kwolf@redhat.com>" [full] # Primary key fingerprint: DC3D EB15 9A9A F95D 3D74 56FE 7F09 B272 C88F 2FD6 * remotes/kevin/tags/for-upstream: qemu-iotests: adding LUKS cleanup for non-UTF8 secret error crypto.c: cleanup created file when block_crypto_co_create_opts_luks fails block.c: adding bdrv_co_delete_file block: introducing 'bdrv_co_delete_file' interface tests/qemu-iotests: Fix socket_scm_helper build path qapi: Add '@allow-write-only-overlay' feature for 'blockdev-snapshot' iotests: Add iothread cases to 155 block: Fix cross-AioContext blockdev-snapshot iotests: Test mirror with temporarily disabled target backing file iotests: Fix run_job() with use_log=False block: Relax restrictions for blockdev-snapshot block: Make bdrv_get_cumulative_perm() public qom-qmp-cmds: fix two memleaks in qmp_object_add Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-03-12hw/arm/virt: Introduce finalize_gic_version()Eric Auger
Let's move the code which freezes which gic-version to be applied in a dedicated function. We also now set by default the VIRT_GIC_VERSION_NO_SET. This eventually turns into the legacy v2 choice in the finalize() function. Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Andrew Jones <drjones@redhat.com> Message-id: 20200311131618.7187-4-eric.auger@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-03-12hw/arm/virt: Introduce VirtGICType enum typeEric Auger
We plan to introduce yet another value for the gic version (nosel). As we already use exotic values such as 0 and -1, let's introduce a dedicated enum type and let vms->gic_version take this type. Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Andrew Jones <drjones@redhat.com> Message-id: 20200311131618.7187-3-eric.auger@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-03-12hw/arm/allwinner: add RTC device supportNiek Linnenbank
Allwinner System-on-Chips usually contain a Real Time Clock (RTC) for non-volatile system date and time keeping. This commit adds a generic Allwinner RTC device that supports the RTC devices found in Allwinner SoC family sun4i (A10), sun7i (A20) and sun6i and newer (A31, H2+, H3, etc). The following RTC functionality and features are implemented: * Year-Month-Day read/write * Hour-Minute-Second read/write * General Purpose storage The following boards are extended with the RTC device: * Cubieboard (hw/arm/cubieboard.c) * Orange Pi PC (hw/arm/orangepi.c) Signed-off-by: Niek Linnenbank <nieklinnenbank@gmail.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-id: 20200311221854.30370-13-nieklinnenbank@gmail.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-03-12hw/arm/allwinner-h3: add SDRAM controller deviceNiek Linnenbank
In the Allwinner H3 SoC the SDRAM controller is responsible for interfacing with the external Synchronous Dynamic Random Access Memory (SDRAM). Types of memory that the SDRAM controller supports are DDR2/DDR3 and capacities of up to 2GiB. This commit adds emulation support of the Allwinner H3 SDRAM controller. Signed-off-by: Niek Linnenbank <nieklinnenbank@gmail.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-id: 20200311221854.30370-12-nieklinnenbank@gmail.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-03-12hw/arm/allwinner-h3: add Boot ROM supportNiek Linnenbank
A real Allwinner H3 SoC contains a Boot ROM which is the first code that runs right after the SoC is powered on. The Boot ROM is responsible for loading user code (e.g. a bootloader) from any of the supported external devices and writing the downloaded code to internal SRAM. After loading the SoC begins executing the code written to SRAM. This commits adds emulation of the Boot ROM firmware setup functionality by loading user code from SD card in the A1 SRAM. While the A1 SRAM is 64KiB, we limit the size to 32KiB because the real H3 Boot ROM also rejects sizes larger than 32KiB. For reference, this behaviour is documented by the Linux Sunxi project wiki at: https://linux-sunxi.org/BROM#U-Boot_SPL_limitations Signed-off-by: Niek Linnenbank <nieklinnenbank@gmail.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-id: 20200311221854.30370-11-nieklinnenbank@gmail.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-03-12hw/arm/allwinner-h3: add EMAC ethernet deviceNiek Linnenbank
The Allwinner Sun8i System on Chip family includes an Ethernet MAC (EMAC) which provides 10M/100M/1000M Ethernet connectivity. This commit adds support for the Allwinner EMAC from the Sun8i family (H2+, H3, A33, etc), including emulation for the following functionality: * DMA transfers * MII interface * Transmit CRC calculation Signed-off-by: Niek Linnenbank <nieklinnenbank@gmail.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-id: 20200311221854.30370-10-nieklinnenbank@gmail.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-03-12hw/arm/allwinner: add SD/MMC host controllerNiek Linnenbank
The Allwinner System on Chip families sun4i and above contain an integrated storage controller for Secure Digital (SD) and Multi Media Card (MMC) interfaces. This commit adds support for the Allwinner SD/MMC storage controller with the following emulated features: * DMA transfers * Direct FIFO I/O * Short/Long format command responses * Auto-Stop command (CMD12) * Insert & remove card detection The following boards are extended with the SD host controller: * Cubieboard (hw/arm/cubieboard.c) * Orange Pi PC (hw/arm/orangepi.c) Signed-off-by: Niek Linnenbank <nieklinnenbank@gmail.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20200311221854.30370-9-nieklinnenbank@gmail.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-03-12hw/arm/allwinner: add Security Identifier deviceNiek Linnenbank
The Security Identifier device found in various Allwinner System on Chip designs gives applications a per-board unique identifier. This commit adds support for the Allwinner Security Identifier using a 128-bit UUID value as input. Signed-off-by: Niek Linnenbank <nieklinnenbank@gmail.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-id: 20200311221854.30370-8-nieklinnenbank@gmail.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-03-12hw/arm/allwinner: add CPU Configuration moduleNiek Linnenbank
Various Allwinner System on Chip designs contain multiple processors that can be configured and reset using the generic CPU Configuration module interface. This commit adds support for the Allwinner CPU configuration interface which emulates the following features: * CPU reset * CPU status Signed-off-by: Niek Linnenbank <nieklinnenbank@gmail.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-id: 20200311221854.30370-7-nieklinnenbank@gmail.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-03-12hw/arm/allwinner-h3: add System Control moduleNiek Linnenbank
The Allwinner H3 System on Chip has an System Control module that provides system wide generic controls and device information. This commit adds support for the Allwinner H3 System Control module. Signed-off-by: Niek Linnenbank <nieklinnenbank@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20200311221854.30370-6-nieklinnenbank@gmail.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-03-12hw/arm/allwinner-h3: add USB host controllerNiek Linnenbank
The Allwinner H3 System on Chip contains multiple USB 2.0 bus connections which provide software access using the Enhanced Host Controller Interface (EHCI) and Open Host Controller Interface (OHCI) interfaces. This commit adds support for both interfaces in the Allwinner H3 System on Chip. Signed-off-by: Niek Linnenbank <nieklinnenbank@gmail.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20200311221854.30370-5-nieklinnenbank@gmail.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-03-12hw/arm/allwinner-h3: add Clock Control UnitNiek Linnenbank
The Clock Control Unit is responsible for clock signal generation, configuration and distribution in the Allwinner H3 System on Chip. This commit adds support for the Clock Control Unit which emulates a simple read/write register interface. Signed-off-by: Niek Linnenbank <nieklinnenbank@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20200311221854.30370-4-nieklinnenbank@gmail.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-03-12hw/arm: add Allwinner H3 System-on-ChipNiek Linnenbank
The Allwinner H3 is a System on Chip containing four ARM Cortex A7 processor cores. Features and specifications include DDR2/DDR3 memory, SD/MMC storage cards, 10/100/1000Mbit Ethernet, USB 2.0, HDMI and various I/O modules. This commit adds support for the Allwinner H3 System on Chip. Signed-off-by: Niek Linnenbank <nieklinnenbank@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20200311221854.30370-2-nieklinnenbank@gmail.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-03-12hw/arm/fsl-imx25: Wire up USB controllersGuenter Roeck
i.MX25 supports two USB controllers. Let's wire them up. With this patch, imx25-pdk can boot from both USB ports. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Message-id: 20200310215146.19688-3-linux@roeck-us.net Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-03-12hw/arm/fsl-imx25: Wire up eSDHC controllersGuenter Roeck
Wire up eSDHC controllers in fsl-imx25. For imx25-pdk, connect drives provided on the command line to available eSDHC controllers. This patch enables booting the imx25-pdk emulation from SD card. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Message-id: 20200310215146.19688-2-linux@roeck-us.net Reviewed-by: Peter Maydell <peter.maydell@linaro.org> [PMM: made commit subject consistent with other patch] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-03-11Merge remote-tracking branch 'remotes/maxreitz/tags/pull-block-2020-03-11' ↵Peter Maydell
into staging Block patches for the 5.0 softfreeze: - qemu-img measure for LUKS - Improve block-copy's performance by reducing inter-request dependencies - Make curl's detection of accept-ranges more robust - Memleak fixes - iotest fix # gpg: Signature made Wed 11 Mar 2020 13:19:01 GMT # gpg: using RSA key 91BEB60A30DB3E8857D11829F407DB0061D5CF40 # gpg: issuer "mreitz@redhat.com" # gpg: Good signature from "Max Reitz <mreitz@redhat.com>" [full] # Primary key fingerprint: 91BE B60A 30DB 3E88 57D1 1829 F407 DB00 61D5 CF40 * remotes/maxreitz/tags/pull-block-2020-03-11: block/block-copy: hide structure definitions block/block-copy: reduce intersecting request lock block/block-copy: rename start to offset in interfaces block/block-copy: refactor interfaces to use bytes instead of end block/block-copy: factor out find_conflicting_inflight_req block/block-copy: use block_status block/block-copy: specialcase first copy_range request block/block-copy: fix progress calculation job: refactor progress to separate object block/qcow2-threads: fix qcow2_decompress qemu-img: free memory before re-assign block/qcow2: do free crypto_opts in qcow2_close() iotests: Fix nonportable use of od --endian block/curl: HTTP header field names are case insensitive block/curl: HTTP header fields allow whitespace around values iotests: add 288 luks qemu-img measure test qemu-img: allow qemu-img measure --object without a filename luks: implement .bdrv_measure() luks: extract qcrypto_block_calculate_payload_offset() Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-03-11block.c: adding bdrv_co_delete_fileDaniel Henrique Barboza
Using the new 'bdrv_co_delete_file' interface, a pure co_routine function 'bdrv_co_delete_file' inside block.c can can be used in a way similar of the existing bdrv_create_file to to clean up a created file. We're creating a pure co_routine because the only caller of 'bdrv_co_delete_file' will be already in co_routine context, thus there is no need to add all the machinery to check for qemu_in_coroutine() and create a separated co_routine to do the job. Suggested-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20200130213907.2830642-3-danielhb413@gmail.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-03-11block: introducing 'bdrv_co_delete_file' interfaceDaniel Henrique Barboza
Adding to Block Drivers the capability of being able to clean up its created files can be useful in certain situations. For the LUKS driver, for instance, a failure in one of its authentication steps can leave files in the host that weren't there before. This patch adds the 'bdrv_co_delete_file' interface to block drivers and add it to the 'file' driver in file-posix.c. The implementation is given by 'raw_co_delete_file'. Suggested-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20200130213907.2830642-2-danielhb413@gmail.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-03-11block: Make bdrv_get_cumulative_perm() publicKevin Wolf
Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20200310113831.27293-2-kwolf@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>