aboutsummaryrefslogtreecommitdiff
path: root/hw
AgeCommit message (Collapse)Author
2020-03-17hw/scsi/spapr_vscsi: Introduce req_iu() helperPhilippe Mathieu-Daudé
Introduce the req_iu() helper which returns a pointer to the viosrp_iu union held in the vscsi_req structure. This simplifies the next patch. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200305121253.19078-5-philmd@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-03-17hw/scsi/spapr_vscsi: Simplify a bitPhilippe Mathieu-Daudé
We already have a 'iu' pointer, use it (this simplifies the next commit). Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200305121253.19078-4-philmd@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-03-17hw/scsi/spapr_vscsi: Use SRP_MAX_IU_LEN instead of sizeof flexible arrayPhilippe Mathieu-Daudé
Replace sizeof() flexible arrays union srp_iu/viosrp_iu by the SRP_MAX_IU_LEN definition, which is what this code actually meant to use. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200305121253.19078-3-philmd@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-03-17hw/scsi/viosrp: Add missing 'hw/scsi/srp.h' includePhilippe Mathieu-Daudé
This header use the srp_* structures declared in "hw/scsi/srp.h". Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200305121253.19078-2-philmd@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-03-17spapr: Clean up RMA size calculationDavid Gibson
Move the calculation of the Real Mode Area (RMA) size into a helper function. While we're there clean it up and correct it in a few ways: * Add comments making it clearer where the various constraints come from * Remove a pointless check that the RMA fits within Node 0 (we've just clamped it so that it does) 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-16via-ide: always use legacy IRQ 14/15 routingMark Cave-Ayland
The existing code uses fixed PCI IRQ routing on IRQ 14 rather than legacy IRQ 14/15 routing as documented in the datasheet. With the changes in this patchset guest OSs now correctly detect and configure the VIA controller in legacy IRQ routing mode, allowing the incorrect fixed PCI IRQ routing to be removed. Note that this fixed legacy IRQ 14/15 routing is identical to similar behaviour in the early PIIX IDE controllers. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Tested-by: BALATON Zoltan <balaton@eik.bme.hu> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-id: 20200313082444.2439-8-mark.cave-ayland@ilande.co.uk Signed-off-by: John Snow <jsnow@redhat.com>
2020-03-16via-ide: allow guests to write to PCI_CLASS_PROGMark Cave-Ayland
MorphOS writes to PCI_CLASS_PROG during IDE initialisation to place the controller in native mode, but thinks the initialisation has failed because the native mode bits aren't set when reading the register back. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Tested-by: BALATON Zoltan <balaton@eik.bme.hu> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-id: 20200313082444.2439-7-mark.cave-ayland@ilande.co.uk Signed-off-by: John Snow <jsnow@redhat.com>
2020-03-16via-ide: initialise IDE controller in legacy modeMark Cave-Ayland
According to both the VT82C686B and VT8231 datasheets the VIA Southbridge IDE controller is initialised in legacy mode. This allows Linux to correctly determine that legacy rather than PCI IRQ routing should be used since the boot console text in the fulong2e test image changes from: scsi0 : pata_via scsi1 : pata_via ata1: PATA max UDMA/100 cmd 0xffffffffbfd04050 ctl 0xffffffffbfd04062 \ bmdma 0xffffffffbfd04040 irq 14 ata2: PATA max UDMA/100 cmd 0xffffffffbfd04058 ctl 0xffffffffbfd04066 \ bmdma 0xffffffffbfd04048 irq 14 to: scsi0 : pata_via scsi1 : pata_via ata1: PATA max UDMA/100 cmd 0xffffffffbfd001f0 ctl 0xffffffffbfd003f6 \ bmdma 0xffffffffbfd04040 irq 14 ata2: PATA max UDMA/100 cmd 0xffffffffbfd00170 ctl 0xffffffffbfd00376 \ bmdma 0xffffffffbfd04048 irq 15 Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Tested-by: BALATON Zoltan <balaton@eik.bme.hu> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-id: 20200313082444.2439-6-mark.cave-ayland@ilande.co.uk Signed-off-by: John Snow <jsnow@redhat.com>
2020-03-16via-ide: ensure that PCI_INTERRUPT_LINE is hard-wired to its default valueMark Cave-Ayland
Some firmwares accidentally write to PCI_INTERRUPT_LINE on startup which has no effect on real hardware since it is hard-wired to its default value, but causes the guest OS to become confused trying to initialise IDE devices when running under QEMU. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Tested-by: BALATON Zoltan <balaton@eik.bme.hu> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-id: 20200313082444.2439-5-mark.cave-ayland@ilande.co.uk Signed-off-by: John Snow <jsnow@redhat.com>
2020-03-16pci: Honour wmask when resetting PCI_INTERRUPT_LINEBALATON Zoltan
The pci_do_device_reset() function (called from pci_device_reset) clears the PCI_INTERRUPT_LINE config reg of devices on the bus but did this without taking wmask into account. We'll have a device model now that needs to set a constant value for this reg and this patch allows to do that without additional workaround in device emulation to reverse the effect of this PCI bus reset function. Suggested-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> 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-4-mark.cave-ayland@ilande.co.uk Signed-off-by: John Snow <jsnow@redhat.com>
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-16via-ide: move registration of VMStateDescription to DeviceClassMark Cave-Ayland
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: BALATON Zoltan <balaton@eik.bme.hu> Message-id: 20200313082444.2439-2-mark.cave-ayland@ilande.co.uk Signed-off-by: John Snow <jsnow@redhat.com>
2020-03-16riscv: sifive_u: Update BIOS_FILENAME for 32-bitBin Meng
Update BIOS_FILENAME to consider 32-bit bios image file name. Tested booting Linux v5.5 32-bit image (built from rv32_defconfig plus CONFIG_SOC_SIFIVE) with the default 32-bit bios image. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.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,ppc: Simplify signature of kvmppc_rma_size()David Gibson
This function calculates the maximum size of the RMA as implied by the host's page size of structure of the VRMA (there are a number of other constraints on the RMA size which will supersede this one in many circumstances). The current interface takes the current RMA size estimate, and clamps it to the VRMA derived size. The only current caller passes in an arguably wrong value (it will match the current RMA estimate in some but not all cases). We want to fix that, but for now just keep concerns separated by having the KVM helper function just return the VRMA derived limit, and let the caller combine it with other constraints. We call the new function kvmppc_vrma_limit() to more clearly indicate its limited responsibility. The helper should only ever be called in the KVM enabled case, so replace its !CONFIG_KVM stub with an assert() rather than a dummy value. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cedric Le Goater <clg@fr.ibm.com> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2020-03-17spapr: Don't use weird units for MIN_RMA_SLOFDavid Gibson
MIN_RMA_SLOF records the minimum about of RMA that the SLOF firmware requires. It lets us give a meaningful error if the RMA ends up too small, rather than just letting SLOF crash. It's currently stored as a number of megabytes, which is strange for global constants. Move that megabyte scaling into the definition of the constant like most other things use. Change from M to MiB in the associated message while we're at it. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2020-03-17spapr, ppc: Remove VPM0/RMLS hacks for POWER9David Gibson
For the "pseries" machine, we use "virtual hypervisor" mode where we only model the CPU in non-hypervisor privileged mode. This means that we need guest physical addresses within the modelled cpu to be treated as absolute physical addresses. We used to do that by clearing LPCR[VPM0] and setting LPCR[RMLS] to a high limit so that the old offset based translation for guest mode applied, which does what we need. However, POWER9 has removed support for that translation mode, which meant we had some ugly hacks to keep it working. We now explicitly handle this sort of translation for virtual hypervisor mode, so the hacks aren't necessary. We don't need to set VPM0 and RMLS from the machine type code - they're now ignored in vhyp mode. On the cpu side we don't need to allow LPCR[RMLS] to be set on POWER9 in vhyp mode - that was only there to allow the hack on the machine side. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org>
2020-03-17hw/ppc/pnv: Fix typo in commentPhilippe Mathieu-Daudé
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200228123303.14540-1-philmd@redhat.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-03-17spapr: Fix Coverity warning while validating nvdimm optionsShivaprasad G Bhat
Fixes Coverity issue, CID 1419883: Error handling issues (CHECKED_RETURN) Calling "qemu_uuid_parse" without checking return value nvdimm_set_uuid() already verifies if the user provided uuid is valid or not. So, need to check for the validity during pre-plug validation again. As this a false positive in this case, assert if not valid to be safe. Also, error_abort if QOM accessor encounters error while fetching the uuid property. Reported-by: Coverity (CID 1419883) Signed-off-by: Shivaprasad G Bhat <sbhat@linux.ibm.com> Message-Id: <158281096564.89540.4507375445765515529.stgit@lep8c.aus.stglabs.ibm.com> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
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-16exec/rom_reset: Free rom data during inmigrate skipDr. David Alan Gilbert
Commit 355477f8c73e9 skips rom reset when we're an incoming migration so as not to overwrite shared ram in the ignore-shared migration optimisation. However, it's got an unexpected side effect that because it skips freeing the ROM data, when rom_reset gets called later on, after migration (e.g. during a reboot), the ROM does get reset to the original file contents. Because of seabios/x86's weird reboot process this confuses a reboot into hanging after a migration. Fixes: 355477f8c73e9 ("migration: do not rom_reset() during incoming migration") https://bugzilla.redhat.com/show_bug.cgi?id=1809380 Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16hw/usb/quirks: Use smaller types to reduce .rodata by 10KiBPhilippe Mathieu-Daudé
The USB descriptor sizes are specified as 16-bit for idVendor / idProduct, and 8-bit for bInterfaceClass / bInterfaceSubClass / bInterfaceProtocol. Doing so we reduce the usbredir_raw_serial_ids[] and usbredir_ftdi_serial_ids[] arrays from 16KiB to 6KiB (size reported on x86_64 host, building with --extra-cflags=-Os). Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16hw/audio/intel-hda: Use memory region alias to reduce .rodata by 4.34MBPhilippe Mathieu-Daudé
The intel-hda model uses an array of register indexed by the register address. This array also contains a pair of aliased registers at offset 0x2000. This creates a huge hole in the array, which ends up eating 4.6MiB of .rodata (size reported on x86_64 host, building with --extra-cflags=-Os). By using a memory region alias, we reduce this array to 132kB. Before: (qemu) info mtree 00000000febd4000-00000000febd7fff (prio 1, i/o): intel-hda After: (qemu) info mtree 00000000febd4000-00000000febd7fff (prio 1, i/o): intel-hda 00000000febd4000-00000000febd7fff (prio 1, i/o): intel-hda-container 00000000febd4000-00000000febd5fff (prio 0, i/o): intel-hda 00000000febd6000-00000000febd7fff (prio 0, i/o): alias intel-hda-alias @intel-hda 0000000000000000-0000000000001fff Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16hw/audio/fmopl: Move ENV_CURVE to .heap to save 32KiB of .bssPhilippe Mathieu-Daudé
This buffer is only used by the adlib audio device. Move it to the .heap to release 32KiB of .bss (size reported on x86_64 host). Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16qom/object: Use common get/set uint helpersFelipe Franciosi
Several objects implemented their own uint property getters and setters, despite them being straightforward (without any checks/validations on the values themselves) and identical across objects. This makes use of an enhanced API for object_property_add_uintXX_ptr() which offers default setters. Some of these setters used to update the value even if the type visit failed (eg. because the value being set overflowed over the given type). The new setter introduces a check for these errors, not updating the value if an error occurred. The error is propagated. 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-16ich9: Simplify ich9_lpc_initfnFelipe Franciosi
Currently, ich9_lpc_initfn simply serves as a caller to ich9_lpc_add_properties. This simplifies the code a bit by eliminating ich9_lpc_add_properties altogether and executing its logic in the parent object initialiser function. 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-16ich9: fix getter type for sci_int propertyFelipe Franciosi
When QOM APIs were added to ich9 in 6f1426ab, the getter for sci_int was written using uint32_t. However, the object property is uint8_t. This fixes the getter for correctness. 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-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-16hw/i386/intel_iommu: Fix out-of-bounds access on guest IRTJan Kiszka
vtd_irte_get failed to check the index against the configured table size, causing an out-of-bounds access on guest memory and potentially misinterpreting the result. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Message-Id: <4b15b728-bdfe-3bbe-3a5c-ca3baeef3c5c@siemens.com> 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-16stdvga+bochs-display: add dummy mmio handlerGerd Hoffmann
The bochs-display mmio bar has some sub-regions with the actual hardware registers. What happens when the guest access something outside those regions depends on the archirecture. On x86 those reads succeed (and return 0xff I think). On risc-v qemu aborts. This patch adds handlers for the parent region, to make the wanted behavior explicit and to make things consistent across architectures. v2: - use existing unassigned_io_ops. - also cover stdvga. Cc: Alistair Francis <alistair23@gmail.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-id: 20200309100009.17624-1-kraxel@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-12hw/arm/virt: kvm: allow gicv3 by default if v2 cannot workEric Auger
At the moment if the end-user does not specify the gic-version along with KVM acceleration, v2 is set by default. However most of the systems now have GICv3 and sometimes they do not support GICv2 compatibility. This patch keeps the default v2 selection in all cases except in the KVM accelerated mode when either - the host does not support GICv2 in-kernel emulation or - number of VCPUS exceeds 8. Those cases did not work anyway so we do not break any compatibility. Now we get v3 selected in such a case. Signed-off-by: Eric Auger <eric.auger@redhat.com> Reported-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Andrew Jones <drjones@redhat.com> Message-id: 20200311131618.7187-7-eric.auger@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-03-12hw/arm/virt: kvm: Restructure finalize_gic_version()Eric Auger
Restructure the finalize_gic_version with switch cases and clearly separate the following cases: - KVM mode / in-kernel irqchip - KVM mode / userspace irqchip - TCG mode In KVM mode / in-kernel irqchip , we explictly check whether the chosen version is supported by the host. If the end-user explicitly sets v2/v3 and this is not supported by the host, then the user gets an explicit error message. Note that for old kernels where the CREATE_DEVICE ioctl doesn't exist then we will now fail if the user specifically asked for gicv2, where previously we (probably) would have succeeded. In KVM mode / userspace irqchip we immediatly output an error in case the end-user explicitly selected v3. Also we warn the end-user about the unexpected usage of gic-version=host in that case as only userspace GICv2 is supported. Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Andrew Jones <drjones@redhat.com> Message-id: 20200311131618.7187-6-eric.auger@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-03-12target/arm/kvm: Let kvm_arm_vgic_probe() return a bitmapEric Auger
Convert kvm_arm_vgic_probe() so that it returns a bitmap of supported in-kernel emulation VGIC versions instead of the max version: at the moment values can be v2 and v3. This allows to expose the case where the host GICv3 also supports GICv2 emulation. This will be useful to choose the default version in KVM accelerated mode. Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20200311131618.7187-5-eric.auger@redhat.com 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/virt: Document 'max' value in gic-version property descriptionEric Auger
Mention 'max' value in the gic-version property description. 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-2-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>
generated by cgit v1.2.3 (git 2.26.2) at 2025-03-15 06:20:27 +0000