aboutsummaryrefslogtreecommitdiff
path: root/hw
AgeCommit message (Collapse)Author
2019-07-01Merge remote-tracking branch 'remotes/aperard/tags/pull-xen-20190624' into ↵Peter Maydell
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>
2019-06-28ati-vga: switch to vgabios-ati.binGerd Hoffmann
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Tested-by: BALATON Zoltan <balaton@eik.bme.hu> Message-id: 20190620151104.2678-4-kraxel@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-06-28ati-vga: Fixes to offset and pitch registersBALATON Zoltan
Fix bit masks of registers for offset and pitch and also handle default values for both R128P and RV100. This improves picture a bit but does not resolve all problems yet so there might be some more bugs somewhere. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-id: 20190624100005.7A1CA746395@zero.eik.bme.hu Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-06-28ati-vga: Implement DDC and EDID info from monitorBALATON Zoltan
This adds DDC support to ati-vga and connects i2c-ddc to it. This allows at least MacOS with an ATI ndrv, Linux radeonfb and MorphOS to get monitor EDID info (although MorphOS splash screen is not displayed and radeonfb needs additional tables from vgabios-rv100). Xorg needs additional support from VESA vgabios, it's missing INT10 0x4F15 function (see https://gitlab.freedesktop.org/xorg/xserver/blob/master/hw/xfree86/vbe/vbe.c) without which no DDC is available that also prevents loading the accelerated X driver. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-id: 046ddebb7ec8db48c4e877ee444ec1c41e385a74.1561028123.git.balaton@eik.bme.hu ati-vga: Clarify comment Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-id: 20190620195213.C54127461AE@zero.eik.bme.hu ati-vga: Add DDC reg names for debug Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-id: 20190621181459.2F8207462AA@zero.eik.bme.hu Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-06-28i2c: Move bitbang_i2c.h to include/hw/i2c/BALATON Zoltan
The bitbang i2c implementation is also useful for other device models such as DDC in display controllers. Move the header to include/hw/i2c/ to allow it to be used from other device models and adjust users of this include. This also reverts commit 2b4c1125ac which is no longer needed. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Acked-by: Corey Minyard <cminyard@mvista.com> Message-id: 5d1fe4db846ab9be4b77ddb0d43cc74cd200a003.1561028123.git.balaton@eik.bme.hu Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-06-27hw/riscv: Extend the kernel loading supportAlistair Francis
Extend the RISC-V kernel loader to support Image and uImage files. A Linux kernel can now be booted with: qemu-system-riscv64 -machine virt -bios fw_jump.bin -kernel Image Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com> Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
2019-06-27hw/riscv: Add support for loading a firmwareAlistair Francis
Add support for loading a firmware file for the virt machine and the SiFive U. This can be run with the following command: qemu-system-riscv64 -machine virt -bios fw_jump.bin -kernel vmlinux Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com> Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
2019-06-27hw/riscv: Split out the boot functionsAlistair Francis
Split the common RISC-V boot functions into a seperate file. This allows us to share the common code. Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com> Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
2019-06-27riscv: sifive_u: Update the plic hart config to support multicoreBin Meng
At present the PLIC is instantiated to support only one hart, while the machine allows at most 4 harts to be created. When more than 1 hart is configured, PLIC needs to instantiated to support multicore, otherwise an SMP OS does not work. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
2019-06-27riscv: sifive_u: Do not create hard-coded phandles in DTBin Meng
At present the cpu, plic and ethclk nodes' phandles are hard-coded to 1/2/3 in DT. If we configure more than 1 cpu for the machine, all cpu nodes' phandles conflict with each other as they are all 1. Fix it by removing the hardcode. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
2019-06-26dma/rc4030: Minor code style cleanupAleksandar Markovic
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>
2019-06-26dma/rc4030: Fix off-by-one error in specified memory region sizeAleksandar Markovic
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>
2019-06-26hw/mips/gt64xxx_pci: Align the pci0-mem sizePhilippe Mathieu-Daudé
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>
2019-06-26hw/mips/gt64xxx_pci: Convert debug printf()s to trace eventsPhilippe Mathieu-Daudé
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Aleksandar Markovic <amarkovic@wavecomp.com> Message-Id: <20190624222844.26584-7-f4bug@amsat.org>
2019-06-26hw/mips/gt64xxx_pci: Use qemu_log_mask() instead of debug printf()Philippe Mathieu-Daudé
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Aleksandar Markovic <amarkovic@wavecomp.com> Message-Id: <20190624222844.26584-6-f4bug@amsat.org>
2019-06-26hw/mips/gt64xxx_pci: Fix 'spaces' coding style issuesPhilippe Mathieu-Daudé
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>
2019-06-26hw/mips/gt64xxx_pci: Fix 'braces' coding style issuesPhilippe Mathieu-Daudé
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>
2019-06-26hw/mips/gt64xxx_pci: Fix 'tabs' coding style issuesPhilippe Mathieu-Daudé
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>
2019-06-26hw/mips/gt64xxx_pci: Fix multiline comment syntaxPhilippe Mathieu-Daudé
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>
2019-06-25riscv: virt: Add cpu-topology DT node.Atish Patra
Currently, there is no cpu topology defined in RISC-V. Define a device tree node that clearly describes the entire topology. This saves the trouble of scanning individual cache to figure out the topology. Here is the linux kernel patch series that enables topology for RISC-V. http://lists.infradead.org/pipermail/linux-riscv/2019-June/005072.html CPU topology after applying this patch in QEMU & above series in kernel / # cat /sys/devices/system/cpu/cpu2/topology/thread_siblings_list 2 / # cat /sys/devices/system/cpu/cpu2/topology/physical_package_id 0 / # cat /sys/devices/system/cpu/cpu2/topology/core_siblings_list 0-7 Signed-off-by: Atish Patra <atish.patra@wdc.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
2019-06-24vfio-ccw: support async command subregionCornelia Huck
A vfio-ccw device may provide an async command subregion for issuing halt/clear subchannel requests. If it is present, use it for sending halt/clear request to the device; if not, fall back to emulation (as done today). Reviewed-by: Farhan Ali <alifm@linux.ibm.com> Message-Id: <20190613092542.2834-1-cohuck@redhat.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-06-24vfio-ccw: use vfio_set_irq_signalingCornelia Huck
Use the new helper. Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Message-Id: <20190617101036.4087-1-cohuck@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-06-24nvme: do not advertise support for unsupported arbitration mechanismKlaus Birkelund Jensen
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>
2019-06-24xen: Import other xen/io/*.hAnthony PERARD
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>
2019-06-24xen: Drop includes of xen/hvm/params.hAnthony PERARD
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>
2019-06-24xen: Avoid VLAAnthony PERARD
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>
2019-06-24xen-bus / xen-block: add support for event channel pollingPaul Durrant
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>
2019-06-24xen-bus: allow AioContext to be specified for each event channelPaul Durrant
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>
2019-06-24xen-bus: use a separate fd for each event channelPaul Durrant
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>
2019-06-24xen-block: support feature-large-sector-sizePaul Durrant
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>
2019-06-23RISC-V: Fix a memory leak when realizing a sifive_ePalmer Dabbelt
Coverity pointed out a memory leak in riscv_sifive_e_soc_realize(), where a pair of recently added MemoryRegion instances would not be freed if there were errors elsewhere in the function. The fix here is to simply not use dynamic allocation for these instances: there's always one of each in SiFiveESoCState, so instead we just include them within the struct. Fixes: 30efbf330a45 ("SiFive RISC-V GPIO Device") Signed-off-by: Palmer Dabbelt <palmer@sifive.com> Suggested-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
2019-06-23riscv: virt: Correct pci "bus-range" encodingBin Meng
The largest pci bus number should be calculated from ECAM size, instead of its base address. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
2019-06-23sifive_prci: Read and write PRCI registersNathaniel Graff
Writes to the SiFive PRCI registers are preserved while leaving the ready bits set for the HFX/HFR oscillators and the lock bit set for the PLL. Signed-off-by: Nathaniel Graff <nathaniel.graff@sifive.com> Reviewed-by: Michael Clark <mjc@sifive.com> Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
2019-06-21hw: Nuke hw_compat_4_0_1 and pc_compat_4_0_1Greg Kurz
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>
2019-06-21sd: Fix out-of-bounds assertionsLidong Chen
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>
2019-06-21i386/kvm: convert hyperv enlightenments properties from bools to bitsVitaly Kuznetsov
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>
2019-06-17hw/intc/arm_gicv3: GICD_TYPER.SecurityExtn is RAZ if GICD_CTLR.DS == 1Peter Maydell
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
2019-06-17hw/intc/arm_gicv3: Fix decoding of ID register rangePeter Maydell
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
2019-06-17hw/arm: Correctly disable FPU/DSP for some ARMSSE-based boardsPeter Maydell
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
2019-06-17hw/arm/armv7m: Forward "vfp" and "dsp" properties to CPUPeter Maydell
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
2019-06-17hw/arm/boot: Honour image size field in AArch64 Image format kernelsPeter Maydell
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
2019-06-17hw/arm/boot: Avoid placing the initrd on top of the kernelPeter Maydell
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
2019-06-17hw/arm/boot: Diagnose layouts that put initrd or DTB off the end of RAMPeter Maydell
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
2019-06-17hw/arm/boot: Don't assume RAM starts at address zeroPeter Maydell
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
2019-06-16q35: fix mmconfig and PCI0._CRSGerd Hoffmann
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>
2019-06-16hw/acpi: extract acpi_add_rom_blob()Wei Yang
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>
2019-06-16vhost: fix vhost_log size overflow during migrationLi Hangjing
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>
2019-06-14hw/block/fdc: floppy command FIFO memory initializationAndrey Shinkevich
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>
2019-06-13vfio/common: Introduce vfio_set_irq_signaling helperEric Auger
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>
2019-06-13vfio/pci: Allow MSI-X relocation to fixup bogus PBAAlex Williamson
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>
generated by cgit v1.2.3 (git 2.26.2) at 2025-03-16 08:23:47 +0000