aboutsummaryrefslogtreecommitdiff
path: root/hw
AgeCommit message (Collapse)Author
2019-02-21hw/char/pl011: Use '0x' prefix when logging hex numbersPeter Maydell
The pl011 logs when the guest makes a bad access. It prints the address offset in hex but confusingly omits the '0x' prefix; add it. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
2019-02-21hw/char/pl011: Support all interrupt linesPeter Maydell
The PL011 UART has six interrupt lines: * RX (receive data) * TX (transmit data) * RT (receive timeout) * MS (modem status) * E (errors) * combined (logical OR of all the above) So far we have only emulated the combined interrupt line; add support for the others, so that boards that wire them up to different interrupt controller inputs can do so. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
2019-02-21hw/char/pl011: Allow use as an embedded-struct devicePeter Maydell
Create a new include file for the pl011's device struct, type macros, etc, so that it can be instantiated using the "embedded struct" coding style. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
2019-02-21hw/timer/pl031: Convert to using trace eventsPeter Maydell
Convert the debug printing in the PL031 device to use trace events, and augment it to cover the interesting parts of device operation. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
2019-02-21hw/timer/pl031: Allow use as an embedded-struct devicePeter Maydell
Create a new include file for the pl031's device struct, type macros, etc, so that it can be instantiated using the "embedded struct" coding style. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
2019-02-21hw/misc/tz-ppc: Support having unused ports in the middle of the rangePeter Maydell
The Peripheral Protection Controller's handling of unused ports is that if there is nothing connected to the port's downstream then it does not create the sysbus MMIO region for the upstream end of the port. This results in odd behaviour when there is an unused port in the middle of the range: since sysbus MMIO regions are implicitly consecutively allocated, any used ports above the unused ones end up with sysbus MMIO region numbers that don't match the port number. Avoid this numbering mismatch by creating dummy MMIO regions for the unused ports. This doesn't change anything for our existing boards, which don't have any gaps in the middle of the port ranges they use; but it will be needed for the Musca board. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
2019-02-21hw/arm/armsse: Fix memory leak in error-exit pathPeter Maydell
Coverity points out (CID 1398632, CID 1398650) that we leak a couple of allocated strings in the error-exit code path for setting up the MHUs in the ARMSSE. Fix this bug by moving the allocate-and-free of each string to be closer to the use, so we do the free before doing the error-exit check. Fixes: f8574705f62b38a ("hw/arm/armsse: Add unimplemented-device stubs for MHUs") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20190215113707.24553-1-peter.maydell@linaro.org
2019-02-21hw/hppa/dino: mask out lower 2 bits of PCI config addrSven Schnelle
some versions of HP-UX 10.20 seems to rely on the fact that DINO strips out the lower 2 bits of the PCI configuration address. Also update the binary SeaBIOS distributed to the latest version from Helge's repository, which is required with that change. Signed-off-by: Sven Schnelle <svens@stackframe.org> Message-Id: <20190218183314.20157-1-svens@stackframe.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2019-02-21virtio-balloon: Use ram_block_discard_range() instead of raw madvise()David Gibson
Currently, virtio-balloon uses madvise() with MADV_DONTNEED to actually discard RAM pages inserted into the balloon. This is basically a Linux only interface (MADV_DONTNEED exists on some other platforms, but doesn't always have the same semantics). It also doesn't work on hugepages and has some other limitations. It turns out that postcopy also needs to discard chunks of memory, and uses a better interface for it: ram_block_discard_range(). It doesn't cover every case, but it covers more than going direct to madvise() and this gives us a single place to update for more possibilities in future. There are some subtleties here to maintain the current balloon behaviour: * For now, we just ignore requests to balloon in a hugepage backed region. That matches current behaviour, because MADV_DONTNEED on a hugepage would simply fail, and we ignore the error. * If host page size is > BALLOON_PAGE_SIZE we can frequently call this on non-host-page-aligned addresses. These would also fail in madvise(), which we then ignored. ram_block_discard_range() error_report()s calls on unaligned addresses, so we explicitly check that case to avoid spamming the logs. * We now call ram_block_discard_range() with the *host* page size, whereas we previously called madvise() with BALLOON_PAGE_SIZE. Surprisingly, this also matches existing behaviour. Although the kernel fails madvise on unaligned addresses, it will round unaligned sizes *up* to the host page size. Yes, this means that if BALLOON_PAGE_SIZE < guest page size we can incorrectly discard more memory than the guest asked us to. I'm planning to address that soon. Errors other than the ones discussed above, will now be reported by ram_block_discard_range(), rather than silently ignored, which means we have a much better chance of seeing when something is going wrong. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <20190214043916.22128-5-david@gibson.dropbear.id.au> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-02-21virtio-balloon: Rework ballon_page() interfaceDavid Gibson
This replaces the balloon_page() internal interface with ballon_inflate_page(), with a slightly different interface. The new interface will make future alterations simpler. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <20190214043916.22128-4-david@gibson.dropbear.id.au> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-02-21virtio-balloon: Corrections to address verificationDavid Gibson
The virtio-balloon device's verification of the address given to it by the guest has a number of faults: * The addresses here are guest physical addresses, which should be 'hwaddr' rather than 'ram_addr_t' (the distinction is admittedly pretty subtle and confusing) * We don't check for section.mr being NULL, which is the main way that memory_region_find() reports basic failures. We really need to check that before looking at any other section fields, because memory_region_find() doesn't initialize them on the failure path * We're passing a length of '1' to memory_region_find(), but really the guest is requesting that we put the entire page into the balloon, so it makes more sense to call it with BALLOON_PAGE_SIZE Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <20190214043916.22128-3-david@gibson.dropbear.id.au> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-02-21virtio-balloon: Remove unnecessary MADV_WILLNEED on deflateDavid Gibson
When the balloon is inflated, we discard memory place in it using madvise() with MADV_DONTNEED. And when we deflate it we use MADV_WILLNEED, which sounds like it makes sense but is actually unnecessary. The misleadingly named MADV_DONTNEED just discards the memory in question, it doesn't set any persistent state on it in-kernel; all that's necessary to bring the memory back is to touch it. MADV_WILLNEED in contrast specifically says that the memory will be used soon and faults it in. This patch simplify's the balloon operation by dropping the madvise() on deflate. This might have an impact on performance - it will move a delay at deflate time until that memory is actually touched, which might be more latency sensitive. However: * Memory that's being given back to the guest by deflating the balloon *might* be used soon, but it equally could just sit around in the guest's pools until needed (or even be faulted out again if the host is under memory pressure). * Usually, the timescale over which you'll be adjusting the balloon is long enough that a few extra faults after deflation aren't going to make a difference. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <20190214043916.22128-2-david@gibson.dropbear.id.au> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-02-21pc-dimm: use same mechanism for [get|set]_addrWei Yang
[get|set]_addr are two counterpart to access PCDIMMDevice.addr. Since we have already set up a property PC_DIMM_ADDR_PROP for this field and use this mechanism in set_addr, it would be more proper to use the same mechanism in get_addr. This patch uses object_property_get_uint() to replace the direct memory access to make [get|set]_addr with the same mechanism. Signed-off-by: Wei Yang <richardw.yang@linux.intel.com> Message-Id: <20190211064629.20186-1-richardw.yang@linux.intel.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-02-21vhost-net: revamp configure logicPaolo Bonzini
Detect all invalid configurations (e.g. mingw32 with vhost-user, non-Linux with vhost-kernel). As a collateral benefit, all vhost-kernel backends can be now disabled if one wants to reduce the attack surface. Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <1543851204-41186-6-git-send-email-pbonzini@redhat.com> Message-Id: <1550165756-21617-7-git-send-email-pbonzini@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-02-21vhost-net: compile it on all targets that have virtio-net.Paolo Bonzini
This shows a preexisting bug: if a KVM target did not have virtio-net enabled, it would fail with undefined symbols when vhost was enabled. This must now be fixed, lest targets that have no virtio-net fail to compile. Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <1543851204-41186-5-git-send-email-pbonzini@redhat.com> Message-Id: <1550165756-21617-6-git-send-email-pbonzini@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-02-21vhost: restrict Linux dependency to kernel vhostPaolo Bonzini
vhost-user does not depend on Linux; it can run on any POSIX system. Restrict vhost-kernel to Linux in hw/virtio/vhost-backend.c, everything else can be compiled on all POSIX systems. Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <1543851204-41186-4-git-send-email-pbonzini@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <1550165756-21617-4-git-send-email-pbonzini@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-02-21vhost-net-user: add stubs for when no virtio-net device is presentPaolo Bonzini
hw/net/vhost_net.c needs functions that are declared in net/vhost-user.c: the vhost-user code is always compiled into QEMU, only the constructor net_init_vhost_user is unreachable. Also, net/vhost-user.c needs functions declared in hw/virtio/vhost-stub.c even if no virtio device exists. Break this dependency. First, add a minimal version of net/vhost-user.c, with no functionality and no dependency on vhost code. Second, #ifdef out the calls back to net/vhost-user.c from hw/net/vhost_net.c. While at it, this patch fixes the CONFIG_VHOST_NET_USE*D* typo. Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <1543851204-41186-3-git-send-email-pbonzini@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <1550165756-21617-3-git-send-email-pbonzini@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-02-21vhost-net: move stubs to a separate filePaolo Bonzini
There is no reason for CONFIG_VHOST_NET to be specific to a single target; it is a host feature that can be add to all targets, as long as they support the virtio-net device. Currently CONFIG_VHOST_NET depends on CONFIG_KVM, but ioeventfd support is present in the core memory API and works with other accelerators as well. As a first step, move the vhost-net stubs to a separate file. Later, they will become conditional on CONFIG_VIRTIO_NET, which is not available in .c files. Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <1543851204-41186-2-git-send-email-pbonzini@redhat.com> Message-Id: <1550165756-21617-2-git-send-email-pbonzini@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-02-21spice: set device address and device display ID in QXL interfaceLukáš Hrázký
Calls the new SPICE QXL interface function spice_qxl_set_device_info to set the hardware address of the graphics device represented by the QXL interface (e.g. a PCI path) and the device display IDs (the IDs of the device's monitors that belong to this QXL interface). Also stops using the deprecated spice_qxl_set_max_monitors, the new interface function replaces it. Signed-off-by: Lukáš Hrázký <lhrazky@redhat.com> Message-Id: <20190215150919.8263-1-lhrazky@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-02-20usb: remove unnecessary NULL device check from usb_ep_get()Liam Merwick
No caller of usb_ep_get() calls it with a NULL device (previous commits have addressed the few remaining cases which didn't explicitly check). Replace check for 'dev == NULL' with an assert instead. Signed-off-by: Liam Merwick <liam.merwick@oracle.com> Message-id: 1549460216-25808-10-git-send-email-liam.merwick@oracle.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-02-20usb: add device checks before redirector calls to usb_ep_get()Liam Merwick
Add an assert and an explicit check before the two callers to usb_ep_get() in the USB redirector code to ensure the device passed in is not NULL. Signed-off-by: Liam Merwick <liam.merwick@oracle.com> Message-id: 1549460216-25808-9-git-send-email-liam.merwick@oracle.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-02-20usb: check device is not NULL before calling usb_ep_get()Liam Merwick
In musb_packet(), the call to usb_find_device() can return NULL if it doesn't find a device matching 'addr' so explicitly check the return value before passing it to usb_ep_get(). This then allows the subsequent calculation of 'id' to be streamlined. Signed-off-by: Liam Merwick <liam.merwick@oracle.com> Message-id: 1549460216-25808-8-git-send-email-liam.merwick@oracle.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-02-20uhci: check device is not NULL before calling usb_ep_get()Liam Merwick
In uhci_handle_td(), the call to ehci_find_device() can return NULL if it doesn't find a device matching 'addr' so explicitly check the return value before passing it to usb_ep_get(). Signed-off-by: Liam Merwick <liam.merwick@oracle.com> Message-id: 1549460216-25808-7-git-send-email-liam.merwick@oracle.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-02-20ohci: check device is not NULL before calling usb_ep_get()Liam Merwick
A call to ohci_find_device() can return NULL if it doesn't find a device matching 'addr' so for the two callers, explicitly check the return value before passing it to usb_ep_get(). Signed-off-by: Liam Merwick <liam.merwick@oracle.com> Message-id: 1549460216-25808-6-git-send-email-liam.merwick@oracle.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-02-20ehci: check device is not NULL before calling usb_ep_get()Liam Merwick
In ehci_process_itd(), the call to ehci_find_device() can return NULL if it doesn't find a device matching 'devaddr' so explicitly check the return value before passing it to usb_ep_get(). Signed-off-by: Liam Merwick <liam.merwick@oracle.com> Message-id: 1549460216-25808-5-git-send-email-liam.merwick@oracle.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-02-20xhci: check device is not NULL before calling usb_ep_get()Liam Merwick
Signed-off-by: Liam Merwick <liam.merwick@oracle.com> Message-id: 1549460216-25808-4-git-send-email-liam.merwick@oracle.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-02-20xhci: add asserts to help with static code analysisLiam Merwick
Most callers of xhci_port_update() and xhci_wakeup() pass in a pointer to an array entry and can never be NULL but add two defensive asserts to protect against future changes (e.g. adding a new port speed, etc.) adding a path through xhci_lookup_port() that could result in the return of a NULL XHCIPort. Signed-off-by: Liam Merwick <liam.merwick@oracle.com> Message-id: 1549460216-25808-3-git-send-email-liam.merwick@oracle.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-02-20usb: rearrange usb_ep_get()Liam Merwick
There is no need to calculate the 'eps' variable in usb_ep_get() if 'ep' is the control endpoint. Instead the calculation should be done after validating the input before returning an entry indexed by the endpoint 'ep'. Signed-off-by: Liam Merwick <liam.merwick@oracle.com> Reviewed-by: Darren Kenny <Darren.Kenny@oracle.com> Reviewed-by: Mark Kanda <Mark.Kanda@oracle.com> Reviewed-by: Ameya More <ameya.more@oracle.com> Message-id: 1549460216-25808-2-git-send-email-liam.merwick@oracle.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-02-18Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-4.0-20190219' ↵Peter Maydell
into staging ppc patch queue 2019-02-19 Here's the next batch of ppc and spapr patches. Higlights are: * A bunch of improvements to TCG handling of vector instructions from Richard Henderson and Marc Cave-Ayland * Cleanup to the XICS interrupt controller from Greg Kurz, removing the special KVM subclasses which were a bad idea * Some refinements to the XIVE interrupt controller from Cédric Le Goater * Fix from Fabiano Rosas for a really dumb buffer overflow in the device tree code for memory hotplug * Code for allowing access to SPRs from the gdb stub from Fabiano Rosas * Assorted minor fixes and cleanups # gpg: Signature made Mon 18 Feb 2019 13:47:54 GMT # gpg: using RSA key 75F46586AE61A66CC44E87DC6C38CACA20D9B392 # gpg: Good signature from "David Gibson <david@gibson.dropbear.id.au>" [full] # gpg: aka "David Gibson (Red Hat) <dgibson@redhat.com>" [full] # gpg: aka "David Gibson (ozlabs.org) <dgibson@ozlabs.org>" [full] # gpg: aka "David Gibson (kernel.org) <dwg@kernel.org>" [unknown] # Primary key fingerprint: 75F4 6586 AE61 A66C C44E 87DC 6C38 CACA 20D9 B392 * remotes/dgibson/tags/ppc-for-4.0-20190219: (43 commits) target/ppc: convert vmin* and vmax* to vector operations target/ppc: convert vadd*s and vsub*s to vector operations target/ppc: Split out VSCR_SAT to a vector field target/ppc: Add set_vscr_sat target/ppc: Use mtvscr/mfvscr for vmstate target/ppc: Add helper_mfvscr target/ppc: Remove vscr_nj and vscr_sat target/ppc: Use helper_mtvscr for reset and gdb target/ppc: Pass integer to helper_mtvscr target/ppc: convert xxsel to vector operations target/ppc: convert xxspltw to vector operations target/ppc: convert xxspltib to vector operations target/ppc: convert VSX logical operations to vector operations target/ppc: convert vsplt[bhw] to use vector operations target/ppc: convert vspltis[bhw] to use vector operations target/ppc: convert vaddu[b,h,w,d] and vsubu[b,h,w,d] over to use vector operations target/ppc: convert VMX logical instructions to use vector operations xics: Drop the KVM ICS class spapr/irq: Use the "simple" ICS class for KVM xics: Handle KVM interrupt presentation from "simple" ICS code ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-02-18Merge remote-tracking branch 'remotes/armbru/tags/pull-qapi-2019-02-18' into ↵Peter Maydell
staging QAPI patches for 2019-02-18 # gpg: Signature made Mon 18 Feb 2019 13:44:30 GMT # gpg: using RSA key 3870B400EB918653 # gpg: Good signature from "Markus Armbruster <armbru@redhat.com>" [full] # gpg: aka "Markus Armbruster <armbru@pond.sub.org>" [full] # Primary key fingerprint: 354B C8B3 D7EB 2A6B 6867 4E5F 3870 B400 EB91 8653 * remotes/armbru/tags/pull-qapi-2019-02-18: qapi: move RTC_CHANGE to the target schema qmp: Deprecate query-events in favor of query-qmp-schema Revert "qapi-events: add 'if' condition to implicit event enum" qapi: remove qmp_unregister_command() qapi: make query-cpu-definitions depend on specific targets qapi: make query-cpu-model-expansion depend on s390 or x86 qapi: make query-gic-capabilities depend on TARGET_ARM target.json: add a note about query-cpu* not being s390x-specific qapi: make s390 commands depend on TARGET_S390X qapi: make rtc-reset-reinjection and SEV depend on TARGET_I386 qapi: New module target.json build: Deal with all of QAPI's .o in qapi/Makefile.objs build-sys: move qmp-introspect per target qapi: Generate QAPIEvent stuff into separate files qapi: Prepare for system modules other than 'builtin' qapi: Clean up modular built-in code generation a bit qapi: Fix up documentation for recent commit a95291007b2 qapi: Belatedly document modular code generation Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-02-18qapi: move RTC_CHANGE to the target schemaMarc-André Lureau
A few targets don't emit RTC_CHANGE, we could restrict the event to the tagets that do emit it. Note: There is a lot more of events & commands that we could restrict to capable targets, with the cost of some additional complexity, but the benefit of added correctness and better introspection. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190214152251.2073-19-armbru@redhat.com>
2019-02-18qapi: make s390 commands depend on TARGET_S390XMarc-André Lureau
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Acked-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190214152251.2073-11-armbru@redhat.com>
2019-02-18qapi: make rtc-reset-reinjection and SEV depend on TARGET_I386Marc-André Lureau
Move rtc-reset-reinjection and SEV in target.json and make them conditional on TARGET_I386. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190214152251.2073-10-armbru@redhat.com>
2019-02-18s390x/cpumodel: default enable mepoch for z14 and laterCollin Walling
Latest systems and host kernels support mepoch, which is a feature that was meant to be supported for z14 GA1 from the get-go. Let's copy it to the z14 GA1 default CPU model. Machines s390-ccw-virtio-3.1 and older will retain the old CPU models and will not provide this bit nor the extended PTFF functions in the default model. Signed-off-by: Collin Walling <walling@linux.ibm.com> Message-Id: <20190212011657.18324-2-walling@linux.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-02-18s390x: add zPCI feature to "qemu" CPU modelDavid Hildenbrand
As we now always have PCI support, let's add it to the "qemu" CPU model, taking care of backwards compatibility. Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20190212112323.15904-1-david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-02-18s390x: always provide pci supportCornelia Huck
We tried to make pci support optional on s390x in the past; unfortunately, we still require the s390 phb to be created unconditionally due to backwards compatibility issues. Instead of sinking more effort into this (including compat handling for older machines etc.) for non-obvious gains, let's just make CONFIG_PCI something that is always set on s390x. Note that you can still fence off pci for the _guest_ if you provide a cpu model without the zpci feature. Message-Id: <20190211113255.3837-1-cohuck@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-02-18xics: Drop the KVM ICS classGreg Kurz
The KVM ICS class isn't used anymore. Drop it. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <155023084177.1011724.14693955932559990358.stgit@bahia.lan> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-02-18spapr/irq: Use the "simple" ICS class for KVMGreg Kurz
The "simple" ICS class knows how to interract with KVM. Adapt sPAPR to use it instead of the ICS KVM class. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <155023083585.1011724.2868047424353921455.stgit@bahia.lan> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-02-18xics: Handle KVM interrupt presentation from "simple" ICS codeGreg Kurz
We want to use the "simple" ICS type in both KVM and non-KVM setups. Teach the "simple" ICS how to present interrupts to KVM and adapt sPAPR accordingly. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <155023082996.1011724.16237920586343905010.stgit@bahia.lan> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-02-18xics: Handle KVM ICS reset from the "simple" ICS codeGreg Kurz
The KVM ICS reset handler simply writes the ICS state to KVM. This doesn't need the overkill parent_reset logic we have today. Also we want to use the same ICS type for the KVM and non-KVM case with pseries. Call icp_set_kvm_state() from the "simple" ICS reset function. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <155023082407.1011724.1983100830860273401.stgit@bahia.lan> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-02-18xics: Explicitely call KVM ICS methods from the common codeGreg Kurz
The pre_save(), post_load() and synchronize_state() methods of the ICSStateClass type are really KVM only things. Make that obvious by dropping the indirections and directly calling the KVM functions instead. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <155023081817.1011724.14078777320394028836.stgit@bahia.lan> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-02-18xics: Drop the KVM ICP classGreg Kurz
The KVM ICP class isn't used anymore. Drop it. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <155023081228.1011724.12474992370439652538.stgit@bahia.lan> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-02-18spapr/irq: Use the base ICP class for KVMGreg Kurz
The base ICP class knows how to interact with KVM. Adapt sPAPR to use it instead of the ICP KVM class. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <155023080638.1011724.792095453419098948.stgit@bahia.lan> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-02-18xics: Handle KVM ICP realize from the common codeGreg Kurz
The realization of KVM ICP currently follows the parent_realize logic, which is a bit overkill here. Also we want to get rid of the KVM ICP class. Explicitely call icp_kvm_realize() from the base ICP realize function. Note that ICPStateClass::parent_realize is retained because powernv needs it. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <155023080049.1011724.15423463482790260696.stgit@bahia.lan> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-02-18xics: Handle KVM ICP reset from the common codeGreg Kurz
The KVM ICP reset handler simply writes the ICP state to KVM. This doesn't need the overkill parent_reset logic we have today. Call icp_set_kvm_state() from the base ICP reset function instead. Since there are no other users for ICPStateClass::parent_reset, and it isn't currently expected to change, drop it as well. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <155023079461.1011724.12644984391500635645.stgit@bahia.lan> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-02-18xics: Explicitely call KVM ICP methods from the common codeGreg Kurz
The pre_save(), post_load() and synchronize_state() methods of the ICPStateClass type are really KVM only things. Make that obvious by dropping the indirections and directly calling the KVM functions instead. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <155023078871.1011724.3083923389814185598.stgit@bahia.lan> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-02-17spapr/irq: remove the XICS offset adjustmentCédric Le Goater
Now that we have changed the XICS and the XIVE interrupt backend to have different size for their IRQ number space, we do not need to align their source numbers anymore. Remove the offset adjustment and wire the dual 'qirq' handler to the 'qirq' handler of the current interrupt mode in use. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20190213210756.27032-3-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-02-17spapr/irq: add an 'nr_irq' parameter to initialize the backend.Cédric Le Goater
When using the 'dual' interrupt mode, the source numbers of both sPAPR IRQ backends are aligned to share a common IRQ number space and to use a similar mapping of the machine qemu_irq array which is indexed by the source number. The XICS IRQ number range initially being [ 0x1000 - 0x2000 ], this requires to change the XICS ICSState offset to 0 and to provision for an extra 4K of source numbers and qemu_irqs which will never be used by the machine when running under the XICS interrupt mode. This is not an optimal solution. Change the init() method to allocate an IRQ number space of the expected size for the XICS sPAPR IRQ backend. It breaks the interrupt signaling when under the 'dual' mode because source numbers have unexpected values but next patch will fix that. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20190213210756.27032-2-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-02-17spapr: fix out of bounds write in spapr_populate_drmem_v2Fabiano Rosas
buf_len is uint8_t which is not large enough to hold the result of: nr_entries * sizeof(struct sPAPRDrconfCellV2) + sizeof(uint32_t); for a nr_entries greater than 10. This causes the allocated buffer 'int_buf' to be smaller than expected and we eventually overwrite some of glibc's control structures (see "chunk" in https://sourceware.org/glibc/wiki/MallocInternals) The following error is seen while trying to free int_buf: "free(): invalid next size (fast)" Fixes: a324d6f166 "spapr: Support ibm,dynamic-memory-v2 property" Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com> Message-Id: <20190213172926.21740-1-farosas@linux.ibm.com> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-02-17qdev: pass an Object * to qbus_set_hotplug_handler()Michael Roth
Certain devices types, like memory/CPU, are now being handled using a hotplug interface provided by a top-level MachineClass. Hotpluggable host bridges are another such device where it makes sense to use a machine-level hotplug handler. However, unlike those devices, host-bridges have a parent bus (the main system bus), and devices with a parent bus use a different mechanism for registering their hotplug handlers: qbus_set_hotplug_handler(). This interface currently expects a handler to be a subclass of DeviceClass, but this is not the case for MachineClass, which derives directly from ObjectClass. Internally, the interface only requires an ObjectClass, so expose that in qbus_set_hotplug_handler(). Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Acked-by: Halil Pasic <pasic@linux.ibm.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <154999589921.690774.3640149277362188566.stgit@bahia.lan> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
generated by cgit v1.2.3 (git 2.26.2) at 2025-03-15 20:29:28 +0000