aboutsummaryrefslogtreecommitdiff
path: root/hw
AgeCommit message (Collapse)Author
2021-07-09hw/gpio/pl061: Make pullup/pulldown of outputs configurablePeter Maydell
The PL061 GPIO does not itself include pullup or pulldown resistors to set the value of a GPIO line treated as an output when it is configured as an input (ie when the PL061 itself is not driving it). In real hardware it is up to the board to add suitable pullups or pulldowns. Currently our implementation hardwires this to "outputs pulled high", which is correct for some boards (eg the realview ones: see figure 3-29 in the "RealView Platform Baseboard for ARM926EJ-S User Guide" DUI0224I), but wrong for others. In particular, the wiring in the 'virt' board and the gpio-pwr device assumes that wires should be pulled low, because otherwise the pull-to-high will trigger a shutdown or reset action. (The only reason this doesn't happen immediately on startup is due to another bug in the PL061, where we don't assert the GPIOs to the correct value on reset, but will do so as soon as the guest touches a register and pl061_update() gets called.) Add properties to the pl061 so the board can configure whether it wants GPIO lines to have pullup, pulldown, or neither. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
2021-07-09hw/gpio/pl061: Honour Luminary PL061 PUR and PDR registersPeter Maydell
The Luminary variant of the PL061 has registers GPIOPUR and GPIOPDR which lets the guest configure whether the GPIO lines are pull-up, pull-down, or truly floating. Instead of assuming all lines are pulled high, honour the PUR and PDR registers. For the plain PL061, continue to assume that lines have an external pull-up resistor, as we did before. The stellaris board actually relies on this behaviour -- the CD line of the ssd0323 display device is connected to GPIO output C7, and it is only because of a different bug which we're about to fix that we weren't incorrectly driving this line high on reset and putting the ssd0323 into data mode. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
2021-07-09hw/gpio/pl061: Document the interface of this devicePeter Maydell
Add a comment documenting the "QEMU interface" of this device: which MMIO regions, IRQ lines, GPIO lines, etc it exposes. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
2021-07-09hw/gpio/pl061: Add tracepoints for register read and writePeter Maydell
Add tracepoints for reads and writes to the PL061 registers. This requires restructuring pl061_read() to only return after the tracepoint, rather than having lots of early-returns. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
2021-07-09hw/gpio/pl061: Clean up read/write offset handling logicPeter Maydell
Currently the pl061_read() and pl061_write() functions handle offsets using a combination of three if() statements and a switch(). Clean this up to use just a switch, using case ranges. This requires that instead of catching accesses to the luminary-only registers on a stock PL061 via a check on s->rsvd_start we use an "is this luminary?" check in the cases for each luminary-only register. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
2021-07-09hw/gpio/pl061: Convert DPRINTF to tracepointsPeter Maydell
Convert the use of the DPRINTF debug macro in the PL061 model to use tracepoints. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
2021-07-09hw/intc/arm_gicv3_cpuif: Fix virtual irq number check in icv_[dir|eoir]_writeRicardo Koller
icv_eoir_write() and icv_dir_write() ignore invalid virtual IRQ numbers (like LPIs). The issue is that these functions check against the number of implemented IRQs (QEMU's default is num_irq=288) which can be lower than the maximum virtual IRQ number (1020 - 1). The consequence is that if a hypervisor creates an LR for an IRQ between 288 and 1020, then the guest is unable to deactivate the resulting IRQ. Note that other functions that deal with large IRQ numbers, like icv_iar_read, check against 1020 and not against num_irq. Fix the checks by using GICV3_MAXIRQ (1020) instead of the number of implemented IRQs. Signed-off-by: Ricardo Koller <ricarkol@google.com> Message-id: 20210702233701.3369-1-ricarkol@google.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-07-09stm32vldiscovery: Add the STM32VLDISCOVERY MachineAlexandre Iooss
This is a Cortex-M3 based machine. Information can be found at: https://www.st.com/en/evaluation-tools/stm32vldiscovery.html Signed-off-by: Alexandre Iooss <erdnaxe@crans.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20210617165647.2575955-3-erdnaxe@crans.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-07-09stm32f100: Add the stm32f100 SoCAlexandre Iooss
This SoC is similar to stm32f205 SoC. This will be used by the STM32VLDISCOVERY to create a machine. Signed-off-by: Alexandre Iooss <erdnaxe@crans.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20210617165647.2575955-2-erdnaxe@crans.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-07-09Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into stagingPeter Maydell
pc,pci,virtio: bugfixes, improvements vhost-user-rng support. Fixes all over the place. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> # gpg: Signature made Wed 07 Jul 2021 14:29:30 BST # gpg: using RSA key 5D09FD0871C8F85B94CA8A0D281F0DB8D28D5469 # gpg: issuer "mst@redhat.com" # gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>" [full] # gpg: aka "Michael S. Tsirkin <mst@redhat.com>" [full] # Primary key fingerprint: 0270 606B 6F3C DF3D 0B17 0970 C350 3912 AFBE 8E67 # Subkey fingerprint: 5D09 FD08 71C8 F85B 94CA 8A0D 281F 0DB8 D28D 5469 * remotes/mst/tags/for_upstream: MAINTAINERS: Add maintainer for vhost-user RNG implementation docs: add slot when adding new PCIe root port acpi/ged: fix reset cause tests: acpi: pc: update expected DSDT blobs acpi: pc: revert back to v5.2 PCI slot enumeration tests: acpi: prepare for changing DSDT tables migration: failover: reset partially_hotplugged virtio-pci: Changed return values for "notify", "device" and "isr" read. virtio-pci: Added check for virtio device in PCI config cbs. virtio-pci: Added check for virtio device presence in mm callbacks. hw/pci-host/q35: Ignore write of reserved PCIEXBAR LENGTH field virtio: Clarify MR transaction optimization virtio: disable ioeventfd for record/replay Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-07-09vhost-user: Fix backends without multiqueue supportKevin Wolf
dev->max_queues was never initialised for backends that don't support VHOST_USER_PROTOCOL_F_MQ, so it would use 0 as the maximum number of queues to check against and consequently fail for any such backend. Set it to 1 if the backend doesn't have multiqueue support. Fixes: c90bd505a3e8210c23d69fecab9ee6f56ec4a161 Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20210705171429.29286-1-kwolf@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Raphael Norwitz <raphael.norwitz@nutanix.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2021-07-09target/ppc: Support for H_RPT_INVALIDATE hcallBharata B Rao
If KVM_CAP_RPT_INVALIDATE KVM capability is enabled, then - indicate the availability of H_RPT_INVALIDATE hcall to the guest via ibm,hypertas-functions property. - Enable the hcall Both the above are done only if the new sPAPR machine capability cap-rpt-invalidate is set. Signed-off-by: Bharata B Rao <bharata@linux.ibm.com> Message-Id: <20210706112440.1449562-3-bharata@linux.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-07-09spapr: Fix implementation of Open Firmware client interfaceAlexey Kardashevskiy
This addresses the comments from v22. The functional changes are (the VOF ones need retesting with Pegasos2): (VOF) setprop will start failing if the machine class callback did not handle it; (VOF) unit addresses are lowered in path_offset(); (SPAPR) /chosen/bootargs is initialized from kernel_cmdline if the client did not change it. Fixes: 5c991e5d4378 ("spapr: Implement Open Firmware client interface") Cc: BALATON Zoltan <balaton@eik.bme.hu> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Message-Id: <20210708065625.548396-1-aik@ozlabs.ru> Tested-by: BALATON Zoltan <balaton@eik.bme.hu> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-07-09ppc/pegasos2: Implement some RTAS functions with VOFBALATON Zoltan
Linux uses RTAS functions to access PCI devices so we need to provide these with VOF. Implement some of the most important functions to allow booting Linux with VOF. With this the board is now usable without a binary ROM image and we can enable it by default as other boards. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <20210708215113.B3F747456E3@zero.eik.bme.hu> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-07-09ppc/pegasos2: Fix use of && instead of &David Gibson
This is obviously intended to be a mask, not a logical operation. Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-07-09ppc/pegasos2: Use Virtual Open Firmware as firmware replacementBALATON Zoltan
The pegasos2 board comes with an Open Firmware compliant ROM based on SmartFirmware but it has some changes that are not open source therefore the ROM binary cannot be included in QEMU. Guests running on the board however depend on services provided by the firmware. The Virtual Open Firmware recently added to QEMU implements a minimal set of these services to allow some guests to boot without the original firmware. This patch adds VOF as the default firmware for pegasos2 which allows booting Linux and MorphOS via -kernel option while a ROM image can still be used with -bios for guests that don't run with VOF. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <1d6ed6f290c5c1f0b5a1e1c51cf1151452d70d9a.1624811233.git.balaton@eik.bme.hu> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-07-09target/ppc/spapr: Update H_GET_CPU_CHARACTERISTICS L1D cache flush bitsNicholas Piggin
There are several new L1D cache flush bits added to the hcall which reflect hardware security features for speculative cache access issues. These behaviours are now being specified as negative in order to simplify patched kernel compatibility with older firmware (a new problem found in existing systems would automatically be vulnerable). [dwg: Technically this changes behaviour for existing machine types. After discussion with Nick, we've determined this is safe, because the worst that will happen if a guest gets the wrong information due to a migration is that it will perform some unnecessary workarounds, but will remain correct and secure (well, as secure as it was going to be anyway). In addition the change only affects cap-cfpc=safe which is not enabled by default, and in fact is not possible to set on any current hardware (though it's expected it will be possible on POWER10)] Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Message-Id: <20210615044107.1481608-1-npiggin@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-07-09ppc/pegasos2: Introduce Pegasos2MachineState structureBALATON Zoltan
Add own machine state structure which will be used to store state needed for firmware emulation. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <7f6d5fbf4f70c64dba001483174a2921dd616ecd.1624811233.git.balaton@eik.bme.hu> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-07-09spapr: Implement Open Firmware client interfaceAlexey Kardashevskiy
The PAPR platform describes an OS environment that's presented by a combination of a hypervisor and firmware. The features it specifies require collaboration between the firmware and the hypervisor. Since the beginning, the runtime component of the firmware (RTAS) has been implemented as a 20 byte shim which simply forwards it to a hypercall implemented in qemu. The boot time firmware component is SLOF - but a build that's specific to qemu, and has always needed to be updated in sync with it. Even though we've managed to limit the amount of runtime communication we need between qemu and SLOF, there's some, and it has become increasingly awkward to handle as we've implemented new features. This implements a boot time OF client interface (CI) which is enabled by a new "x-vof" pseries machine option (stands for "Virtual Open Firmware). When enabled, QEMU implements the custom H_OF_CLIENT hcall which implements Open Firmware Client Interface (OF CI). This allows using a smaller stateless firmware which does not have to manage the device tree. The new "vof.bin" firmware image is included with source code under pc-bios/. It also includes RTAS blob. This implements a handful of CI methods just to get -kernel/-initrd working. In particular, this implements the device tree fetching and simple memory allocator - "claim" (an OF CI memory allocator) and updates "/memory@0/available" to report the client about available memory. This implements changing some device tree properties which we know how to deal with, the rest is ignored. To allow changes, this skips fdt_pack() when x-vof=on as not packing the blob leaves some room for appending. In absence of SLOF, this assigns phandles to device tree nodes to make device tree traversing work. When x-vof=on, this adds "/chosen" every time QEMU (re)builds a tree. This adds basic instances support which are managed by a hash map ihandle -> [phandle]. Before the guest started, the used memory is: 0..e60 - the initial firmware 8000..10000 - stack 400000.. - kernel 3ea0000.. - initramdisk This OF CI does not implement "interpret". Unlike SLOF, this does not format uninitialized nvram. Instead, this includes a disk image with pre-formatted nvram. With this basic support, this can only boot into kernel directly. However this is just enough for the petitboot kernel and initradmdisk to boot from any possible source. Note this requires reasonably recent guest kernel with: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=df5be5be8735 The immediate benefit is much faster booting time which especially crucial with fully emulated early CPU bring up environments. Also this may come handy when/if GRUB-in-the-userspace sees light of the day. This separates VOF and sPAPR in a hope that VOF bits may be reused by other POWERPC boards which do not support pSeries. This assumes potential support for booting from QEMU backends such as blockdev or netdev without devices/drivers used. Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Message-Id: <20210625055155.2252896-1-aik@ozlabs.ru> Reviewed-by: BALATON Zoltan <balaton@eik.bme.hu> [dwg: Adjusted some includes which broke compile in some more obscure compilation setups] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-07-09spapr: tune rtas-sizeAlexey Kardashevskiy
QEMU reserves space for RTAS via /rtas/rtas-size which tells the client how much space the RTAS requires to work which includes the RTAS binary blob implementing RTAS runtime. Because pseries supports FWNMI which requires plenty of space, QEMU reserves more than 2KB which is enough for the RTAS blob as it is just 20 bytes (under QEMU). Since FWNMI reset delivery was added, RTAS_SIZE macro is not used anymore. This replaces RTAS_SIZE with RTAS_MIN_SIZE and uses it in the /rtas/rtas-size calculation to account for the RTAS blob. Fixes: 0e236d347790 ("ppc/spapr: Implement FWNMI System Reset delivery") Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Message-Id: <20210622070336.1463250-1-aik@ozlabs.ru> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-07-08Merge remote-tracking branch ↵Peter Maydell
'remotes/stefanha-gitlab/tags/block-pull-request' into staging Pull request # gpg: Signature made Thu 08 Jul 2021 14:11:37 BST # gpg: using RSA key 8695A8BFD3F97CDAAC35775A9CA4ABB381AB73C8 # gpg: Good signature from "Stefan Hajnoczi <stefanha@redhat.com>" [full] # gpg: aka "Stefan Hajnoczi <stefanha@gmail.com>" [full] # Primary key fingerprint: 8695 A8BF D3F9 7CDA AC35 775A 9CA4 ABB3 81AB 73C8 * remotes/stefanha-gitlab/tags/block-pull-request: block/io: Merge discard request alignments block: Add backend_defaults property block/file-posix: Optimize for macOS util/async: print leaked BH name when AioContext finalizes util/async: add a human-readable name to BHs for debugging Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-07-08vfio: Disable only uncoordinated discards for VFIO_TYPE1 iommusDavid Hildenbrand
We support coordinated discarding of RAM using the RamDiscardManager for the VFIO_TYPE1 iommus. Let's unlock support for coordinated discards, keeping uncoordinated discards (e.g., via virtio-balloon) disabled if possible. This unlocks virtio-mem + vfio on x86-64. Note that vfio used via "nvme://" by the block layer has to be implemented/unlocked separately. For now, virtio-mem only supports x86-64; we don't restrict RamDiscardManager to x86-64, though: arm64 and s390x are supposed to work as well, and we'll test once unlocking virtio-mem support. The spapr IOMMUs will need special care, to be tackled later, e.g.., once supporting virtio-mem. Note: The block size of a virtio-mem device has to be set to sane sizes, depending on the maximum hotplug size - to not run out of vfio mappings. The default virtio-mem block size is usually in the range of a couple of MBs. The maximum number of mapping is 64k, shared with other users. Assume you want to hotplug 256GB using virtio-mem - the block size would have to be set to at least 8 MiB (resulting in 32768 separate mappings). Acked-by: Alex Williamson <alex.williamson@redhat.com> Reviewed-by: Alex Williamson <alex.williamson@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Dr. David Alan Gilbert <dgilbert@redhat.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Pankaj Gupta <pankaj.gupta.linux@gmail.com> Cc: Peter Xu <peterx@redhat.com> Cc: Auger Eric <eric.auger@redhat.com> Cc: Wei Yang <richard.weiyang@linux.alibaba.com> Cc: teawater <teawaterz@linux.alibaba.com> Cc: Marek Kedzierski <mkedzier@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20210413095531.25603-14-david@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-07-08virtio-mem: Require only coordinated discardsDavid Hildenbrand
We implement the RamDiscardManager interface and only require coordinated discarding of RAM to work. Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Pankaj Gupta <pankaj.gupta@cloud.ionos.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Dr. David Alan Gilbert <dgilbert@redhat.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Pankaj Gupta <pankaj.gupta.linux@gmail.com> Cc: Peter Xu <peterx@redhat.com> Cc: Auger Eric <eric.auger@redhat.com> Cc: Wei Yang <richard.weiyang@linux.alibaba.com> Cc: teawater <teawaterz@linux.alibaba.com> Cc: Marek Kedzierski <mkedzier@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20210413095531.25603-13-david@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-07-08vfio: Support for RamDiscardManager in the vIOMMU caseDavid Hildenbrand
vIOMMU support works already with RamDiscardManager as long as guests only map populated memory. Both, populated and discarded memory is mapped into &address_space_memory, where vfio_get_xlat_addr() will find that memory, to create the vfio mapping. Sane guests will never map discarded memory (e.g., unplugged memory blocks in virtio-mem) into an IOMMU - or keep it mapped into an IOMMU while memory is getting discarded. However, there are two cases where a malicious guests could trigger pinning of more memory than intended. One case is easy to handle: the guest trying to map discarded memory into an IOMMU. The other case is harder to handle: the guest keeping memory mapped in the IOMMU while it is getting discarded. We would have to walk over all mappings when discarding memory and identify if any mapping would be a violation. Let's keep it simple for now and print a warning, indicating that setting RLIMIT_MEMLOCK can mitigate such attacks. We have to take care of incoming migration: at the point the IOMMUs get restored and start creating mappings in vfio, RamDiscardManager implementations might not be back up and running yet: let's add runstate priorities to enforce the order when restoring. Acked-by: Alex Williamson <alex.williamson@redhat.com> Reviewed-by: Alex Williamson <alex.williamson@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Dr. David Alan Gilbert <dgilbert@redhat.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Pankaj Gupta <pankaj.gupta.linux@gmail.com> Cc: Peter Xu <peterx@redhat.com> Cc: Auger Eric <eric.auger@redhat.com> Cc: Wei Yang <richard.weiyang@linux.alibaba.com> Cc: teawater <teawaterz@linux.alibaba.com> Cc: Marek Kedzierski <mkedzier@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20210413095531.25603-10-david@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-07-08vfio: Sanity check maximum number of DMA mappings with RamDiscardManagerDavid Hildenbrand
Although RamDiscardManager can handle running into the maximum number of DMA mappings by propagating errors when creating a DMA mapping, we want to sanity check and warn the user early that there is a theoretical setup issue and that virtio-mem might not be able to provide as much memory towards a VM as desired. As suggested by Alex, let's use the number of KVM memory slots to guess how many other mappings we might see over time. Acked-by: Alex Williamson <alex.williamson@redhat.com> Reviewed-by: Alex Williamson <alex.williamson@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Dr. David Alan Gilbert <dgilbert@redhat.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Pankaj Gupta <pankaj.gupta.linux@gmail.com> Cc: Peter Xu <peterx@redhat.com> Cc: Auger Eric <eric.auger@redhat.com> Cc: Wei Yang <richard.weiyang@linux.alibaba.com> Cc: teawater <teawaterz@linux.alibaba.com> Cc: Marek Kedzierski <mkedzier@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20210413095531.25603-9-david@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-07-08vfio: Query and store the maximum number of possible DMA mappingsDavid Hildenbrand
Let's query the maximum number of possible DMA mappings by querying the available mappings when creating the container (before any mappings are created). We'll use this informaton soon to perform some sanity checks and warn the user. Reviewed-by: Alex Williamson <alex.williamson@redhat.com> Acked-by: Alex Williamson <alex.williamson@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Dr. David Alan Gilbert <dgilbert@redhat.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Pankaj Gupta <pankaj.gupta.linux@gmail.com> Cc: Peter Xu <peterx@redhat.com> Cc: Auger Eric <eric.auger@redhat.com> Cc: Wei Yang <richard.weiyang@linux.alibaba.com> Cc: teawater <teawaterz@linux.alibaba.com> Cc: Marek Kedzierski <mkedzier@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20210413095531.25603-8-david@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-07-08vfio: Support for RamDiscardManager in the !vIOMMU caseDavid Hildenbrand
Implement support for RamDiscardManager, to prepare for virtio-mem support. Instead of mapping the whole memory section, we only map "populated" parts and update the mapping when notified about discarding/population of memory via the RamDiscardListener. Similarly, when syncing the dirty bitmaps, sync only the actually mapped (populated) parts by replaying via the notifier. Using virtio-mem with vfio is still blocked via ram_block_discard_disable()/ram_block_discard_require() after this patch. Reviewed-by: Alex Williamson <alex.williamson@redhat.com> Acked-by: Alex Williamson <alex.williamson@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Dr. David Alan Gilbert <dgilbert@redhat.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Pankaj Gupta <pankaj.gupta.linux@gmail.com> Cc: Peter Xu <peterx@redhat.com> Cc: Auger Eric <eric.auger@redhat.com> Cc: Wei Yang <richard.weiyang@linux.alibaba.com> Cc: teawater <teawaterz@linux.alibaba.com> Cc: Marek Kedzierski <mkedzier@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20210413095531.25603-7-david@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-07-08virtio-mem: Implement RamDiscardManager interfaceDavid Hildenbrand
Let's properly notify when (un)plugging blocks, after discarding memory and before allowing the guest to consume memory. Handle errors from notifiers gracefully (e.g., no remaining VFIO mappings) when plugging, rolling back the change and telling the guest that the VM is busy. One special case to take care of is replaying all notifications after restoring the vmstate. The device starts out with all memory discarded, so after loading the vmstate, we have to notify about all plugged blocks. Acked-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Dr. David Alan Gilbert <dgilbert@redhat.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Pankaj Gupta <pankaj.gupta.linux@gmail.com> Cc: Peter Xu <peterx@redhat.com> Cc: Auger Eric <eric.auger@redhat.com> Cc: Wei Yang <richard.weiyang@linux.alibaba.com> Cc: teawater <teawaterz@linux.alibaba.com> Cc: Marek Kedzierski <mkedzier@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20210413095531.25603-6-david@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-07-08virtio-mem: Don't report errors when ram_block_discard_range() failsDavid Hildenbrand
Any errors are unexpected and ram_block_discard_range() already properly prints errors. Let's stop manually reporting errors. Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Dr. David Alan Gilbert <dgilbert@redhat.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Pankaj Gupta <pankaj.gupta.linux@gmail.com> Cc: Peter Xu <peterx@redhat.com> Cc: Auger Eric <eric.auger@redhat.com> Cc: Wei Yang <richard.weiyang@linux.alibaba.com> Cc: teawater <teawaterz@linux.alibaba.com> Cc: Marek Kedzierski <mkedzier@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20210413095531.25603-5-david@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-07-08virtio-mem: Factor out traversing unplugged rangesDavid Hildenbrand
Let's factor out the core logic, no need to replicate. Reviewed-by: Pankaj Gupta <pankaj.gupta@cloud.ionos.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Dr. David Alan Gilbert <dgilbert@redhat.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Pankaj Gupta <pankaj.gupta.linux@gmail.com> Cc: Peter Xu <peterx@redhat.com> Cc: Auger Eric <eric.auger@redhat.com> Cc: Wei Yang <richard.weiyang@linux.alibaba.com> Cc: teawater <teawaterz@linux.alibaba.com> Cc: Marek Kedzierski <mkedzier@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20210413095531.25603-4-david@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-07-08hw/misc: add MAX34451 deviceTitus Rwantare
The MAX34451 is a Maxim power-supply system manager that can monitor up to 16 voltage rails or currents. It also contains a temperature sensor and supports up to four external temperature sensors. This commit adds support for interfacing with it, and setting limits on the supported sensors. Reviewed-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Hao Wu <wuhaotsh@google.com> Signed-off-by: Titus Rwantare <titusr@google.com> Message-Id: <20210708172556.1868139-5-titusr@google.com> [Moved the device to the sensor directory] Signed-off-by: Corey Minyard <cminyard@mvista.com>
2021-07-08hw/misc: add ADM1272 deviceTitus Rwantare
The ADM1272 is a PMBus compliant Hot Swap Controller and Digital Power Monitor by Analog Devices. This commit adds support for interfacing with it, and support for setting and monitoring sensor limits. Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/ADM1272.pdf Reviewed-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Hao Wu <wuhaotsh@google.com> Signed-off-by: Titus Rwantare <titusr@google.com> Message-Id: <20210708172556.1868139-3-titusr@google.com> [Moved the device to the sensor directory] [remove include of trace.h, it is not needed] Signed-off-by: Corey Minyard <cminyard@mvista.com>
2021-07-08hw/i2c: add support for PMBusTitus Rwantare
QEMU has support for SMBus devices, and PMBus is a more specific implementation of SMBus. The additions made in this commit makes it easier to add new PMBus devices to QEMU. https://pmbus.org/specification-archives/ Reviewed-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Hao Wu <wuhaotsh@google.com> Signed-off-by: Titus Rwantare <titusr@google.com> Message-Id: <20210708172556.1868139-2-titusr@google.com> Signed-off-by: Corey Minyard <cminyard@mvista.com>
2021-07-08ipmi/sim: fix watchdog_expired data type error in IPMIBmcSim structJinhua Cao
1) watchdog_expired is set bool which value could only be 0 or 1, but watchdog_expired every bit mean different Timer Use. 2) Use the command -ipmitool mc get watchdog- to query ipmi-watchdog status in guest. ... [root@localhost ~]# ipmitool mc watchdog get Watchdog Timer Use: SMS/OS (0x44) Watchdog Timer Is: Started/Running Watchdog Timer Actions: Hard Reset (0x01) Pre-timeout interval: 0 seconds Timer Expiration Flags: 0x00 Initial Countdown: 60 sec Present Countdown: 57 sec ... bool for watchdog_expired results -Timer Expiration Flags- always be 0x00 or 0x01, but the -Timer Expiration Flags- indicts the Timer Use after timeout. So change watchdog_expired data type from bool to uint8_t to fix this problem. Signed-off-by: Jinhua Cao <caojinhua1@huawei.com> Message-Id: <20210625021232.73614-1-caojinhua1@huawei.com> [I checked, a bool and uint8 are the same size for the vmstate transfer, so this should be fine.] Signed-off-by: Corey Minyard <cminyard@mvista.com>
2021-07-08hw/i2c: Introduce i2c_start_recv() and i2c_start_send()Philippe Mathieu-Daudé
To ease reviewing code using the I2C bus API, introduce the i2c_start_recv() and i2c_start_send() helpers which don't take the confusing 'is_recv' boolean argument. Use these new helpers in the SMBus / AUX bus models. Suggested-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Corey Minyard <cminyard@mvista.com>
2021-07-08hw/i2c: Extract i2c_do_start_transfer() from i2c_start_transfer()Philippe Mathieu-Daudé
To allow further simplications, extract i2c_do_start_transfer() from i2c_start_transfer(). This is mostly the same function, but the former is static and takes an enum argument. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Corey Minyard <cminyard@mvista.com>
2021-07-08hw/i2c: Make i2c_start_transfer() direction argument a booleanBALATON Zoltan
Make the argument representing the direction of the transfer a boolean type. Rename the boolean argument as 'is_recv' to match i2c_recv_send(). Document the function prototype. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <20200621145235.9E241745712@zero.eik.bme.hu> [PMD: Split patch, added docstring] Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Acked-by: Corey Minyard <cminyard@mvista.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Corey Minyard <cminyard@mvista.com>
2021-07-08hw/i2c: Rename i2c_set_slave_address() -> i2c_slave_set_address()Philippe Mathieu-Daudé
Other functions from I2C slave API are named "i2c_slave_XXX()". Follow that pattern with set_address(). Add docstring along. No logical change. Patch created mechanically using: $ sed -i s/i2c_set_slave_address/i2c_slave_set_address/ \ $(git grep -l i2c_set_slave_address) Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Acked-by: Corey Minyard <cminyard@mvista.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Corey Minyard <cminyard@mvista.com>
2021-07-08hw/i2c: Remove confusing i2c_send_recv()Philippe Mathieu-Daudé
We replaced all the i2c_send_recv() calls by the clearer i2c_recv() and i2c_send(), so we can remove this confusing API. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Acked-by: Corey Minyard <cminyard@mvista.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Corey Minyard <cminyard@mvista.com>
2021-07-08hw/misc/auxbus: Replace i2c_send_recv() by i2c_recv() & i2c_send()Philippe Mathieu-Daudé
Instead of using the confuse i2c_send_recv(), replace i2c_send_recv(send = true) by i2c_send() and i2c_send_recv(send = false) by i2c_recv(). During the replacement we also change a while() statement by for(). The resulting code is easier to review. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Acked-by: Corey Minyard <cminyard@mvista.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Corey Minyard <cminyard@mvista.com>
2021-07-08hw/misc/auxbus: Replace 'is_write' boolean by its valuePhilippe Mathieu-Daudé
Remove the 'is_write' boolean by directly using its value in place. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Acked-by: Corey Minyard <cminyard@mvista.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Corey Minyard <cminyard@mvista.com>
2021-07-08hw/misc/auxbus: Explode READ_I2C / WRITE_I2C_MOT casesPhilippe Mathieu-Daudé
To allow further simplifications in the following commits, start copying WRITE_I2C code to the READ_I2C, and READ_I2C_MOT to WRITE_I2C_MOT. No logical change. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Acked-by: Corey Minyard <cminyard@mvista.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Corey Minyard <cminyard@mvista.com>
2021-07-08hw/misc/auxbus: Fix MOT/classic I2C modePhilippe Mathieu-Daudé
Since its introduction in commit 6fc7f77fd2 i2c_start_transfer() uses incorrectly the direction of the transfer (the last argument is called 'is_recv'). Fix by inverting the argument, we now have is_recv = !is_write. Fixes: 6fc7f77fd2 ("introduce aux-bus") Reported-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Acked-by: Corey Minyard <cminyard@mvista.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Corey Minyard <cminyard@mvista.com>
2021-07-08hw/i2c/ppc4xx_i2c: Replace i2c_send_recv() by i2c_recv() & i2c_send()Philippe Mathieu-Daudé
Instead of using the confuse i2c_send_recv(), rewrite to directly call i2c_recv() & i2c_send(), resulting in code easier to review. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Acked-by: Corey Minyard <cminyard@mvista.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Corey Minyard <cminyard@mvista.com>
2021-07-08hw/i2c/ppc4xx_i2c: Add reference to datasheetPhilippe Mathieu-Daudé
It took me a while to find this model datasheet, since it is an OCR scan. Add a reference to save other developers time. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Acked-by: Corey Minyard <cminyard@mvista.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Corey Minyard <cminyard@mvista.com>
2021-07-08hw/display/sm501: Replace i2c_send_recv() by i2c_recv() & i2c_send()Philippe Mathieu-Daudé
Instead of using the confuse i2c_send_recv(), rewrite to directly call i2c_recv() & i2c_send(), resulting in code easier to review. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Acked-by: Corey Minyard <cminyard@mvista.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Corey Minyard <cminyard@mvista.com>
2021-07-08hw/display/sm501: Simplify sm501_i2c_write() logicPhilippe Mathieu-Daudé
Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Acked-by: Corey Minyard <cminyard@mvista.com> Reviewed-by: BALATON Zoltan <balaton@eik.bme.hu> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Corey Minyard <cminyard@mvista.com>
2021-07-08hw/input/lm832x: Define TYPE_LM8323 in public headerPhilippe Mathieu-Daudé
Define TYPE_LM8323 in the public "hw/input/lm832x.h" header and use it in hw/arm/nseries.c. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Acked-by: Corey Minyard <cminyard@mvista.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Corey Minyard <cminyard@mvista.com>
2021-07-08hw/input/lm832x: Move lm832x_key_event() declaration to "lm832x.h"Philippe Mathieu-Daudé
lm832x_key_event() is specific go LM832x devices, not to the I2C bus API. Move it out of "i2c.h" to a new header. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Acked-by: Corey Minyard <cminyard@mvista.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Corey Minyard <cminyard@mvista.com>
2021-07-07target/s390x: move kvm files into kvm/Cho, Yu-Chen
move kvm files into kvm/ After the reshuffling, update MAINTAINERS accordingly. Make use of the new directory: target/s390x/kvm/ Signed-off-by: Claudio Fontana <cfontana@suse.de> Signed-off-by: Cho, Yu-Chen <acho@suse.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20210707105324.23400-14-acho@suse.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
generated by cgit v1.2.3 (git 2.26.2) at 2025-03-16 07:00:26 +0000