summaryrefslogtreecommitdiffstats
path: root/hw
Commit message (Collapse)AuthorAgeFilesLines
* Merge remote-tracking branch 'remotes/amarkovic/tags/mips-queue-jun-26-2019' ↵Peter Maydell2019-07-013-238/+281
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | into staging MIPS queue for June 2016th, 2019 # gpg: Signature made Wed 26 Jun 2019 12:38:58 BST # gpg: using RSA key D4972A8967F75A65 # gpg: Good signature from "Aleksandar Markovic <amarkovic@wavecomp.com>" [unknown] # gpg: WARNING: This key is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: 8526 FBF1 5DA3 811F 4A01 DD75 D497 2A89 67F7 5A65 * remotes/amarkovic/tags/mips-queue-jun-26-2019: target/mips: Fix big endian host behavior for interleave MSA instructions tests/tcg: target/mips: Fix some test cases for pack MSA instructions tests/tcg: target/mips: Add support for MSA MIPS32R6 testings tests/tcg: target/mips: Add support for MSA big-endian target testings tests/tcg: target/mips: Amend tests for MSA int multiply instructions tests/tcg: target/mips: Amend tests for MSA int dot product instructions tests/tcg: target/mips: Add tests for MSA move instructions tests/tcg: target/mips: Add tests for MSA bit move instructions dma/rc4030: Minor code style cleanup dma/rc4030: Fix off-by-one error in specified memory region size hw/mips/gt64xxx_pci: Align the pci0-mem size hw/mips/gt64xxx_pci: Convert debug printf()s to trace events hw/mips/gt64xxx_pci: Use qemu_log_mask() instead of debug printf() hw/mips/gt64xxx_pci: Fix 'spaces' coding style issues hw/mips/gt64xxx_pci: Fix 'braces' coding style issues hw/mips/gt64xxx_pci: Fix 'tabs' coding style issues hw/mips/gt64xxx_pci: Fix multiline comment syntax Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
| * dma/rc4030: Minor code style cleanupAleksandar Markovic2019-06-261-7/+11
| | | | | | | | | | | | | | | | | | Fix some simple checkpatch.pl warnings in rc4030.c. Signed-off-by: Aleksandar Markovic <amarkovic@wavecomp.com> Reviewed-by: Aleksandar Rikalo <arikalo@wavecomp.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <1561472838-32272-3-git-send-email-aleksandar.markovic@rt-rk.com>
| * dma/rc4030: Fix off-by-one error in specified memory region sizeAleksandar Markovic2019-06-261-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The size is one byte less than it should be: address-space: rc4030-dma 0000000000000000-00000000fffffffe (prio 0, i/o): rc4030.dma rc4030 is used in MIPS Jazz board context. Signed-off-by: Aleksandar Markovic <amarkovic@wavecomp.com> Reviewed-by: Aleksandar Rikalo <arikalo@wavecomp.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <1561472838-32272-2-git-send-email-aleksandar.markovic@rt-rk.com>
| * hw/mips/gt64xxx_pci: Align the pci0-mem sizePhilippe Mathieu-Daudé2019-06-261-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | One byte is missing, use an aligned size. (qemu) info mtree memory-region: pci0-mem 0000000000000000-00000000fffffffe (prio 0, i/o): pci0-mem ^ Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Aleksandar Markovic <amarkovic@wavecomp.com> Message-Id: <20190624222844.26584-8-f4bug@amsat.org>
| * hw/mips/gt64xxx_pci: Convert debug printf()s to trace eventsPhilippe Mathieu-Daudé2019-06-262-19/+14Star
| | | | | | | | | | | | Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Aleksandar Markovic <amarkovic@wavecomp.com> Message-Id: <20190624222844.26584-7-f4bug@amsat.org>
| * hw/mips/gt64xxx_pci: Use qemu_log_mask() instead of debug printf()Philippe Mathieu-Daudé2019-06-261-11/+37
| | | | | | | | | | | | Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Aleksandar Markovic <amarkovic@wavecomp.com> Message-Id: <20190624222844.26584-6-f4bug@amsat.org>
| * hw/mips/gt64xxx_pci: Fix 'spaces' coding style issuesPhilippe Mathieu-Daudé2019-06-261-5/+6
| | | | | | | | | | | | | | | | | | | | | | Since we'll move this code around, fix its style first: ERROR: space prohibited between function name and open parenthesis ERROR: line over 90 characters Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Aleksandar Markovic <amarkovic@wavecomp.com> Message-Id: <20190624222844.26584-5-f4bug@amsat.org>
| * hw/mips/gt64xxx_pci: Fix 'braces' coding style issuesPhilippe Mathieu-Daudé2019-06-261-9/+18
| | | | | | | | | | | | | | | | | | | | Since we'll move this code around, fix its style first: ERROR: braces {} are necessary for all arms of this statement Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Aleksandar Markovic <amarkovic@wavecomp.com> Message-Id: <20190624222844.26584-4-f4bug@amsat.org>
| * hw/mips/gt64xxx_pci: Fix 'tabs' coding style issuesPhilippe Mathieu-Daudé2019-06-261-156/+156
| | | | | | | | | | | | | | | | | | | | Since we'll move this code around, fix its style first: ERROR: code indent should never use tabs Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Aleksandar Markovic <amarkovic@wavecomp.com> Message-Id: <20190624222844.26584-3-f4bug@amsat.org>
| * hw/mips/gt64xxx_pci: Fix multiline comment syntaxPhilippe Mathieu-Daudé2019-06-261-29/+35
| | | | | | | | | | | | | | | | | | | | Since commit 8c06fbdf36b checkpatch.pl enforce a new multiline comment syntax. Since we'll move this code around, fix its style first. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Aleksandar Markovic <amarkovic@wavecomp.com> Message-Id: <20190624222844.26584-2-f4bug@amsat.org>
* | Merge remote-tracking branch 'remotes/aperard/tags/pull-xen-20190624' into ↵Peter Maydell2019-07-0113-97/+123
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | staging Xen queue * Fix build * xen-block: support feature-large-sector-size * xen-block: Support IOThread polling for PV shared rings * Avoid usage of a VLA * Cleanup Xen headers usage # gpg: Signature made Mon 24 Jun 2019 16:30:32 BST # gpg: using RSA key F80C006308E22CFD8A92E7980CF5572FD7FB55AF # gpg: issuer "anthony.perard@citrix.com" # gpg: Good signature from "Anthony PERARD <anthony.perard@gmail.com>" [marginal] # gpg: aka "Anthony PERARD <anthony.perard@citrix.com>" [marginal] # gpg: WARNING: This key is not certified with sufficiently trusted signatures! # gpg: It is not certain that the signature belongs to the owner. # Primary key fingerprint: 5379 2F71 024C 600F 778A 7161 D8D5 7199 DF83 42C8 # Subkey fingerprint: F80C 0063 08E2 2CFD 8A92 E798 0CF5 572F D7FB 55AF * remotes/aperard/tags/pull-xen-20190624: xen: Import other xen/io/*.h Revert xen/io/ring.h of "Clean up a few header guard symbols" xen: Drop includes of xen/hvm/params.h xen: Avoid VLA xen-bus / xen-block: add support for event channel polling xen-bus: allow AioContext to be specified for each event channel xen-bus: use a separate fd for each event channel xen-block: support feature-large-sector-size Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
| * | xen: Import other xen/io/*.hAnthony PERARD2019-06-247-15/+10Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A Xen public header have been imported into QEMU (by f65eadb639 "xen: import ring.h from xen"), but there are other header that depends on ring.h which come from the system when building QEMU. This patch resolves the issue of having headers from the system importing a different copie of ring.h. This patch is prompt by the build issue described in the previous patch: 'Revert xen/io/ring.h of "Clean up a few header guard symbols"' ring.h and the new imported headers are moved to "include/hw/xen/interface" as those describe interfaces with a guest. The imported headers are cleaned up a bit while importing them: some part of the file that QEMU doesn't use are removed (description of how to make hypercall in grant_table.h have been removed). Other cleanup: - xen-mapcache.c and xen-legacy-backend.c don't need grant_table.h. - xenfb.c doesn't need event_channel.h. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Paul Durrant <paul.durrant@citrix.com> Message-Id: <20190621105441.3025-3-anthony.perard@citrix.com>
| * | xen: Drop includes of xen/hvm/params.hAnthony PERARD2019-06-242-3/+0Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | xen-mapcache.c doesn't needs params.h. xen-hvm.c uses defines available in params.h but so is xen_common.h which is included before. HVM_PARAM_* flags are only needed to make xc_hvm_param_{get,set} calls so including only xenctrl.h, which is where the definition the function is, should be enough. (xenctrl.h does include params.h) Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Paul Durrant <paul.durrant@citrix.com> Message-Id: <20190618112341.513-4-anthony.perard@citrix.com>
| * | xen: Avoid VLAAnthony PERARD2019-06-241-4/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Avoid using a variable length array. We allocate the `dirty_bitmap' buffer only once when we start tracking for dirty bits. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Paul Durrant <paul.durrant@citrix.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20190618112341.513-5-anthony.perard@citrix.com>
| * | xen-bus / xen-block: add support for event channel pollingPaul Durrant2019-06-242-10/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch introduces a poll callback for event channel fd-s and uses this to invoke the channel callback function. To properly support polling, it is necessary for the event channel callback function to return a boolean saying whether it has done any useful work or not. Thus xen_block_dataplane_event() is modified to directly invoke xen_block_handle_requests() and the latter only returns true if it actually processes any requests. This also means that the call to qemu_bh_schedule() is moved into xen_block_complete_aio(), which is more intuitive since the only reason for doing a deferred poll of the shared ring should be because there were previously insufficient resources to fully complete a previous poll. Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com> Message-Id: <20190408151617.13025-4-paul.durrant@citrix.com> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
| * | xen-bus: allow AioContext to be specified for each event channelPaul Durrant2019-06-242-4/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds an AioContext parameter to xen_device_bind_event_channel() and then uses aio_set_fd_handler() to set the callback rather than qemu_set_fd_handler(). Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com> Message-Id: <20190408151617.13025-3-paul.durrant@citrix.com> [Call aio_set_fd_handler() with is_external=true] Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
| * | xen-bus: use a separate fd for each event channelPaul Durrant2019-06-241-39/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To better support use of IOThread-s it will be necessary to be able to set the AioContext for each XenEventChannel and hence it is necessary to open a separate handle to libxenevtchan for each channel. This patch stops using NotifierList for event channel callbacks, replacing that construct by a list of complete XenEventChannel structures. Each of these now has a xenevtchn_handle pointer in place of the single pointer previously held in the XenDevice structure. The individual handles are opened/closed in xen_device_bind/unbind_event_channel(), replacing the single open/close in xen_device_realize/unrealize(). NOTE: This patch does not add an AioContext parameter to xen_device_bind_event_channel(). That will be done in a subsequent patch. Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com> Message-Id: <20190408151617.13025-2-paul.durrant@citrix.com> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
| * | xen-block: support feature-large-sector-sizePaul Durrant2019-06-243-26/+40
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A recent Xen commit [1] clarified the semantics of sector based quantities used in the blkif protocol such that it is now safe to create a xen-block device with a logical_block_size != 512, as long as the device only connects to a frontend advertizing 'feature-large-block-size'. This patch modifies xen-block accordingly. It also uses a stack variable for the BlockBackend in xen_block_realize() to avoid repeated dereferencing of the BlockConf pointer, and changes the parameters of xen_block_dataplane_create() so that the BlockBackend pointer and sector size are passed expicitly rather than implicitly via the BlockConf. These modifications have been tested against a recent Windows PV XENVBD driver [2] using a xen-disk device with a 4kB logical block size. [1] http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=67e1c050e36b2c9900cca83618e56189effbad98 [2] https://winpvdrvbuild.xenproject.org:8080/job/XENVBD-master/126 Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com> Message-Id: <20190409164038.25484-1-paul.durrant@citrix.com> [Edited error message] Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
* / nvme: do not advertise support for unsupported arbitration mechanismKlaus Birkelund Jensen2019-06-241-1/+0Star
|/ | | | | | | | | | | | The device mistakenly reports that the Weighted Round Robin with Urgent Priority Class arbitration mechanism is supported. It is not. Signed-off-by: Klaus Birkelund Jensen <klaus.jensen@cnexlabs.com> Message-id: 20190606092530.14206-1-klaus@birkelund.eu Acked-by: Maxim Levitsky <mlevitsk@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
* hw: Nuke hw_compat_4_0_1 and pc_compat_4_0_1Greg Kurz2019-06-213-11/+9Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit c87759ce876a fixed a regression affecting pc-q35 machines by introducing a new pc-q35-4.0.1 machine version to be used instead of pc-q35-4.0. The only purpose was to revert the default behaviour of not using split irqchip, but the change also introduced the usual hw_compat and pc_compat bits, and wired them for pc-q35 only. This raises questions when it comes to add new compat properties for 4.0* machine versions of any architecture. Where to add them ? In 4.0, 4.0.1 or both ? Error prone. Another possibility would be to teach all other architectures about 4.0.1. This solution isn't satisfying, especially since this is a pc-q35 specific issue. It turns out that the split irqchip default is handled in the machine option function and doesn't involve compat lists at all. Drop all the 4.0.1 compat lists and use the 4.0 ones instead in the 4.0.1 machine option function. Move the compat props that were added to the 4.0.1 since c87759ce876a to 4.0. Even if only hw_compat_4_0_1 had an impact on other architectures, drop pc_compat_4_0_1 as well for consistency. Fixes: c87759ce876a "q35: Revert to kernel irqchip" Suggested-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <156051774276.244890.8660277280145466396.stgit@bahia.lan> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* sd: Fix out-of-bounds assertionsLidong Chen2019-06-211-2/+2
| | | | | | | | | | | | | | | Due to an off-by-one error, the assert statements allow an out-of-bound array access. This doesn't happen in practice, but the static analyzer notices. Signed-off-by: Lidong Chen <lidong.chen@oracle.com> Reviewed-by: Liam Merwick <liam.merwick@oracle.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Li Qiang <liq3ea@gmail.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Message-Id: <6b19cb7359a10a6bedc3ea0fce22fed3ef93c102.1560806687.git.lidong.chen@oracle.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* i386/kvm: convert hyperv enlightenments properties from bools to bitsVitaly Kuznetsov2019-06-211-1/+2
| | | | | | | | | | Representing Hyper-V properties as bits will allow us to check features and dependencies between them in a natural way. Suggested-by: Roman Kagan <rkagan@virtuozzo.com> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20190517141924.19024-2-vkuznets@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* hw/intc/arm_gicv3: GICD_TYPER.SecurityExtn is RAZ if GICD_CTLR.DS == 1Peter Maydell2019-06-171-1/+7
| | | | | | | | | | | | The GICv3 specification says that the GICD_TYPER.SecurityExtn bit is RAZ if GICD_CTLR.DS is 1. We were incorrectly making it RAZ if the security extension is unsupported. "Security extension unsupported" always implies GICD_CTLR.DS == 1, but the guest can also set DS on a GIC which does support the security extension. Fix the condition to correctly check the GICD_CTLR.DS bit. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20190524124248.28394-3-peter.maydell@linaro.org
* hw/intc/arm_gicv3: Fix decoding of ID register rangePeter Maydell2019-06-172-4/+4
| | | | | | | | | | The GIC ID registers cover an area 0x30 bytes in size (12 registers, 4 bytes each). We were incorrectly decoding only the first 0x20 bytes. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20190524124248.28394-2-peter.maydell@linaro.org
* hw/arm: Correctly disable FPU/DSP for some ARMSSE-based boardsPeter Maydell2019-06-172-12/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The SSE-200 hardware has configurable integration settings which determine whether its two CPUs have the FPU and DSP: * CPU0_FPU (default 0) * CPU0_DSP (default 0) * CPU1_FPU (default 1) * CPU1_DSP (default 1) Similarly, the IoTKit has settings for its single CPU: * CPU0_FPU (default 1) * CPU0_DSP (default 1) Of our four boards that use either the IoTKit or the SSE-200: * mps2-an505, mps2-an521 and musca-a use the default settings * musca-b1 enables FPU and DSP on both CPUs Currently QEMU models all these boards using CPUs with both FPU and DSP enabled. This means that we are incorrect for mps2-an521 and musca-a, which should not have FPU or DSP on CPU0. Create QOM properties on the ARMSSE devices corresponding to the default h/w integration settings, and make the Musca-B1 board enable FPU and DSP on both CPUs. This fixes the mps2-an521 and musca-a behaviour, and leaves the musca-b1 and mps2-an505 behaviour unchanged. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-id: 20190517174046.11146-5-peter.maydell@linaro.org
* hw/arm/armv7m: Forward "vfp" and "dsp" properties to CPUPeter Maydell2019-06-171-0/+18
| | | | | | | | | | | Create "vfp" and "dsp" properties on the armv7m container object which will be forwarded to its CPU object, so that SoCs can configure whether the CPU has these features. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-id: 20190517174046.11146-4-peter.maydell@linaro.org
* hw/arm/boot: Honour image size field in AArch64 Image format kernelsPeter Maydell2019-06-171-2/+15
| | | | | | | | | | | | | | | | | | | | | Since Linux v3.17, the kernel's Image header includes a field image_size, which gives the total size of the kernel including unpopulated data sections such as the BSS). If this is present, then return it from load_aarch64_image() as the true size of the kernel rather than just using the size of the Image file itself. This allows the code which calculates where to put the initrd to avoid putting it in the kernel's BSS area. This means that we should be able to reliably load kernel images which are larger than 128MB without accidentally putting the initrd or dtb in locations that clash with the kernel itself. Fixes: https://bugs.launchpad.net/qemu/+bug/1823998 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Mark Rutland <mark.rutland@arm.com> Message-id: 20190516144733.32399-5-peter.maydell@linaro.org
* hw/arm/boot: Avoid placing the initrd on top of the kernelPeter Maydell2019-06-171-14/+20
| | | | | | | | | | | | | | | | | | | | We currently put the initrd at the smaller of: * 128MB into RAM * halfway into the RAM (with the dtb following it). However for large kernels this might mean that the kernel overlaps the initrd. For some kinds of kernel (self-decompressing 32-bit kernels, and ELF images with a BSS section at the end) we don't know the exact size, but even there we have a minimum size. Put the initrd at least further into RAM than that. For image formats that can give us an exact kernel size, this will mean that we definitely avoid overlaying kernel and initrd. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Mark Rutland <mark.rutland@arm.com> Message-id: 20190516144733.32399-4-peter.maydell@linaro.org
* hw/arm/boot: Diagnose layouts that put initrd or DTB off the end of RAMPeter Maydell2019-06-171-0/+23
| | | | | | | | | | | | | | | | We calculate the locations in memory where we want to put the initrd and the DTB based on the size of the kernel, since they come after it. Add some explicit checks that these aren't off the end of RAM entirely. (At the moment the way we calculate the initrd_start means that it can't ever be off the end of RAM, but that will change with the next commit.) Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Mark Rutland <mark.rutland@arm.com> Message-id: 20190516144733.32399-3-peter.maydell@linaro.org
* hw/arm/boot: Don't assume RAM starts at address zeroPeter Maydell2019-06-171-5/+4Star
| | | | | | | | | | | | | | | | | In the Arm kernel/initrd loading code, in some places we make the incorrect assumption that info->ram_size can be treated as the address of the end of RAM, as for instance when we calculate the available space for the initrd using "info->ram_size - info->initrd_start". This is wrong, because many Arm boards (including "virt") specify a non-zero info->loader_start to indicate that their RAM area starts at a non-zero physical address. Correct the places which make this incorrect assumption. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Mark Rutland <mark.rutland@arm.com> Message-id: 20190516144733.32399-2-peter.maydell@linaro.org
* q35: fix mmconfig and PCI0._CRSGerd Hoffmann2019-06-162-23/+22Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch changes the handling of the mmconfig area. Thanks to the pci(e) expander devices we already have the logic to exclude address ranges from PCI0._CRS. We can simply add the mmconfig address range to the list get it excluded as well. With that in place we can go with a fixed pci hole which covers the whole area from the end of (low) ram to the ioapic. This will make the whole logic alot less fragile. No matter where the firmware places the mmconfig xbar, things should work correctly. The guest also gets a bit more PCI address space (seabios boot): # cat /proc/iomem [ ... ] 7ffdd000-7fffffff : reserved 80000000-afffffff : PCI Bus 0000:00 <<-- this is new b0000000-bfffffff : PCI MMCONFIG 0000 [bus 00-ff] b0000000-bfffffff : reserved c0000000-febfffff : PCI Bus 0000:00 f8000000-fbffffff : 0000:00:01.0 [ ... ] So this is a guest visible change. Cc: László Érsek <lersek@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20190607073429.3436-1-kraxel@redhat.com>
* hw/acpi: extract acpi_add_rom_blob()Wei Yang2019-06-164-33/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | arm and i386 has almost the same function acpi_add_rom_blob(), except giving different FWCfgCallback function. This patch moves acpi_add_rom_blob() to utils.c by passing FWCfgCallback to it. Signed-off-by: Wei Yang <richardw.yang@linux.intel.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> v7: * rebase on top of current master because of conflict v6: * change author from Igor to Michael v5: * remove unnecessary header glib/gprintf.h * rearrange include header to make it more suitable v4: * extract -> moves * adjust comment in source to make checkpatch happy v3: * put acpi_add_rom_blob() to hw/acpi/utils.c v2: * remove unused header in original source file Message-Id: <20190610011830.28398-1-richardw.yang@linux.intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* vhost: fix vhost_log size overflow during migrationLi Hangjing2019-06-161-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a guest which doesn't support multiqueue is migrated with a multi queues vhost-user-blk deivce, a crash will occur like: 0 qemu_memfd_alloc (name=<value optimized out>, size=562949953421312, seals=<value optimized out>, fd=0x7f87171fe8b4, errp=0x7f87171fe8a8) at util/memfd.c:153 1 0x00007f883559d7cf in vhost_log_alloc (size=70368744177664, share=true) at hw/virtio/vhost.c:186 2 0x00007f88355a0758 in vhost_log_get (listener=0x7f8838bd7940, enable=1) at qemu-2-12/hw/virtio/vhost.c:211 3 vhost_dev_log_resize (listener=0x7f8838bd7940, enable=1) at hw/virtio/vhost.c:263 4 vhost_migration_log (listener=0x7f8838bd7940, enable=1) at hw/virtio/vhost.c:787 5 0x00007f88355463d6 in memory_global_dirty_log_start () at memory.c:2503 6 0x00007f8835550577 in ram_init_bitmaps (f=0x7f88384ce600, opaque=0x7f8836024098) at migration/ram.c:2173 7 ram_init_all (f=0x7f88384ce600, opaque=0x7f8836024098) at migration/ram.c:2192 8 ram_save_setup (f=0x7f88384ce600, opaque=0x7f8836024098) at migration/ram.c:2219 9 0x00007f88357a419d in qemu_savevm_state_setup (f=0x7f88384ce600) at migration/savevm.c:1002 10 0x00007f883579fc3e in migration_thread (opaque=0x7f8837530400) at migration/migration.c:2382 11 0x00007f8832447893 in start_thread () from /lib64/libpthread.so.0 12 0x00007f8832178bfd in clone () from /lib64/libc.so.6 This is because vhost_get_log_size() returns a overflowed vhost-log size. In this function, it uses the uninitialized variable vqs->used_phys and vqs->used_size to get the vhost-log size. Signed-off-by: Li Hangjing <lihangjing@baidu.com> Reviewed-by: Xie Yongji <xieyongji@baidu.com> Reviewed-by: Chai Wen <chaiwen@baidu.com> Message-Id: <20190603061524.24076-1-lihangjing@baidu.com> Cc: qemu-stable@nongnu.org Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* hw/block/fdc: floppy command FIFO memory initializationAndrey Shinkevich2019-06-141-0/+1
| | | | | | | | | | | | | | The uninitialized memory allocated for the command FIFO of the floppy controller during the VM hardware initialization incurs many unwanted reports by Valgrind when VM state is being saved. That verbosity hardens a search for the real memory issues when the iotests run. Particularly, the patch eliminates 20 unnecessary reports of the Valgrind tool in the iotest #169. Signed-off-by: Andrey Shinkevich <andrey.shinkevich@virtuozzo.com> Message-id: 1559154027-282547-1-git-send-email-andrey.shinkevich@virtuozzo.com Reviewed-by: John Snow <jsnow@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
* vfio/common: Introduce vfio_set_irq_signaling helperEric Auger2019-06-133-211/+152Star
| | | | | | | | | | | | | | | The code used to assign an interrupt index/subindex to an eventfd is duplicated many times. Let's introduce an helper that allows to set/unset the signaling for an ACTION_TRIGGER, ACTION_MASK or ACTION_UNMASK action. In the error message, we now use errno in case of any VFIO_DEVICE_SET_IRQS ioctl failure. Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Li Qiang <liq3ea@gmail.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
* vfio/pci: Allow MSI-X relocation to fixup bogus PBAAlex Williamson2019-06-131-1/+1
| | | | | | | | | The MSI-X relocation code can sometimes be used to work around bogus MSI-X capabilities, but this test for whether the PBA is outside of the specified BAR causes the device to error before we can apply a relocation. Let it proceed if we intend to relocate MSI-X anyway. Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
* vfio/pci: Hide Resizable BAR capabilityAlex Williamson2019-06-131-0/+1
| | | | | | | | | | | | | | | | | | The resizable BAR capability is currently exposed read-only from the kernel and we don't yet implement a protocol for virtualizing it to the VM. Exposing it to the guest read-only introduces poor behavior as the guest has no reason to test that a control register write is accepted by the hardware. This can lead to cases where the guest OS assumes the BAR has been resized, but it hasn't. This has been observed when assigning AMD Vega GPUs. Note, this does not preclude future enablement of resizable BARs, but it's currently incorrect to expose this capability as read-only, so better to not expose it at all. Reported-by: James Courtier-Dutton <james.dutton@gmail.com> Tested-by: James Courtier-Dutton <james.dutton@gmail.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
* hw/core/bus.c: Only the main system bus can have no parentPeter Maydell2019-06-131-12/+9Star
| | | | | | | | | | | | | | | | | | | | | | | | In commit 80376c3fc2c38fdd453 in 2010 we added a workaround for some qbus buses not being connected to qdev devices -- if the bus has no parent object then we register a reset function which resets the bus on system reset (and unregister it when the bus is unparented). Nearly a decade later, we have now no buses in the tree which are created with non-NULL parents, so we can remove the workaround and instead just assert that if the bus has a NULL parent then it is the main system bus. (The absence of other parentless buses was confirmed by code inspection of all the callsites of qbus_create() and qbus_create_inplace() and cross-checked by 'make check'.) Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Damien Hedde <damien.hedde@greensocs.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20190523150543.22676-1-peter.maydell@linaro.org
* hw/arm/smmuv3: Fix decoding of ID register rangePeter Maydell2019-06-131-1/+1
| | | | | | | | | | The SMMUv3 ID registers cover an area 0x30 bytes in size (12 registers, 4 bytes each). We were incorrectly decoding only the first 0x20 bytes. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Eric Auger <eric.auger@redhat.com> Message-id: 20190524124829.2589-1-peter.maydell@linaro.org
* Merge remote-tracking branch 'remotes/kraxel/tags/vga-20190613-pull-request' ↵Peter Maydell2019-06-133-4/+10
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | into staging edid: add xmax + ymax properties, enable by default. # gpg: Signature made Thu 13 Jun 2019 08:38:18 BST # gpg: using RSA key 4CB6D8EED3E87138 # gpg: Good signature from "Gerd Hoffmann (work) <kraxel@redhat.com>" [full] # gpg: aka "Gerd Hoffmann <gerd@kraxel.org>" [full] # gpg: aka "Gerd Hoffmann (private) <kraxel@gmail.com>" [full] # Primary key fingerprint: A032 8CFF B93A 17A7 9901 FE7D 4CB6 D8EE D3E8 7138 * remotes/kraxel/tags/vga-20190613-pull-request: edid: flip the default to enabled edid: add xmax + ymax properties Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
| * edid: flip the default to enabledGerd Hoffmann2019-06-133-4/+10
| | | | | | | | | | | | Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-id: 20190607083444.32175-1-kraxel@redhat.com
* | semihosting: split console_out into string and char versionsAlex Bennée2019-06-121-9/+25
|/ | | | | | | | | This is ostensibly to avoid the weirdness of len looking like it might come from a guest and sometimes being used. While we are at it fix up the error checking for the arm-linux-user implementation of the API which got flagged up by Coverity (CID 1401700). Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
* Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-4.1-20190612' ↵Peter Maydell2019-06-125-205/+354
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | into staging ppc patch queue 2019-06-12 Next pull request against qemu-4.1. The big thing here is adding support for hot plug of P2P bridges, and PCI devices under P2P bridges on the "pseries" machine (which doesn't use SHPC). Other than that there's just a handful of fixes and small enhancements. # gpg: Signature made Wed 12 Jun 2019 06:47:56 BST # gpg: using RSA key 75F46586AE61A66CC44E87DC6C38CACA20D9B392 # gpg: Good signature from "David Gibson <david@gibson.dropbear.id.au>" [full] # gpg: aka "David Gibson (Red Hat) <dgibson@redhat.com>" [full] # gpg: aka "David Gibson (ozlabs.org) <dgibson@ozlabs.org>" [full] # gpg: aka "David Gibson (kernel.org) <dwg@kernel.org>" [unknown] # Primary key fingerprint: 75F4 6586 AE61 A66C C44E 87DC 6C38 CACA 20D9 B392 * remotes/dgibson/tags/ppc-for-4.1-20190612: ppc/xive: Make XIVE generate the proper interrupt types ppc/pnv: activate the "dumpdtb" option on the powernv machine target/ppc: Use tcg_gen_gvec_bitsel spapr: Allow hot plug/unplug of PCI bridges and devices under PCI bridges spapr: Direct all PCI hotplug to host bridge, rather than P2P bridge spapr: Don't use bus number for building DRC ids spapr: Clean up DRC index construction spapr: Clean up spapr_drc_populate_dt() spapr: Clean up dt creation for PCI buses spapr: Clean up device tree construction for PCI devices spapr: Clean up device node name generation for PCI devices target/ppc: Fix lxvw4x, lxvh8x and lxvb16x spapr_pci: Improve error message Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
| * ppc/xive: Make XIVE generate the proper interrupt typesBenjamin Herrenschmidt2019-06-121-3/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It should be generic Hypervisor Virtualization interrupts for HV directed rings and traditional External Interrupts for the OS directed ring. Don't generate anything for the user ring as it isn't actually supported. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20190606174409.12502-1-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
| * ppc/pnv: activate the "dumpdtb" option on the powernv machineCédric Le Goater2019-06-121-0/+2
| | | | | | | | | | | | | | | | | | | | This is a good way to debug the DT creation for current PowerNV machines and new ones to come. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20190606174732.13051-1-clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
| * spapr: Allow hot plug/unplug of PCI bridges and devices under PCI bridgesDavid Gibson2019-06-121-13/+102
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The pseries machine type already allows PCI hotplug and unplug via the PAPR mechanism, but only on the root bus of each PHB. This patch extends this to allow PCI to PCI bridges to be hotplugged, and devices to be hotplugged or unplugged under P2P bridges. For now we disallow hot unplugging P2P bridges. I tried doing that, but haven't managed to get it working, I think due to some guest side problems that need further investigation. To do this we dynamically construct DRCs when bridges are hot (or cold) added, which can in turn be used to hotplug devices under the bridge. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Acked-by: Michael S. Tsirkin <mst@redhat.com>
| * spapr: Direct all PCI hotplug to host bridge, rather than P2P bridgeDavid Gibson2019-06-121-0/+11
| | | | | | | | | | | | | | | | | | | | A P2P bridge will attempt to handle the hotplug with SHPC, which doesn't work in the PAPR environment. Instead we want to direct all PCI hotplug actions to the PAPR specific host bridge which will use the PAPR hotplug mechanism. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Acked-by: Michael S. Tsirkin <mst@redhat.com>
| * spapr: Don't use bus number for building DRC idsDavid Gibson2019-06-121-14/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DRC ids are more or less arbitrary, as long as they're consistent. For PCI, we notionally build them from the phb's index along with PCI bus number, slot and function number. Using bus number is broken, however, because it can change if the guest re-enumerates the PCI topology for whatever reason (e.g. due to hotplug of a bridge, which we don't support yet but want to). Fortunately, there's an alternative. Bridges are required to have a unique non-zero "chassis number" that we can use instead. Adjust the code to use that instead. This looks like it would introduce a guest visible breaking change, but in fact it does not because we don't yet ever use non-zero bus numbers. Both chassis and bus number are always 0 for the root bus, so there's no change for the existing cases. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Acked-by: Michael S. Tsirkin <mst@redhat.com>
| * spapr: Clean up DRC index constructionDavid Gibson2019-06-121-56/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | | spapr_pci.c currently has several confusingly similarly named functions for various conversions between representations of DRCs. Make things clearer by renaming things in a more consistent XXX_from_YYY() manner and remove some called-only-once variants in favour of open coding. While we're at it, move this code together in the file to avoid some extra forward references, and split out construction and removal of DRCs for the host bridge into helper functions. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Acked-by: Michael S. Tsirkin <mst@redhat.com>
| * spapr: Clean up spapr_drc_populate_dt()David Gibson2019-06-123-13/+10Star
| | | | | | | | | | | | | | | | | | This makes some minor cleanups to spapr_drc_populate_dt(), renaming it to the shorter and more idiomatic spapr_dt_drc() along the way. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Acked-by: Michael S. Tsirkin <mst@redhat.com>