summary refs log tree commit diff stats
path: root/hw (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
| * | | vhost_net: introduce set_config & get_configCindy Lu2020-07-032-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch introduces set_config & get_config method which allows vhost_net set/get the config to backend Signed-off-by: Cindy Lu <lulu@redhat.com> Message-Id: <20200701145538.22333-13-lulu@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com>
| * | | vhost: implement vhost_force_iommu methodCindy Lu2020-07-031-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | use the vhost_force_iommu callback to force enable feature bit VIRTIO_F_IOMMU_PLATFORM Signed-off-by: Cindy Lu <lulu@redhat.com> Message-Id: <20200701145538.22333-12-lulu@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com>
| * | | vhost: implement vhost_vq_get_addr methodCindy Lu2020-07-031-9/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | use vhost_vq_get_addr callback to get the vq address from backend Signed-off-by: Cindy Lu <lulu@redhat.com> Message-Id: <20200701145538.22333-10-lulu@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com>
| * | | vhost: implement vhost_dev_start methodCindy Lu2020-07-031-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | use the vhost_dev_start callback to send the status to backend Signed-off-by: Cindy Lu <lulu@redhat.com> Message-Id: <20200701145538.22333-8-lulu@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com>
| * | | vhost: check the existence of vhost_set_iotlb_callbackJason Wang2020-07-031-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add the check of vhost_set_iotlb_callback before calling Signed-off-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Cindy Lu <lulu@redhat.com> Message-Id: <20200701145538.22333-6-lulu@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com>
| * | | virtio-pci: implement queue_enabled methodJason Wang2020-07-031-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With version 1, we can detect whether a queue is enabled via queue_enabled. Signed-off-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Cindy Lu <lulu@redhat.com> Message-Id: <20200701145538.22333-5-lulu@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com>
| * | | virtio-bus: introduce queue_enabled methodJason Wang2020-07-031-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch introduces queue_enabled() method which allows the transport to implement its own way to report whether or not a queue is enabled. Signed-off-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Cindy Lu <lulu@redhat.com> Message-Id: <20200701145538.22333-4-lulu@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com>
| * | | vhost_net: use the function qemu_get_peerCindy Lu2020-07-031-6/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | user the qemu_get_peer to replace the old process Signed-off-by: Cindy Lu <lulu@redhat.com> Reviewed-by: Laurent Vivier <lvivier@redhat.com> Message-Id: <20200701145538.22333-3-lulu@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com>
| * | | numa: Auto-enable NUMA when any memory devices are possibleDavid Hildenbrand2020-07-036-5/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Let's auto-enable it also when maxmem is specified but no slots are defined. This will result in us properly creating ACPI srat tables, indicating the maximum possible PFN to the guest OS. Based on this, e.g., Linux will enable the swiotlb properly. This avoids having to manually force the switolb on (swiotlb=force) in Linux in case we're booting only using DMA memory (e.g., 2GB on x86-64), and virtio-mem adds memory later on that really needs the swiotlb to be used for DMA. Let's take care of backwards compatibility if somebody has a setup that specifies "maxram" without "slots". Reported-by: Alex Shi <alex.shi@linux.alibaba.com> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Eduardo Habkost <ehabkost@redhat.com> Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> Cc: Sergio Lopez <slp@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Richard Henderson <rth@twiddle.net> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: qemu-arm@nongnu.org <qemu-arm@nongnu.org> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20200626072248.78761-22-david@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
| * | | virtio-mem: Exclude unplugged memory during migrationDavid Hildenbrand2020-07-031-1/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The content of unplugged memory is undefined and should not be migrated, ever. Exclude all unplugged memory during precopy using the precopy notifier infrastructure introduced for free page hinting in virtio-balloon. Unplugged memory is marked as "not dirty", meaning it won't be considered for migration. Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20200626072248.78761-21-david@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
| * | | virtio-mem: Add trace eventsDavid Hildenbrand2020-07-032-1/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Let's add some trace events that might come in handy later. Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20200626072248.78761-20-david@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
| * | | virtio-mem: Migration sanity checksDavid Hildenbrand2020-07-031-0/+70
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We want to make sure that certain properties don't change during migration, especially to catch user errors in a nice way. Let's migrate a temporary structure and validate that the properties didn't change. Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20200626072248.78761-19-david@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
| * | | virtio-pci: Send qapi events when the virtio-mem size changesDavid Hildenbrand2020-07-032-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Let's register the notifier and trigger the qapi event with the right device id. MEMORY_DEVICE_SIZE_CHANGE is similar to BALLOON_CHANGE, however on a memory device level. Don't unregister the notifier (we neither have finalize() nor unrealize() for VirtIOPCIProxy, so it's not that simple to do it) - both devices are expected to vanish at the same time. Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Markus Armbruster <armbru@redhat.com> Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com> Cc: Eric Blake <eblake@redhat.com> Cc: Igor Mammedov <imammedo@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20200626072248.78761-18-david@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
| * | | virtio-mem: Allow notifiers for size changesDavid Hildenbrand2020-07-031-1/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We want to send qapi events in case the size of a virtio-mem device changes. This allows upper layers to always know how much memory is actually currently consumed via a virtio-mem device. Unfortuantely, we have to report the id of our proxy device. Let's provide an easy way for our proxy device to register, so it can send the qapi events. Piggy-backing on the notifier infrastructure (although we'll only ever have one notifier registered) seems to be an easy way. Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com> Cc: Igor Mammedov <imammedo@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20200626072248.78761-17-david@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
| * | | pc: Support for virtio-mem-pciDavid Hildenbrand2020-07-032-21/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Let's wire it up similar to virtio-pmem. Also disallow unplug, so it's harder for users to shoot themselves into the foot. Reviewed-by: Pankaj Gupta <pankaj.gupta.linux@gmail.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Richard Henderson <rth@twiddle.net> Cc: Eduardo Habkost <ehabkost@redhat.com> Cc: Eric Blake <eblake@redhat.com> Cc: Markus Armbruster <armbru@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20200626072248.78761-16-david@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
| * | | numa: Handle virtio-mem in NUMA statsDavid Hildenbrand2020-07-031-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Account the memory to the configured nid. Reviewed-by: Pankaj Gupta <pankaj.gupta.linux@gmail.com> Cc: Eduardo Habkost <ehabkost@redhat.com> Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20200626072248.78761-15-david@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
| * | | virtio-pci: Proxy for virtio-memDavid Hildenbrand2020-07-033-0/+163
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Let's add a proxy for virtio-mem, make it a memory device, and pass-through the properties. Reviewed-by: Pankaj Gupta <pankaj.gupta.linux@gmail.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com> Cc: Igor Mammedov <imammedo@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20200626072248.78761-12-david@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
| * | | virtio-mem: Paravirtualized memory hot(un)plugDavid Hildenbrand2020-07-033-0/+736
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the very basic/initial version of virtio-mem. An introduction to virtio-mem can be found in the Linux kernel driver [1]. While it can be used in the current state for hotplug of a smaller amount of memory, it will heavily benefit from resizeable memory regions in the future. Each virtio-mem device manages a memory region (provided via a memory backend). After requested by the hypervisor ("requested-size"), the guest can try to plug/unplug blocks of memory within that region, in order to reach the requested size. Initially, and after a reboot, all memory is unplugged (except in special cases - reboot during postcopy). The guest may only try to plug/unplug blocks of memory within the usable region size. The usable region size is a little bigger than the requested size, to give the device driver some flexibility. The usable region size will only grow, except on reboots or when all memory is requested to get unplugged. The guest can never plug more memory than requested. Unplugged memory will get zapped/discarded, similar to in a balloon device. The block size is variable, however, it is always chosen in a way such that THP splits are avoided (e.g., 2MB). The state of each block (plugged/unplugged) is tracked in a bitmap. As virtio-mem devices (e.g., virtio-mem-pci) will be memory devices, we now expose "VirtioMEMDeviceInfo" via "query-memory-devices". -------------------------------------------------------------------------- There are two important follow-up items that are in the works: 1. Resizeable memory regions: Use resizeable allocations/RAM blocks to grow/shrink along with the usable region size. This avoids creating initially very big VMAs, RAM blocks, and KVM slots. 2. Protection of unplugged memory: Make sure the gust cannot actually make use of unplugged memory. Other follow-up items that are in the works: 1. Exclude unplugged memory during migration (via precopy notifier). 2. Handle remapping of memory. 3. Support for other architectures. -------------------------------------------------------------------------- Example usage (virtio-mem-pci is introduced in follow-up patches): Start QEMU with two virtio-mem devices (one per NUMA node): $ qemu-system-x86_64 -m 4G,maxmem=20G \ -smp sockets=2,cores=2 \ -numa node,nodeid=0,cpus=0-1 -numa node,nodeid=1,cpus=2-3 \ [...] -object memory-backend-ram,id=mem0,size=8G \ -device virtio-mem-pci,id=vm0,memdev=mem0,node=0,requested-size=0M \ -object memory-backend-ram,id=mem1,size=8G \ -device virtio-mem-pci,id=vm1,memdev=mem1,node=1,requested-size=1G Query the configuration: (qemu) info memory-devices Memory device [virtio-mem]: "vm0" memaddr: 0x140000000 node: 0 requested-size: 0 size: 0 max-size: 8589934592 block-size: 2097152 memdev: /objects/mem0 Memory device [virtio-mem]: "vm1" memaddr: 0x340000000 node: 1 requested-size: 1073741824 size: 1073741824 max-size: 8589934592 block-size: 2097152 memdev: /objects/mem1 Add some memory to node 0: (qemu) qom-set vm0 requested-size 500M Remove some memory from node 1: (qemu) qom-set vm1 requested-size 200M Query the configuration again: (qemu) info memory-devices Memory device [virtio-mem]: "vm0" memaddr: 0x140000000 node: 0 requested-size: 524288000 size: 524288000 max-size: 8589934592 block-size: 2097152 memdev: /objects/mem0 Memory device [virtio-mem]: "vm1" memaddr: 0x340000000 node: 1 requested-size: 209715200 size: 209715200 max-size: 8589934592 block-size: 2097152 memdev: /objects/mem1 [1] https://lkml.kernel.org/r/20200311171422.10484-1-david@redhat.com Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Eric Blake <eblake@redhat.com> Cc: Markus Armbruster <armbru@redhat.com> Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com> Cc: Igor Mammedov <imammedo@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20200626072248.78761-11-david@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
| * | | virtio-balloon: Rip out qemu_balloon_inhibit()David Hildenbrand2020-07-021-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The only remaining special case is postcopy. It cannot handle concurrent discards yet, which would result in requesting already sent pages from the source. Special-case it in virtio-balloon instead. Introduce migration_in_incoming_postcopy(), to find out if incoming postcopy is active. Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Juan Quintela <quintela@redhat.com> Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20200626072248.78761-7-david@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
| * | | s390x/pv: Convert to ram_block_discard_disable()David Hildenbrand2020-07-021-9/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Discarding RAM does not work as expected with protected VMs. Let's switch to ram_block_discard_disable() for now, as we want to get rid of qemu_balloon_inhibit(). Note that it will currently never fail, but might fail in the future with new technologies (e.g., virtio-mem). Acked-by: Cornelia Huck <cohuck@redhat.com> Cc: Richard Henderson <rth@twiddle.net> Cc: Cornelia Huck <cohuck@redhat.com> Cc: Halil Pasic <pasic@linux.ibm.com> Cc: Christian Borntraeger <borntraeger@de.ibm.com> Cc: Janosch Frank <frankja@linux.ibm.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20200626072248.78761-6-david@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
| * | | vfio: Convert to ram_block_discard_disable()David Hildenbrand2020-07-024-36/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | VFIO is (except devices without a physical IOMMU or some mediated devices) incompatible with discarding of RAM. The kernel will pin basically all VM memory. Let's convert to ram_block_discard_disable(), which can now fail, in contrast to qemu_balloon_inhibit(). Leave "x-balloon-allowed" named as it is for now. Reviewed-by: Tony Krowiak <akrowiak@linux.ibm.com> Acked-by: Cornelia Huck <cohuck@redhat.com> Cc: Cornelia Huck <cohuck@redhat.com> Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Christian Borntraeger <borntraeger@de.ibm.com> Cc: Tony Krowiak <akrowiak@linux.ibm.com> Cc: Halil Pasic <pasic@linux.ibm.com> Cc: Pierre Morel <pmorel@linux.ibm.com> Cc: Eric Farman <farman@linux.ibm.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20200626072248.78761-4-david@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
| * | | pc: Support coldplugging of virtio-pmem-pci devices on all busesDavid Hildenbrand2020-07-021-8/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | E.g., with "pc-q35-4.2", trying to coldplug a virtio-pmem-pci devices results in "virtio-pmem-pci not supported on this bus" Reasons is, that the bus does not support hotplug and, therefore, does not have a hotplug handler. Let's allow coldplugging virtio-pmem devices on such buses. The hotplug order is only relevant for virtio-pmem-pci when the guest is already alive and the device is visible before memory_device_plug() wired up the memory device bits. Hotplug attempts will still fail with: "Error: Bus 'pcie.0' does not support hotplugging" Hotunplug attempts will still fail with: "Error: Bus 'pcie.0' does not support hotplugging" Reported-by: Vivek Goyal <vgoyal@redhat.com> Reviewed-by: Pankaj Gupta <pankaj.gupta.linux@gmail.com> Cc: Pankaj Gupta <pankaj.gupta.linux@gmail.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Richard Henderson <rth@twiddle.net> Cc: Eduardo Habkost <ehabkost@redhat.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20200626072248.78761-2-david@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
| * | | virtio-balloon: always indicate S_DONE when migration failsDavid Hildenbrand2020-07-021-6/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If something goes wrong during precopy, before stopping the VM, we will never send a S_DONE indication to the VM, resulting in the hinted pages not getting released to be used by the guest OS (e.g., Linux). Easy to reproduce: 1. Start migration (e.g., HMP "migrate -d 'exec:gzip -c > STATEFILE.gz'") 2. Cancel migration (e.g., HMP "migrate_cancel") 3. Oberve in the guest (e.g., cat /proc/meminfo) that there is basically no free memory left. While at it, add similar locking to virtio_balloon_free_page_done() as done in virtio_balloon_free_page_stop. Locking is still weird, but that has to be sorted out separately. There is nothing to do in the PRECOPY_NOTIFY_COMPLETE case. Add some comments regarding S_DONE handling. Fixes: c13c4153f76d ("virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT") Reviewed-by: Alexander Duyck <alexander.h.duyck@linux.intel.com> Cc: Wei Wang <wei.w.wang@intel.com> Cc: Alexander Duyck <alexander.duyck@gmail.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20200629080615.26022-1-david@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* | | | hw/m68k/mcf5206: Replace remaining hw_error()s by qemu_log_mask()Thomas Huth2020-07-061-11/+28
| |/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | hw_error() dumps the CPU state and exits QEMU. This is ok during initial code development (to see where the guest code is currently executing), but it is certainly not the desired behavior that we want to present to normal users, and it can also cause trouble when e.g. fuzzing devices. Thus let's replace these hw_error()s by qemu_log_mask()s instead. Message-Id: <20200611055807.15921-1-huth@tuxfamily.org> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Thomas Huth <huth@tuxfamily.org>
* | | Merge remote-tracking branch ↵Peter Maydell2020-07-0420-278/+672
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 'remotes/pmaydell/tags/pull-target-arm-20200703' into staging target-arm queue: * i.MX6UL EVK board: put PHYs in the correct places * hw/arm/virt: Let the virtio-iommu bypass MSIs * target/arm: kvm: Handle DABT with no valid ISS * hw/arm/virt-acpi-build: Only expose flash on older machine types * target/arm: Fix temp double-free in sve ldr/str * hw/display/bcm2835_fb.c: Initialize all fields of struct * hw/arm/spitz: Code cleanup to fix Coverity-detected memory leak * Deprecate TileGX port # gpg: Signature made Fri 03 Jul 2020 17:53:05 BST # gpg: using RSA key E1A5C593CD419DE28E8315CF3C2525ED14360CDE # gpg: issuer "peter.maydell@linaro.org" # gpg: Good signature from "Peter Maydell <peter.maydell@linaro.org>" [ultimate] # gpg: aka "Peter Maydell <pmaydell@gmail.com>" [ultimate] # gpg: aka "Peter Maydell <pmaydell@chiark.greenend.org.uk>" [ultimate] # Primary key fingerprint: E1A5 C593 CD41 9DE2 8E83 15CF 3C25 25ED 1436 0CDE * remotes/pmaydell/tags/pull-target-arm-20200703: (34 commits) Deprecate TileGX port Replace uses of FROM_SSI_SLAVE() macro with QOM casts hw/arm/spitz: Provide usual QOM macros for corgi-ssp and spitz-lcdtg hw/arm/pxa2xx_pic: Use LOG_GUEST_ERROR for bad guest register accesses hw/arm/spitz: Use LOG_GUEST_ERROR for bad guest register accesses hw/gpio/zaurus.c: Use LOG_GUEST_ERROR for bad guest register accesses hw/arm/spitz: Encapsulate misc GPIO handling in a device hw/misc/max111x: Create header file for documentation, TYPE_ macros hw/misc/max111x: Use GPIO lines rather than max111x_set_input() hw/arm/spitz: Use max111x properties to set initial values ssi: Add ssi_realize_and_unref() hw/misc/max111x: Don't use vmstate_register() hw/misc/max111x: provide QOM properties for setting initial values hw/arm/spitz: Implement inbound GPIO lines for bit5 and power signals hw/arm/spitz: Keep pointers to scp0, scp1 in SpitzMachineState hw/arm/spitz: Keep pointers to MPU and SSI devices in SpitzMachineState hw/arm/spitz: Create SpitzMachineClass abstract base class hw/arm/spitz: Detabify hw/display/bcm2835_fb.c: Initialize all fields of struct target/arm: Fix temp double-free in sve ldr/str ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
| * | | Replace uses of FROM_SSI_SLAVE() macro with QOM castsPeter Maydell2020-07-034-12/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The FROM_SSI_SLAVE() macro predates QOM and is used as a typesafe way to cast from an SSISlave* to the instance struct of a subtype of TYPE_SSI_SLAVE. Switch to using the QOM cast macros instead, which have the same effect (by writing the QOM macros if the types were previously missing them.) (The FROM_SSI_SLAVE() macro allows the SSISlave member of the subtype's struct to be anywhere as long as it is named "ssidev", whereas a QOM cast macro insists that it is the first thing in the subtype's struct. This is true for all the types we convert here.) This removes all the uses of FROM_SSI_SLAVE() so we can delete the definition. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20200628142429.17111-18-peter.maydell@linaro.org
| * | | hw/arm/spitz: Provide usual QOM macros for corgi-ssp and spitz-lcdtgPeter Maydell2020-07-031-8/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The QOM types "spitz-lcdtg" and "corgi-ssp" are missing the usual QOM TYPE and casting macros; provide and use them. In particular, we can safely use the QOM cast macros instead of FROM_SSI_SLAVE() because in both cases the 'ssidev' field of the instance state struct is the first field in it. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20200628142429.17111-17-peter.maydell@linaro.org
| * | | hw/arm/pxa2xx_pic: Use LOG_GUEST_ERROR for bad guest register accessesPeter Maydell2020-07-031-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of using printf() for logging guest accesses to invalid register offsets in the pxa2xx PIC device, use the usual qemu_log_mask(LOG_GUEST_ERROR,...). This was the only user of the REG_FMT macro in pxa.h, so we can remove that. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20200628142429.17111-16-peter.maydell@linaro.org
| * | | hw/arm/spitz: Use LOG_GUEST_ERROR for bad guest register accessesPeter Maydell2020-07-031-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of logging guest accesses to invalid register offsets in the Spitz flash device with zaurus_printf() (which just prints to stderr), use the usual qemu_log_mask(LOG_GUEST_ERROR,...). Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20200628142429.17111-15-peter.maydell@linaro.org
| * | | hw/gpio/zaurus.c: Use LOG_GUEST_ERROR for bad guest register accessesPeter Maydell2020-07-032-5/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of logging guest accesses to invalid register offsets in this device using zaurus_printf() (which just prints to stderr), use the usual qemu_log_mask(LOG_GUEST_ERROR,...). Since this was the only use of the zaurus_printf() macro outside spitz.c, we can move the definition of that macro from sharpsl.h to spitz.c. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20200628142429.17111-14-peter.maydell@linaro.org
| * | | hw/arm/spitz: Encapsulate misc GPIO handling in a devicePeter Maydell2020-07-031-43/+88
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently we have a free-floating set of IRQs and a function spitz_out_switch() which handle some miscellaneous GPIO lines for the spitz board. Encapsulate this behaviour in a simple QOM device. At this point we can finally remove the 'max1111' global, because the ADC battery-temperature value is now handled by the misc-gpio device writing the value to its outbound "adc-temp" GPIO, which the board code wires up to the appropriate inbound GPIO line on the max1111. This commit also fixes Coverity issue CID 1421913 (which pointed out that the 'outsignals' in spitz_scoop_gpio_setup() were leaked), because it removes the use of the qemu_allocate_irqs() API from this code entirely. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20200628142429.17111-13-peter.maydell@linaro.org
| * | | hw/misc/max111x: Create header file for documentation, TYPE_ macrosPeter Maydell2020-07-032-24/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Create a header file for the hw/misc/max111x device, in the usual modern style for QOM devices: * definition of the TYPE_ constants and macros * definition of the device's state struct so that it can be embedded in other structs if desired * documentation of the interface This allows us to use TYPE_MAX_1111 in the spitz.c code rather than the string "max1111". Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20200628142429.17111-12-peter.maydell@linaro.org
| * | | hw/misc/max111x: Use GPIO lines rather than max111x_set_input()Peter Maydell2020-07-032-11/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The max111x ADC device model allows other code to set the level on the 8 ADC inputs using the max111x_set_input() function. Replace this with generic qdev GPIO inputs, which also allow inputs to be set to arbitrary values. Using GPIO lines will make it easier for board code to wire things up, so that if device A wants to set the ADC input it doesn't need to have a direct pointer to the max111x but can just set that value on its output GPIO, which is then wired up by the board to the appropriate max111x input. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20200628142429.17111-11-peter.maydell@linaro.org
| * | | hw/arm/spitz: Use max111x properties to set initial valuesPeter Maydell2020-07-031-4/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use the new max111x qdev properties to set the initial input values rather than calling max111x_set_input(); this means that on system reset the inputs will correctly return to their initial values. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20200628142429.17111-10-peter.maydell@linaro.org
| * | | ssi: Add ssi_realize_and_unref()Peter Maydell2020-07-031-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add an ssi_realize_and_unref(), for the benefit of callers who want to be able to create an SSI device, set QOM properties on it, and then do the realize-and-unref afterwards. The API works on the same principle as the recently added qdev_realize_and_undef(), sysbus_realize_and_undef(), etc. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20200628142429.17111-9-peter.maydell@linaro.org
| * | | hw/misc/max111x: Don't use vmstate_register()Peter Maydell2020-07-031-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The max111x is a proper qdev device; we can use dc->vmsd rather than directly calling vmstate_register(). It's possible that this is a migration compat break, but the only boards that use this device are the spitz-family ('akita', 'borzoi', 'spitz', 'terrier'). Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20200628142429.17111-8-peter.maydell@linaro.org
| * | | hw/misc/max111x: provide QOM properties for setting initial valuesPeter Maydell2020-07-031-10/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add some QOM properties to the max111x ADC device to allow the initial values to be configured. Currently this is done by board code calling max111x_set_input() after it creates the device, which doesn't work on system reset. This requires us to implement a reset method for this device, so while we're doing that make sure we reset the other parts of the device state. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20200628142429.17111-7-peter.maydell@linaro.org
| * | | hw/arm/spitz: Implement inbound GPIO lines for bit5 and power signalsPeter Maydell2020-07-031-16/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently the Spitz board uses a nasty hack for the GPIO lines that pass "bit5" and "power" information to the LCD controller: the lcdtg realize function sets a global variable to point to the instance it just realized, and then the functions spitz_bl_power() and spitz_bl_bit5() use that to find the device they are changing the internal state of. There is a comment reading: FIXME: Implement GPIO properly and remove this hack. which was added in 2009. Implement GPIO properly and remove this hack. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20200628142429.17111-6-peter.maydell@linaro.org
| * | | hw/arm/spitz: Keep pointers to scp0, scp1 in SpitzMachineStatePeter Maydell2020-07-031-17/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Keep pointers to scp0, scp1 in SpitzMachineState, and just pass that to spitz_scoop_gpio_setup(). (We'll want to use some of the other fields in SpitzMachineState in that function in the next commit.) Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20200628142429.17111-5-peter.maydell@linaro.org
| * | | hw/arm/spitz: Keep pointers to MPU and SSI devices in SpitzMachineStatePeter Maydell2020-07-031-26/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Keep pointers to the MPU and the SSI devices in SpitzMachineState. We're going to want to make GPIO connections between some of the SSI devices and the SCPs, so we want to keep hold of a pointer to those; putting the MPU into the struct allows us to pass just one thing to spitz_ssp_attach() rather than two. We have to retain the setting of the global "max1111" variable for the moment as it is used in spitz_adc_temp_on(); later in this series of commits we will be able to remove it. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20200628142429.17111-4-peter.maydell@linaro.org
| * | | hw/arm/spitz: Create SpitzMachineClass abstract base classPeter Maydell2020-07-031-35/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For the four Spitz-family machines (akita, borzoi, spitz, terrier) create a proper abstract class SpitzMachineClass which encapsulates the common behaviour, rather than having them all derive directly from TYPE_MACHINE: * instead of each machine class setting mc->init to a wrapper function which calls spitz_common_init() with parameters, put that data in the SpitzMachineClass and make spitz_common_init the SpitzMachineClass machine-init function * move the settings of mc->block_default_type and mc->ignore_memory_transaction_failures into the SpitzMachineClass class init rather than repeating them in each machine's class init (The motivation is that we're going to want to keep some state in the SpitzMachineState so we can connect GPIOs between devices created in one sub-function of the machine init to devices created in a different sub-function.) Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20200628142429.17111-3-peter.maydell@linaro.org
| * | | hw/arm/spitz: DetabifyPeter Maydell2020-07-031-79/+79
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The spitz board has been around a long time, and still has a fair number of hard-coded tab characters in it. We're about to do some work on this source file, so start out by expanding out the tabs. This commit is a pure whitespace only change. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20200628142429.17111-2-peter.maydell@linaro.org
| * | | hw/display/bcm2835_fb.c: Initialize all fields of structPeter Maydell2020-07-031-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In bcm2835_fb_mbox_push(), Coverity complains (CID 1429989) that we pass a pointer to a local struct to another function without initializing all its fields. This is a real bug: bcm2835_fb_reconfigure() copies the whole of our new BCM2385FBConfig struct into s->config, so any fields we don't initialize will corrupt the state of the device. Copy the two fields which we don't want to update (pixo and alpha) from the existing config so we don't accidentally change them. Fixes: cfb7ba983857e40e88 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20200628195436.27582-1-peter.maydell@linaro.org
| * | | hw/arm/virt-acpi-build: Only expose flash on older machine typesAndrew Jones2020-07-032-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The flash device is exclusively for the host-controlled firmware, so we should not expose it to the OS. Exposing it risks the OS messing with it, which could break firmware runtime services and surprise the OS when all its changes disappear after reboot. As firmware needs the device and uses DT, we leave the device exposed there. It's up to firmware to remove the nodes from DT before sending it on to the OS. However, there's no need to force firmware to remove tables from ACPI (which it doesn't know how to do anyway), so we simply don't add the tables in the first place. But, as we've been adding the tables for quite some time and don't want to change the default hardware exposed to versioned machines, then we only stop exposing the flash device tables for 5.1 and later machine types. Suggested-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Suggested-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-id: 20200629140938.17566-4-drjones@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
| * | | hw/arm/virt: Let the virtio-iommu bypass MSIsEric Auger2020-07-031-0/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At the moment the virtio-iommu translates MSI transactions. This behavior is inherited from ARM SMMU. The virt machine code knows where the guest MSI doorbells are so we can easily declare those regions as VIRTIO_IOMMU_RESV_MEM_T_MSI. With that setting the guest will not map MSIs through the IOMMU and those transactions will be simply bypassed. Depending on which MSI controller is in use (ITS or GICV2M), we declare either: - the ITS interrupt translation space (ITS_base + 0x10000), containing the GITS_TRANSLATOR or - The GICV2M single frame, containing the MSI_SETSP_NS register. Signed-off-by: Eric Auger <eric.auger@redhat.com> Message-id: 20200629070404.10969-6-eric.auger@redhat.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
| * | | virtio-iommu-pci: Add array of Interval propertiesEric Auger2020-07-031-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The machine may need to pass reserved regions to the virtio-iommu-pci device (such as the MSI window on x86 or the MSI doorbells on ARM). So let's add an array of Interval properties. Note: if some reserved regions are already set by the machine code - which should be the case in general -, the length of the property array is already set and prevents the end-user from modifying them. For example, attempting to use: -device virtio-iommu-pci,\ len-reserved-regions=1,reserved-regions[0]=0xfee00000:0xfeefffff:1 would result in the following error message: qemu-system-aarch64: -device virtio-iommu-pci,addr=0xa, len-reserved-regions=1,reserved-regions[0]=0xfee00000:0xfeefffff:1: array size property len-reserved-regions may not be set more than once Otherwise, for example, adding two reserved regions is achieved using the following options: -device virtio-iommu-pci,addr=0xa,len-reserved-regions=2,\ reserved-regions[0]=0xfee00000:0xfeefffff:1,\ reserved-regions[1]=0x1000000:100ffff:1 Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Reviewed-by: Peter Xu <peterx@redhat.com> Message-id: 20200629070404.10969-5-eric.auger@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
| * | | virtio-iommu: Handle reserved regions in the translation processEric Auger2020-07-031-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When translating an address we need to check if it belongs to a reserved virtual address range. If it does, there are 2 cases: - it belongs to a RESERVED region: the guest should neither use this address in a MAP not instruct the end-point to DMA on them. We report an error - It belongs to an MSI region: we bypass the translation. Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-id: 20200629070404.10969-4-eric.auger@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
| * | | virtio-iommu: Implement RESV_MEM probe requestEric Auger2020-07-032-4/+91
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements the PROBE request. At the moment, only THE RESV_MEM property is handled. The first goal is to report iommu wide reserved regions such as the MSI regions set by the machine code. On x86 this will be the IOAPIC MSI region, [0xFEE00000 - 0xFEEFFFFF], on ARM this may be the ITS doorbell. In the future we may introduce per device reserved regions. This will be useful when protecting host assigned devices which may expose their own reserved regions Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-id: 20200629070404.10969-3-eric.auger@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
| * | | qdev: Introduce DEFINE_PROP_RESERVED_REGIONEric Auger2020-07-031-0/+89
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce a new property defining a reserved region: <low address>:<high address>:<type>. This will be used to encode reserved IOVA regions. For instance, in virtio-iommu use case, reserved IOVA regions will be passed by the machine code to the virtio-iommu-pci device (an array of those). The type of the reserved region will match the virtio_iommu_probe_resv_mem subtype value: - VIRTIO_IOMMU_RESV_MEM_T_RESERVED (0) - VIRTIO_IOMMU_RESV_MEM_T_MSI (1) on PC/Q35 machine, this will be used to inform the virtio-iommu-pci device it should bypass the MSI region. The reserved region will be: 0xfee00000:0xfeefffff:1. On ARM, we can declare the ITS MSI doorbell as an MSI region to prevent MSIs from being mapped on guest side. Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-id: 20200629070404.10969-2-eric.auger@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
| * | | Select MDIO device 2 and 1 as PHY devices for i.MX6UL EVK board.Jean-Christophe Dubois2020-07-031-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The i.MX6UL EVK 14x14 board uses: - PHY 2 for FEC 1 - PHY 1 for FEC 2 Signed-off-by: Jean-Christophe Dubois <jcd@tribudubois.net> Message-id: fb41992126c091a71d76ab3d1898959091f60583.1593296112.git.jcd@tribudubois.net Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>