summaryrefslogtreecommitdiffstats
path: root/hw
Commit message (Collapse)AuthorAgeFilesLines
* ivshmem: Inline check_shm_size() into its only callerMarkus Armbruster2016-03-211-26/+11Star
| | | | | | | | Improve the error messages while there. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <1458066895-20632-34-git-send-email-armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
* ivshmem: Simplify memory regions for BAR 2 (shared memory)Markus Armbruster2016-03-211-30/+17Star
| | | | | | | | | | | | | ivshmem_realize() puts the shared memory region in a container region. Used to be necessary to permit delayed mapping of the shared memory. However, we recently moved to synchronous mapping, in "ivshmem: Receive shared memory synchronously in realize()" and the commit following it. The container is redundant since then. Drop it. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <1458066895-20632-33-git-send-email-armbru@redhat.com>
* ivshmem: Implement shm=... with a memory backendMarkus Armbruster2016-03-211-56/+23Star
| | | | | | | | | | | | | | | | | | | ivshmem has its very own code to create and map shared memory. Replace that with an implicitly created memory backend. Reduces the number of ways we create BAR 2 from three to two. The memory-backend-file is currently available only with CONFIG_LINUX, so this adds a second Linuxism to ivshmem (the other one is eventfd). Should we ever need to make it portable to systems where memory-backend-file can't be made to serve, we could create a memory-backend-shmem that allocates memory with shm_open(). Bonus fix: shared memory files are now created with permissions 0655 instead of 0777. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <1458066895-20632-32-git-send-email-armbru@redhat.com>
* ivshmem: Tighten check of property "size"Markus Armbruster2016-03-211-3/+4
| | | | | | | | | If size_t is narrower than 64 bits, passing uint64_t ivshmem_size to mmap() truncates. Reject such sizes. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <1458066895-20632-31-git-send-email-armbru@redhat.com>
* ivshmem: Simplify how we cope with short reads from serverMarkus Armbruster2016-03-211-59/+16Star
| | | | | | | | | | | Short reads from a UNIX domain sockets are exceedingly unlikely when the other side always sends eight bytes and we always read eight bytes. We cope with them anyway. However, the code doing that is rather convoluted. Dumb it down radically. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <1458066895-20632-30-git-send-email-armbru@redhat.com>
* ivshmem: Drop the hackish test for UNIX domain chardevMarkus Armbruster2016-03-211-9/+0Star
| | | | | | | | | | | | | | | The chardev must be capable of transmitting SCM_RIGHTS ancillary messages. We check it by comparing CharDriverState member filename to "unix:". That's almost as brittle as it is disgusting. When the actual transmission all happened asynchronously, this check was all we could do in realize(), and thus better than nothing. But now we receive at least one SCM_RIGHTS synchronously in realize(), it's not worth its keep anymore. Drop it. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <1458066895-20632-29-git-send-email-armbru@redhat.com>
* ivshmem: Rely on server sending the ID right after the versionMarkus Armbruster2016-03-211-3/+24
| | | | | | | | | | | | | | The protocol specification (ivshmem-spec.txt, formerly ivshmem_device_spec.txt) has always required the ID message to be sent right at the beginning, and ivshmem-server has always complied. The device, however, accepts it out of order. If an interrupt setup arrived before it, though, it would be misinterpreted as connect notification. Fix the latent bug by relying on the spec and ivshmem-server's actual behavior. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <1458066895-20632-28-git-send-email-armbru@redhat.com>
* ivshmem: Propagate errors through ivshmem_recv_setup()Markus Armbruster2016-03-211-46/+83
| | | | | | | | | | This kills off the funny state described in the previous commit. Simplify ivshmem_io_read() accordingly, and update documentation. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <1458066895-20632-27-git-send-email-armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
* ivshmem: Receive shared memory synchronously in realize()Markus Armbruster2016-03-211-20/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When configured for interrupts (property "chardev" given), we receive the shared memory from an ivshmem server. We do so asynchronously after realize() completes, by setting up callbacks with qemu_chr_add_handlers(). Keeping server I/O out of realize() that way avoids delays due to a slow server. This is probably relevant only for hot plug. However, this funny "no shared memory, yet" state of the device also causes a raft of issues that are hard or impossible to work around: * The guest is exposed to this state: when we enter and leave it its shared memory contents is apruptly replaced, and device register IVPosition changes. This is a known issue. We document that guests should not access the shared memory after device initialization until the IVPosition register becomes non-negative. For cold plug, the funny state is unlikely to be visible in practice, because we normally receive the shared memory long before the guest gets around to mess with the device. For hot plug, the timing is tighter, but the relative slowness of PCI device configuration has a good chance to hide the funny state. In either case, guests complying with the documented procedure are safe. * Migration becomes racy. If migration completes before the shared memory setup completes on the source, shared memory contents is silently lost. Fortunately, migration is rather unlikely to win this race. If the shared memory's ramblock arrives at the destination before shared memory setup completes, migration fails. There is no known way for a management application to wait for shared memory setup to complete. All you can do is retry failed migration. You can improve your chances by leaving more time between running the destination QEMU and the migrate command. To mitigate silent memory loss, you need to ensure the server initializes shared memory exactly the same on source and destination. These issues are entirely undocumented so far. I'd expect the server to be almost always fast enough to hide these issues. But then rare catastrophic races are in a way the worst kind. This is way more trouble than I'm willing to take from any device. Kill the funny state by receiving shared memory synchronously in realize(). If your hot plug hangs, go kill your ivshmem server. For easier review, this commit only makes the receive synchronous, it doesn't add the necessary error propagation. Without that, the funny state persists. The next commit will do that, and kill it off for real. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <1458066895-20632-26-git-send-email-armbru@redhat.com>
* ivshmem: Plug leaks on unplug, fix peer disconnectMarkus Armbruster2016-03-211-12/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | close_peer_eventfds() cleans up three things: ioeventfd triggers if they exist, eventfds, and the array to store them. Commit 98609cd (v1.2.0) fixed it not to clean up ioeventfd triggers when they don't exist (property ioeventfd=off, which is the default). Unfortunately, the fix also made it skip cleanup of the eventfds and the array then. This is a memory and file descriptor leak on unplug. Additionally, the reset of nb_eventfds is skipped. Doesn't matter on unplug. On peer disconnect, however, this permanently wedges the interrupt vectors used for that peer's ID. The eventfds stay behind, but aren't connected to a peer anymore. When the ID gets recycled for a new peer, the new peer's eventfds get assigned to vectors after the old ones. Commonly, the device's number of vectors matches the server's, so the new ones get dropped with a "Too many eventfd received" message. Interrupts either don't work (common case) or go to the wrong vector. Fix by narrowing the conditional to just the ioeventfd trigger cleanup. While there, move the "invalid" peer check to the only caller where it can actually happen, and tighten it to reject own ID. Cc: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <1458066895-20632-25-git-send-email-armbru@redhat.com>
* ivshmem: Disentangle ivshmem_read()Markus Armbruster2016-03-211-79/+80
| | | | | | Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <1458066895-20632-24-git-send-email-armbru@redhat.com>
* ivshmem: Simplify rejection of invalid peer ID from serverMarkus Armbruster2016-03-211-39/+22Star
| | | | | | | | | | | | | | | | | | | | | ivshmem_read() processes server messages. These are 64 bit signed integers. -1 is shared memory setup, 16 bit unsigned is a peer ID, anything else is invalid. ivshmem_read() rejects invalid negative messages right away, silently. Invalid positive messages get rejected only in resize_peers(), and ivshmem_read() then prints the rather cryptic message "failed to resize peers array". Extend the first check to cover all invalid messages, make it report "server sent invalid message", and drop the second check. Now resize_peers() can't fail anymore; simplify. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <1458066895-20632-23-git-send-email-armbru@redhat.com>
* ivshmem: Assert interrupts are set up onceMarkus Armbruster2016-03-211-5/+2Star
| | | | | | | | | | | | | | | | | | An interrupt is set up when the interrupt's file descriptor is received. Each message applies to the next interrupt vector. Therefore, each vector cannot be set up more than once. ivshmem_add_kvm_msi_virq() half-heartedly tries not to rely on this by doing nothing then, but that's not going to recover from this error should it become possible in the future. watch_vector_notifier() doesn't even try. Simply assert what is the case, so we get alerted if we ever screw it up. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <1458066895-20632-22-git-send-email-armbru@redhat.com>
* ivshmem: Leave INTx alone when using MSI-XMarkus Armbruster2016-03-211-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | The ivshmem device can either use MSI-X or legacy INTx for interrupts. With MSI-X enabled, peer interrupt events trigger an MSI as they should. But software can still raise INTx via interrupt status and mask register in BAR 0. This is explicitly prohibited by PCI Local Bus Specification Revision 3.0, section 6.8.3.3: While enabled for MSI or MSI-X operation, a function is prohibited from using its INTx# pin (if implemented) to request service (MSI, MSI-X, and INTx# are mutually exclusive). Fix the device model to leave INTx alone when using MSI-X. Document that we claim to use INTx in config space even when we don't. Unlike other devices, ivshmem does *not* use INTx when configured for MSI-X and MSI-X isn't enabled by software. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <1458066895-20632-21-git-send-email-armbru@redhat.com>
* ivshmem: Clean up MSI-X conditionsMarkus Armbruster2016-03-211-12/+10Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are three predicates related to MSI-X: * ivshmem_has_feature(s, IVSHMEM_MSI) is true unless the non-MSI-X variant of the device is selected with msi=off. * msix_present() is true when the device has the PCI capability MSI-X. It's initially false, and becomes true during successful realize of the MSI-X variant of the device. Thus, it's the same as ivshmem_has_feature(s, IVSHMEM_MSI) for realized devices. * msix_enabled() is true when msix_present() is true and guest software has enabled MSI-X. Code that differs between the non-MSI-X and the MSI-X variant of the device needs to be guarded by ivshmem_has_feature(s, IVSHMEM_MSI) or by msix_present(), except the latter works only for realized devices. Code that depends on whether MSI-X is in use needs to be guarded with msix_enabled(). Code review led me to two minor messes: * ivshmem_vector_notify() calls msix_notify() even when !msix_enabled(), unlike most other MSI-X-capable devices. As far as I can tell, msix_notify() does nothing when !msix_enabled(). Add the guard anyway. * Most callers of ivshmem_use_msix() guard it with ivshmem_has_feature(s, IVSHMEM_MSI). Not necessary, because ivshmem_use_msix() does nothing when !msix_present(). That's ivshmem's only use of msix_present(), though. Guard it consistently, and drop the now redundant msix_present() check. While there, rename ivshmem_use_msix() to ivshmem_msix_vector_use(). Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <1458066895-20632-20-git-send-email-armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
* ivshmem: Clean up register callbacksMarkus Armbruster2016-03-211-9/+2Star
| | | | | | Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <1458066895-20632-19-git-send-email-armbru@redhat.com>
* ivshmem: Failed realize() can leave migration blocker behindMarkus Armbruster2016-03-211-9/+14
| | | | | | | | | | | | If pci_ivshmem_realize() fails after it created its migration blocker, the blocker is left in place. Fix that by creating it last. Likewise, if it fails after it called fifo8_create(), it leaks fifo memory. Fix that the same way. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <1458066895-20632-18-git-send-email-armbru@redhat.com>
* ivshmem: Fix harmless misuse of ErrorMarkus Armbruster2016-03-211-3/+4
| | | | | | | | | | | | | | We reuse errp after passing it host_memory_backend_get_memory(). If both host_memory_backend_get_memory() and the reuse set an error, the reuse will fail the assertion in error_setv(). Fortunately, host_memory_backend_get_memory() can't fail. Pass it &error_abort to make our assumption explicit, and to get the assertion failure in the right place should it become invalid. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <1458066895-20632-17-git-send-email-armbru@redhat.com>
* ivshmem: Don't destroy the chardev on version mismatchMarkus Armbruster2016-03-211-2/+1Star
| | | | | | | | | | | | | | | Yes, the chardev is commonly useless after we read a bad version from it, but destroying it is inappropriate anyway: the user created it, so the user should be able to hold on to it as long as he likes. We don't destroy it on other errors. Screwed up in commit 5105b1d. Stop reading instead. Also note QEMU's behavior in ivshmem-spec.txt. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <1458066895-20632-16-git-send-email-armbru@redhat.com>
* ivshmem: Drop ivshmem_event() stubMarkus Armbruster2016-03-211-7/+2Star
| | | | | | Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <1458066895-20632-15-git-send-email-armbru@redhat.com>
* ivshmem: Clean up after commit 9940c32Markus Armbruster2016-03-211-12/+0Star
| | | | | | | | | IVShmemState member eventfd_chr is useless since commit 9940c32. Drop it. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <1458066895-20632-14-git-send-email-armbru@redhat.com>
* ivshmem: Compile debug prints unconditionally to prevent bit-rotMarkus Armbruster2016-03-211-7/+7
| | | | | | Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <1458066895-20632-13-git-send-email-armbru@redhat.com>
* ivshmem: Add missing newlines to debug printfsMarkus Armbruster2016-03-211-3/+3
| | | | | | Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <1458066895-20632-12-git-send-email-armbru@redhat.com>
* blockdev: Split monitor reference from BB creationMax Reitz2016-03-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Before this patch, blk_new() automatically assigned a name to the new BlockBackend and considered it referenced by the monitor. This patch removes the implicit monitor_add_blk() call from blk_new() (and consequently the monitor_remove_blk() call from blk_delete(), too) and thus blk_new() (and related functions) no longer take a BB name argument. In fact, there is only a single point where blk_new()/blk_new_open() is called and the new BB is monitor-owned, and that is in blockdev_init(). Besides thus relieving us from having to invent names for all of the BBs we use in qemu-img, this fixes a bug where qemu cannot create a new image if there already is a monitor-owned BB named "image". If a BB and its BDS tree are created in a single operation, as of this patch the BDS tree will be created before the BB is given a name (whereas it was the other way around before). This results in minor change to the output of iotest 087, whose reference output is amended accordingly. Signed-off-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
* module: Rename machine_init() to opts_init()Eduardo Habkost2016-03-162-2/+2
| | | | | | | | | | | | | The only remaining users of machine_init() only call qemu_add_opts(). Rename machine_init() to opts_init() and move it closer to the qemu_add_opts() calls on vl.c. Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
* machine: Use type_init() to register machine classesEduardo Habkost2016-03-1619-25/+17Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | Change all machine_init() users that simply call type_register*() to use type_init(). Cc: Evgeny Voevodin <e.voevodin@samsung.com> Cc: Maksim Kozlov <m.kozlov@samsung.com> Cc: Igor Mitsyanko <i.mitsyanko@gmail.com> Cc: Dmitry Solodkiy <d.solodkiy@samsung.com> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Rob Herring <robh@kernel.org> Cc: Andrzej Zaborowski <balrogg@gmail.com> Cc: Michael Walle <michael@walle.cc> Cc: "Hervé Poussineau" <hpoussin@reactos.org> Cc: Aurelien Jarno <aurelien@aurel32.net> Cc: Leon Alrae <leon.alrae@imgtec.com> Cc: Alexander Graf <agraf@suse.de> Cc: David Gibson <david@gibson.dropbear.id.au> Cc: Blue Swirl <blauwirbel@gmail.com> Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Cc: Max Filippov <jcmvbkbc@gmail.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Acked-by: Marcel Apfelbaum <marcel@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
* sd: Fix "info qtree" on boards with SD cardsPeter Maydell2016-03-161-2/+4
| | | | | | | | | | | | | | | | | | | The SD card object is not a SysBusDevice, so don't create it with qdev_create() if we're not assigning it to a specific bus; use object_new() instead. This was causing 'info qtree' to segfault on boards with SD cards, because qdev_create(NULL, TYPE_FOO) puts the created object on the system bus, and then we may try to run functions like sysbus_dev_print() on it, which fail when casting the object to SysBusDevice. (This is the same mistake that we made with the NAND device and fixed in commit 6749695eaaf346c1.) Reported-by: xiaoqiang.zhao <zxq_yx_007@163.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: xiaoqiang.zhao <zxq_yx_007@163.com> Message-id: 1458061009-7733-1-git-send-email-peter.maydell@linaro.org
* bcm2835_dma: add emulation of Raspberry Pi DMA controllerGrégory ESTRADE2016-03-163-0/+435
| | | | | | | | | | | | | | | At present, all DMA transfers complete inline (so a looping descriptor queue will lock up the device). We also do not model pause/abort, arbitrarion/priority, or debug features. Signed-off-by: Grégory ESTRADE <gregory.estrade@gmail.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Andrew Baumann <Andrew.Baumann@microsoft.com> Message-id: 1457467526-8840-6-git-send-email-Andrew.Baumann@microsoft.com [AB: implement 2D mode, cleanup/refactoring for upstream submission] Signed-off-by: Andrew Baumann <Andrew.Baumann@microsoft.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* bcm2835_property: implement framebuffer control/configuration propertiesGrégory ESTRADE2016-03-163-14/+140
| | | | | | | | | | | | | | | | | The property channel driver now interfaces with the framebuffer device to query and set framebuffer parameters. As a result of this, the "get ARM RAM size" query now correctly returns the video RAM base address (not total RAM size), and the ram-size property is no longer relevant here. Signed-off-by: Grégory ESTRADE <gregory.estrade@gmail.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Andrew Baumann <Andrew.Baumann@microsoft.com> Message-id: 1457467526-8840-5-git-send-email-Andrew.Baumann@microsoft.com [AB: cleanup/refactoring for upstream submission] Signed-off-by: Andrew Baumann <Andrew.Baumann@microsoft.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* bcm2835_fb: add framebuffer device for Raspberry PiGrégory ESTRADE2016-03-165-2/+468
| | | | | | | | | | | | | | | The framebuffer occupies the upper portion of memory (64MiB by default), but it can only be controlled/configured via a system mailbox or property channel (to be added by a subsequent patch). Signed-off-by: Grégory ESTRADE <gregory.estrade@gmail.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Andrew Baumann <Andrew.Baumann@microsoft.com> Message-id: 1457467526-8840-4-git-send-email-Andrew.Baumann@microsoft.com [AB: added Windows (BGR) support and cleanup/refactoring for upstream submission] Signed-off-by: Andrew Baumann <Andrew.Baumann@microsoft.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* bcm2835_aux: add emulation of BCM2835 AUX (aka UART1) blockAndrew Baumann2016-03-163-0/+349
| | | | | | | | | | | | | | | | At present only the core UART functions (data path for tx/rx) are implemented, which is enough for UEFI to boot. The following features/registers are unimplemented: * Line/modem control * Scratch register * Extra control * Baudrate * SPI interfaces Signed-off-by: Andrew Baumann <Andrew.Baumann@microsoft.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 1457467526-8840-3-git-send-email-Andrew.Baumann@microsoft.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* bcm2835_peripherals: enable sdhci pending-insert quirk for raspberry piAndrew Baumann2016-03-161-0/+7
| | | | | | | Signed-off-by: Andrew Baumann <Andrew.Baumann@microsoft.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 1457467526-8840-2-git-send-email-Andrew.Baumann@microsoft.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* hw/arm: Add palmetto-bmc machineAndrew Jeffery2016-03-162-1/+66
| | | | | | | | | | | | | | | | The new machine is a thin layer over the AST2400 ARM926-based SoC[1]. Between the minimal machine and the current SoC implementation there is enough functionality to boot an aspeed_defconfig Linux kernel to userspace. Nothing yet is specific to the Palmetto's BMC (other than using an AST2400 SoC), but creating specific machine types is preferable to a generic machine that doesn't match any particular hardware. [1] http://www.aspeedtech.com/products.php?fPath=20&rId=376 Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Message-id: 1458096317-25223-5-git-send-email-andrew@aj.id.au Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* hw/arm: Add ASPEED AST2400 SoC modelAndrew Jeffery2016-03-162-0/+138
| | | | | | | | | | | | | While the ASPEED AST2400 SoC[1] has a broad range of capabilities this implementation is minimal, comprising an ARM926 processor, ASPEED VIC and timer devices, and a 8250 UART. [1] http://www.aspeedtech.com/products.php?fPath=20&rId=376 Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Message-id: 1458096317-25223-4-git-send-email-andrew@aj.id.au Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* hw/intc: Add (new) ASPEED VIC device modelAndrew Jeffery2016-03-162-0/+340
| | | | | | | | | | | | | | | Implement a basic ASPEED VIC device model for the AST2400 SoC[1], with enough functionality to boot an aspeed_defconfig Linux kernel. The model implements the 'new' (revised) register set: While the hardware exposes both the new and legacy register sets, accesses to the model's legacy register set will not be serviced (however the access will be logged). [1] http://www.aspeedtech.com/products.php?fPath=20&rId=376 Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Message-id: 1458096317-25223-3-git-send-email-andrew@aj.id.au Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* hw/timer: Add ASPEED timer device modelAndrew Jeffery2016-03-162-0/+450
| | | | | | | | | | | | | | | Implement basic ASPEED timer functionality for the AST2400 SoC[1]: Up to 8 timers can independently be configured, enabled, reset and disabled. Some hardware features are not implemented, namely clock value matching and pulse generation, but the implementation is enough to boot the Linux kernel configured with aspeed_defconfig. [1] http://www.aspeedtech.com/products.php?fPath=20&rId=376 Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Message-id: 1458096317-25223-2-git-send-email-andrew@aj.id.au Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* i.MX: Add missing descriptions in devices.Jean-Christophe Dubois2016-03-164-0/+4
| | | | | | | Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Jean-Christophe Dubois <jcd@tribudubois.net> Message-id: f1f565eb9dffdeb582feb1b15ba9e8b0afcf5468.1456868959.git.jcd@tribudubois.net Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* i.MX: Add i.MX6 CCM and ANALOG device.Jean-Christophe Dubois2016-03-162-0/+775
| | | | | | | Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Jean-Christophe Dubois <jcd@tribudubois.net> Message-id: 9fa80b4d8c5d0f50c94e77d74f952a7a665e168f.1456868959.git.jcd@tribudubois.net Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* i.MX: Add the CLK_IPG_HIGH clockJean-Christophe Dubois2016-03-164-12/+14
| | | | | | | | | | | | | | | | EPIT, GPT and other i.MX timers are using "abstract" clocks among which a CLK_IPG_HIGH clock. On i.MX25 and i.MX31 CLK_IPG and CLK_IPG_HIGH are mapped to the same clock but on other SOC like i.MX6 they are mapped to distinct clocks. This patch add the CLK_IPG_HIGH to prepare for SOC where these 2 clocks are different. Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Jean-Christophe Dubois <jcd@tribudubois.net> Message-id: 224bf650194760284cb40630e985867e1373276a.1456868959.git.jcd@tribudubois.net Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* i.MX: Remove CCM useless clock computation handling.Jean-Christophe Dubois2016-03-162-58/+0Star
| | | | | | | | | | | | | | | | | Most clocks supported by the CCM are useless to the qemu framework. Only clocks related to timers (EPIT, GPT, PWM, WATCHDOG, ...) are usefull to QEMU code. Therefore this patch removes clock computation handling for all clocks but: * CLK_NONE, * CLK_IPG, * CLK_32k Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Jean-Christophe Dubois <jcd@tribudubois.net> Message-id: 9e7222efb349801032e60c0f6b0fbad0e5dcf648.1456868959.git.jcd@tribudubois.net Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* i.MX: Rename CCM NOCLK to CLK_NONE for naming consistency.Jean-Christophe Dubois2016-03-164-8/+8
| | | | | | | | | This way all CCM clock defines/enums are named CLK_XXX Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Jean-Christophe Dubois <jcd@tribudubois.net> Message-id: 8537df765c1713625c7a8b9aca4c7ca60b42e0c0.1456868959.git.jcd@tribudubois.net Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* i.MX: Allow GPT timer to rollover.Jean-Christophe Dubois2016-03-161-12/+15
| | | | | | | | | | | | GPT timer need to rollover when it reaches 0xffffffff. It also need to reset to 0 when in "restart mode" and crossing the compare 1 register. Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Jean-Christophe Dubois <jcd@tribudubois.net> Message-id: 6e2b36117a249a78bf822dd59a390368f407136e.1456868959.git.jcd@tribudubois.net Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* arm: virt: Move machine class init code to the abstract machine typeWei Huang2016-03-161-14/+20
| | | | | | | | | | | | This patch moves the common class initialization code from "virt-2.6" to the new abstract class. An empty property is added to "virt-2.6" machine. In the meanwhile, related funtions are renamed to "virt_2_6_*" for consistency. Signed-off-by: Wei Huang <wei@redhat.com> Message-id: 1457717778-17727-3-git-send-email-wei@redhat.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* arm: virt: Add an abstract ARM virt machine typeWei Huang2016-03-161-5/+18
| | | | | | | | | | | | | | | | | In preparation for future ARM virt machine types, this patch creates an abstract type for all ARM machines. The current machine type in QEMU (i.e. "virt") is renamed to "virt-2.6", whose naming scheme is similar to other architectures. For the purpose of backward compatibility, "virt" is converted to an alias, pointing to "virt-2.6". With this patch, "qemu -M ?" lists the following virtual machine types along with others: virt QEMU 2.6 ARM Virtual Machine (alias of virt-2.6) virt-2.6 QEMU 2.6 ARM Virtual Machine Signed-off-by: Wei Huang <wei@redhat.com> Message-id: 1457717778-17727-2-git-send-email-wei@redhat.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-2.6-20160316' ↵Peter Maydell2016-03-166-188/+241
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | into staging ppc patch queue for 2016-03-16 Accumulated patches for target-ppc, pseries machine type and related devices. As we are now in soft freeze, these are mostly fixes. * Fix KVM migration for several SPRs that qemu didn't handle * Clean up handling of SDR1, which allows a fix to the gdbstub * Fix a race in spapr_rng * Fix a bug with multifunction hotplug The exception is the 7 patches to allow EEH on spapr-pci-host-bridge devices (rather than the special and poorly designed spapr-vfio-pci-host-bridge device). I believe these are low risk of breaking non-EEH cases, and EEH cases were little used in practice previously (since libvirt did not support the special device amongst other things). It did have a draft posted before the soft freeze, removes a very ugly VFIO interface, and removes device we'd like to deprecate sooner rather than later. So, I'm hoping we can squeeze these in during the soft freeze. This includes two patches to the VFIO code, which Alex Williamson has indicated he's ok with coming through my tree. # gpg: Signature made Wed 16 Mar 2016 05:04:52 GMT using RSA key ID 20D9B392 # gpg: Good signature from "David Gibson <david@gibson.dropbear.id.au>" # gpg: aka "David Gibson (Red Hat) <dgibson@redhat.com>" # gpg: aka "David Gibson (ozlabs.org) <dgibson@ozlabs.org>" # 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: 75F4 6586 AE61 A66C C44E 87DC 6C38 CACA 20D9 B392 * remotes/dgibson/tags/ppc-for-2.6-20160316: vfio: Eliminate vfio_container_ioctl() spapr_pci: Remove finish_realize hook spapr_pci: (Mostly) remove spapr-pci-vfio-host-bridge spapr_pci: Allow EEH on spapr-pci-host-bridge spapr_pci: Eliminate class callbacks spapr_pci: Switch to vfio_eeh_as_op() interface vfio: Start improving VFIO/EEH interface spapr_rng: fix race with main loop target-ppc: Eliminate kvmppc_kern_htab global target-ppc: Add helpers for updating a CPU's SDR1 and external HPT target-ppc: Split out SREGS get/put functions spapr_pci: fix multifunction hotplug target-ppc: Add PVR for POWER8NVL processor ppc: Add a few more P8 PMU SPRs ppc: Fix migration of the TAR SPR ppc: Define the PSPB register on POWER8 Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
| * vfio: Eliminate vfio_container_ioctl()David Gibson2016-03-151-45/+0Star
| | | | | | | | | | | | | | | | | | | | | | | | vfio_container_ioctl() was a bad interface that bypassed abstraction boundaries, had semantics that sat uneasily with its name, and was unsafe in many realistic circumstances. Now that spapr-pci-vfio-host-bridge has been folded into spapr-pci-host-bridge, there are no more users, so remove it. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru> Acked-by: Alex Williamson <alex.williamson@redhat.com>
| * spapr_pci: Remove finish_realize hookDavid Gibson2016-03-151-20/+5Star
| | | | | | | | | | | | | | | | | | | | | | Now that spapr-pci-vfio-host-bridge is reduced to just a stub, there is only one implementation of the finish_realize hook in sPAPRPHBClass. So, we can fold that implementation into its (single) caller, and remove the hook. That's the last thing left in sPAPRPHBClass, so that can go away as well. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
| * spapr_pci: (Mostly) remove spapr-pci-vfio-host-bridgeDavid Gibson2016-03-151-44/+17Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that the regular spapr-pci-host-bridge can handle EEH, there are only two things that spapr-pci-vfio-host-bridge does differently: 1. automatically sizes its DMA window to match the host IOMMU 2. checks if the attached VFIO container is backed by the VFIO_SPAPR_TCE_IOMMU type on the host (1) is not particularly useful, since the default window used by the regular host bridge will work with the host IOMMU configuration on all current systems anyway. Plus, automatically changing guest visible configuration (such as the DMA window) based on host settings is generally a bad idea. It's not definitively broken, since spapr-pci-vfio-host-bridge is only supposed to support VFIO devices which can't be migrated anyway, but still. (2) is not really useful, because if a guest tries to configure EEH on a different host IOMMU, the first call will fail and that will be that. It's possible there are scripts or tools out there which expect spapr-pci-vfio-host-bridge, so we don't remove it entirely. This patch reduces it to just a stub for backwards compatibility. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
| * spapr_pci: Allow EEH on spapr-pci-host-bridgeDavid Gibson2016-03-152-9/+7Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that the EEH code is independent of the special spapr-vfio-pci-host-bridge device, we can allow it on all spapr PCI host bridges instead. We do this by changing spapr_phb_eeh_available() to be based on the vfio_eeh_as_ok() call instead of the host bridge class. Because the value of vfio_eeh_as_ok() can change with devices being hotplugged or unplugged, this can potentially lead to some strange edge cases where the guest starts using EEH, then it starts failing because of a change in status. However, it's not really any worse than the current situation. Cases that would have worked previously will still work (i.e. VFIO devices from at most one VFIO IOMMU group per vPHB), it's just that it's no longer necessary to use spapr-vfio-pci-host-bridge with the groupid pre-specified. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
| * spapr_pci: Eliminate class callbacksDavid Gibson2016-03-152-33/+29Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The EEH operations in the spapr-vfio-pci-host-bridge no longer rely on the special groupid field in sPAPRPHBVFIOState. So we can simplify, removing the class specific callbacks with direct calls based on a simple spapr_phb_eeh_enabled() helper. For now we implement that in terms of a boolean in the class, but we'll continue to clean that up later. On its own this is a rather strange way of doing things, but it's a useful intermediate step to further cleanups. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2024-12-22 20:34:37 +0100