aboutsummaryrefslogtreecommitdiff
path: root/include/hw
AgeCommit message (Collapse)Author
2022-01-18ppc/pnv: move intbar to PnvPHB4Daniel Henrique Barboza
This MemoryRegion can also be moved in a single step. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220113192952.911188-5-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-18ppc/pnv: move phbbar to PnvPHB4Daniel Henrique Barboza
This MemoryRegion is simple enough to be moved in a single step. A 'stack->phb' pointer had to be introduced in pnv_pec_stk_update_map() because this function isn't ready to be fully converted to use a PnvPHB4 pointer instead. This will be dealt with in the following patches. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220113192952.911188-4-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-18ppc/pnv: move PCI registers to PnvPHB4Daniel Henrique Barboza
Previous patch changed pnv_pec_stk_pci_xscom_read() and pnv_pec_stk_pci_xscom_write() to use a PnvPHB4 opaque, making it easier to move both pci_regs[] and the pci_regs_mr MemoryRegion to the PnvHB4 object. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220113192952.911188-3-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-18hw/dma: Let dma_buf_read() / dma_buf_write() propagate MemTxResultPhilippe Mathieu-Daudé
Since commit 292e13142d2, dma_buf_rw() returns a MemTxResult type. Do not discard it, return it to the caller. Pass the previously returned value (the QEMUSGList residual size, which was rarely used) as an optional argument. With this new API, SCSIRequest::residual might now be accessed via a pointer. Since the size_t type does not have the same size on 32 and 64-bit host architectures, convert it to a uint64_t, which is big enough to hold the residual size, and the type is constant on both 32/64-bit hosts. Update the few dma_buf_read() / dma_buf_write() callers to the new API. Reviewed-by: Klaus Jensen <k.jensen@samsung.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Acked-by: Peter Xu <peterx@redhat.com> Message-Id: <20220117125130.131828-1-f4bug@amsat.org>
2022-01-18hw/scsi: Rename SCSIRequest::resid as 'residual'Philippe Mathieu-Daudé
The 'resid' field is slightly confusing and could be interpreted as some ID. Rename it as 'residual' which is clearer to review. No logical change. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: David Hildenbrand <david@redhat.com> Message-Id: <20220111184309.28637-8-f4bug@amsat.org> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2022-01-18qdev-core.h: Fix wrongly named reference to TYPE_SPLIT_IRQPeter Maydell
Fix a comment in qdev-core.h where we incorrectly referred to TYPE_IRQ_SPLIT when we meant TYPE_SPLIT_IRQ. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20220111172655.3546766-1-peter.maydell@linaro.org> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2022-01-18hw/pci: Document pci_dma_map()Philippe Mathieu-Daudé
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20220111184309.28637-5-f4bug@amsat.org> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2022-01-17s390x/css: fix PMCW invalid maskNico Boehr
Previously, we required bits 5, 6 and 7 to be zero (0x07 == 0b111). But, as per the principles of operation, bit 5 is ignored in MSCH and bits 0, 1, 6 and 7 need to be zero. As both PMCW_FLAGS_MASK_INVALID and ioinst_schib_valid() are only used by ioinst_handle_msch(), adjust the mask accordingly. Fixes: db1c8f53bfb1 ("s390: Channel I/O basic definitions.") Signed-off-by: Nico Boehr <nrb@linux.ibm.com> Reviewed-by: Pierre Morel <pmorel@linux.ibm.com> Reviewed-by: Halil Pasic <pasic@linux.ibm.com> Reviewed-by: Janosch Frank <frankja@linux.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Message-Id: <20211216131657.1057978-1-nrb@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2022-01-14Merge remote-tracking branch ↵Peter Maydell
'remotes/kraxel/tags/kraxel-20220114-pull-request' into staging - bugfixes for ui, usb, audio, display - change default display resolution - add horizontal scrolling support # gpg: Signature made Fri 14 Jan 2022 06:52:53 GMT # gpg: using RSA key A0328CFFB93A17A79901FE7D4CB6D8EED3E87138 # gpg: Good signature from "Gerd Hoffmann (work) <kraxel@redhat.com>" [full] # gpg: aka "Gerd Hoffmann <gerd@kraxel.org>" [full] # gpg: aka "Gerd Hoffmann (private) <kraxel@gmail.com>" [full] # Primary key fingerprint: A032 8CFF B93A 17A7 9901 FE7D 4CB6 D8EE D3E8 7138 * remotes/kraxel/tags/kraxel-20220114-pull-request: ui/input-legacy: pass horizontal scroll information ui/sdl2: pass horizontal scroll information to the device code ui/gtk: pass horizontal scroll information to the device code ui/cocoa: pass horizontal scroll information to the device code ps2: Initial horizontal scroll support edid: Added support for 4k@60 Hz monitor edid: set default resolution to 1280x800 (WXGA) hw/mips/jazz: Inline vga_mmio_init() and remove it hw/display/vga-mmio: QOM'ify vga_mmio_init() as TYPE_VGA_MMIO hw/display/vga-mmio: Inline vga_mm_init() hw/display: Rename VGA_ISA_MM -> VGA_MMIO uas: add missing return ui: fix gtk clipboard clear assertion ui/dbus: fix buffer-overflow detected by ASAN hw/audio/intel-hda: fix stream reset dsoundaudio: fix crackling audio recordings jackaudio: use ifdefs to hide unavailable functions ui/vnc.c: Fixed a deadlock bug. usb: allow max 8192 bytes for desc hw/usb/dev-wacom: add missing HID descriptor Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-01-14Merge remote-tracking branch ↵Peter Maydell
'remotes/stefanha-gitlab/tags/block-pull-request' into staging Pull request # gpg: Signature made Wed 12 Jan 2022 17:13:54 GMT # gpg: using RSA key 8695A8BFD3F97CDAAC35775A9CA4ABB381AB73C8 # gpg: Good signature from "Stefan Hajnoczi <stefanha@redhat.com>" [full] # gpg: aka "Stefan Hajnoczi <stefanha@gmail.com>" [full] # Primary key fingerprint: 8695 A8BF D3F9 7CDA AC35 775A 9CA4 ABB3 81AB 73C8 * remotes/stefanha-gitlab/tags/block-pull-request: virtio: unify dataplane and non-dataplane ->handle_output() virtio: use ->handle_output() instead of ->handle_aio_output() virtio-scsi: prepare virtio_scsi_handle_cmd for dataplane virtio-blk: drop unused virtio_blk_handle_vq() return value virtio: get rid of VirtIOHandleAIOOutput aio-posix: split poll check from ready handler Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-01-13edid: set default resolution to 1280x800 (WXGA)Daniel P. Berrangé
Currently QEMU defaults to a resolution of 1024x768 when exposing EDID info to the guest OS. The EDID default info is important as this will influence what resolution many guest OS will configure the screen with on boot. It can also potentially influence what resolution the firmware will configure the screen with, though until very recently EDK2 would not handle EDID info. One important thing to bear in mind is that the default graphics card driver provided by Windows will leave the display set to whatever resolution was enabled by the firmware on boot. Even if sufficient VRAM is available, the resolution can't be changed without installing new drivers. IOW, the default resolution choice is quite important for usability of Windows. Modern real world monitor hardware for desktop/laptop has supported resolutions higher than 1024x768 for a long time now, perhaps as long as 15+ years. There are quite a wide variety of native resolutions in use today, however, and in wide screen form factors the height may not be all that tall. None the less, it is considered that there is scope for making the QEMU default resolution slightly larger. In considering what possible new default could be suitable, choices considered were 1280x720 (720p), 1280x800 (WXGA) and 1280x1024 (SXGA). In many ways, vertical space is the most important, and so 720p was discarded due to loosing vertical space, despite being 25% wider. The SXGA resolution would be good, but when taking into account window titlebars/toolbars and window manager desktop UI, this might be a little too tall for some users to fit the guest on their physical montior. This patch thus suggests a modest change to 1280x800 (WXGA). This only consumes 1 MB per colour channel, allowing double buffered framebuffer in 8 MB of VRAM. Width wise this is 25% larger than QEMU's current default, but height wise this only adds 5%, so the difference isn't massive on the QEMU side. Overall there doesn't appear to be a compelling reason to stick with 1024x768 resolution. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Message-Id: <20211129140508.1745130-1-berrange@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2022-01-13hw/mips/jazz: Inline vga_mmio_init() and remove itPhilippe Mathieu-Daudé
vga_mmio_init() is used only one time and not very helpful, inline and remove it. Reviewed-by: BALATON Zoltan <balaton@eik.bme.hu> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20211206224528.563588-5-f4bug@amsat.org> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2022-01-13hw/display/vga-mmio: QOM'ify vga_mmio_init() as TYPE_VGA_MMIOPhilippe Mathieu-Daudé
Introduce TYPE_VGA_MMIO, a sysbus device. While there is no change in the vga_mmio_init() interface, this is a migration compatibility break of the MIPS Acer Pica 61 Jazz machine (pica61). Suggested-by: Thomas Huth <thuth@redhat.com> Reviewed-by: BALATON Zoltan <balaton@eik.bme.hu> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20211206224528.563588-4-f4bug@amsat.org> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2022-01-13hw/display: Rename VGA_ISA_MM -> VGA_MMIOPhilippe Mathieu-Daudé
There is no ISA bus part in the MMIO VGA device, so rename: * hw/display/vga-isa-mm.c -> hw/display/vga-mmio.c * CONFIG_VGA_ISA_MM -> CONFIG_VGA_MMIO * ISAVGAMMState -> VGAMmioState * isa_vga_mm_init() -> vga_mmio_init() Reviewed-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20211206224528.563588-2-f4bug@amsat.org> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2022-01-12virtio: unify dataplane and non-dataplane ->handle_output()Stefan Hajnoczi
Now that virtio-blk and virtio-scsi are ready, get rid of the handle_aio_output() callback. It's no longer needed. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Message-id: 20211207132336.36627-7-stefanha@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2022-01-12virtio-blk: drop unused virtio_blk_handle_vq() return valueStefan Hajnoczi
The return value of virtio_blk_handle_vq() is no longer used. Get rid of it. This is a step towards unifying the dataplane and non-dataplane virtqueue handler functions. Prepare virtio_blk_handle_output() to be used by both dataplane and non-dataplane by making the condition for starting ioeventfd more specific. This way it won't trigger when dataplane has already been started. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Message-id: 20211207132336.36627-4-stefanha@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2022-01-12virtio: get rid of VirtIOHandleAIOOutputStefan Hajnoczi
The virtqueue host notifier API virtio_queue_aio_set_host_notifier_handler() polls the virtqueue for new buffers. AioContext previously required a bool progress return value indicating whether an event was handled or not. This is no longer necessary because the AioContext polling API has been split into a poll check function and an event handler function. The event handler is only run when we know there is work to do, so it doesn't return bool. The VirtIOHandleAIOOutput function signature is now the same as VirtIOHandleOutput. Get rid of the bool return value. Further simplifications will be made for virtio-blk and virtio-scsi in the next patch. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Message-id: 20211207132336.36627-3-stefanha@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2022-01-12ppc/pnv: turn pnv_phb4_update_regions() into staticDaniel Henrique Barboza
Its only callers are inside pnv_phb4.c. Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220111131027.599784-6-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-12ppc/pnv: turn 'phb' into a pointer in struct PnvPhb4PecStackDaniel Henrique Barboza
At this moment, stack->phb is the plain PnvPHB4 device itself instead of a pointer to the device. This will present a problem when adding user creatable devices because we can't deal with this struct and the realize() callback from the user creatable device. We can't get rid of this attribute, similar to what we did when enabling pnv-phb3 user creatable devices, because pnv_phb4_update_regions() needs to access stack->phb to do its job. This function is called twice in pnv_pec_stk_update_map(), which is one of the nested xscom write callbacks (via pnv_pec_stk_nest_xscom_write()). In fact, pnv_pec_stk_update_map() code comment is explicit about how the order of the unmap/map operations relates with the PHB subregions. All of this indicates that this code is tied together in a way that we either go on a crusade, featuring lots of refactories and redesign and considerable pain, to decouple stack and phb mapping, or we allow stack update_map operations to access the associated PHB as it is today even after introducing pnv-phb4 user devices. This patch chooses the latter. Instead of getting rid of stack->phb, turn it into a PHB pointer. This will allow us to assign an user created PHB to an existing stack later. In this process, pnv_pec_stk_instance_init() is removed because stack->phb is being initialized in stk_realize() instead. Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220111131027.599784-4-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-12pnv_phb4_pec.c: move pnv_pec_phb_offset() to pnv_phb4.cDaniel Henrique Barboza
The logic inside pnv_pec_phb_offset() will be useful in the next patch to determine the stack that should contain a PHB4 device. Move the function to pnv_phb4.c and make it public since there's no pnv_phb4_pec.h header. While we're at it, add 'stack_index' as a parameter and make the function return 'phb-id' directly. And rename it to pnv_phb4_pec_get_phb_id() to be even clearer about the function intent. Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220110143346.455901-3-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-12pnv_phb4.c: change TYPE_PNV_PHB4_ROOT_BUS nameDaniel Henrique Barboza
Similar to what was happening with pnv-phb3 buses, TYPE_PNV_PHB4_ROOT_BUS set to "pnv-phb4-root-bus" is a bit too long for a default root bus name. The usual default name for theses buses in QEMU are 'pcie', but we want to make a distinction between pnv-phb4 buses and other PCIE buses, at least as far as default name goes, because not all PCIE devices are attachable to a pnv-phb4 root-bus type. Changing the default to 'pnv-phb4-root' allow us to have a shorter name while making this bus distinct, and the user can always set its own bus naming via the "id" attribute anyway. This is the 'info qtree' output after this change, using a powernv9 domain with 2 sockets and default settings enabled: qemu-system-ppc64 -m 4G -machine powernv9,accel=tcg \ -smp 2,sockets=2,cores=1,threads=1 dev: pnv-phb4, id "" index = 5 (0x5) chip-id = 1 (0x1) version = 704374636546 (0xa400000002) device-id = 1217 (0x4c1) x-config-reg-migration-enabled = true bypass-iommu = false bus: pnv-phb4-root.11 type pnv-phb4-root dev: pnv-phb4-root-port, id "" (...) dev: pnv-phb4, id "" index = 0 (0x0) chip-id = 1 (0x1) version = 704374636546 (0xa400000002) device-id = 1217 (0x4c1) x-config-reg-migration-enabled = true bypass-iommu = false bus: pnv-phb4-root.6 type pnv-phb4-root dev: pnv-phb4-root-port, id "" (..) dev: pnv-phb4, id "" index = 5 (0x5) chip-id = 0 (0x0) version = 704374636546 (0xa400000002) device-id = 1217 (0x4c1) x-config-reg-migration-enabled = true bypass-iommu = false bus: pnv-phb4-root.5 type pnv-phb4-root dev: pnv-phb4-root-port, id "" (...) dev: pnv-phb4, id "" index = 0 (0x0) chip-id = 0 (0x0) version = 704374636546 (0xa400000002) device-id = 1217 (0x4c1) x-config-reg-migration-enabled = true bypass-iommu = false bus: pnv-phb4-root.0 type pnv-phb4-root dev: pnv-phb4-root-port, id "" Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220110143346.455901-11-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-12pnv_phb3.h: change TYPE_PNV_PHB3_ROOT_BUS nameDaniel Henrique Barboza
The TYPE_PNV_PHB3_ROOT_BUS name is used as the default bus name when the dev has no 'id'. However, pnv-phb3-root-bus is a bit too long to be used as a bus name. Most common QEMU buses and PCI controllers are named based on their bus type (e.g. pSeries spapr-pci-host-bridge is called 'pci'). The most common name for a PCIE bus controller in QEMU is 'pcie'. Naming it 'pcie' would break the documented use of the pnv-phb3 device, since 'pcie.0' would now refer to the root bus instead of the first root port. There's nothing particularly wrong with the 'root-bus' name used before, aside from the fact that 'root-bus' is being used for pnv-phb3 and pnv-phb4 created buses, which is not quite correct since these buses aren't implemented the same way in QEMU - you can't plug a pnv-phb4-root-port into a pnv-phb3 root bus, for example. This patch renames it as 'pnv-phb3-root', which is a compromise between the existing and the previously used name. Creating 3 phbs without ID will result in an "info qtree" output similar to this: bus: main-system-bus type System dev: pnv-phb3, id "" index = 2 (0x2) chip-id = 0 (0x0) x-config-reg-migration-enabled = true bypass-iommu = false bus: pnv-phb3-root.2 type pnv-phb3-root (...) dev: pnv-phb3, id "" index = 1 (0x1) chip-id = 0 (0x0) x-config-reg-migration-enabled = true bypass-iommu = false bus: pnv-phb3-root.1 type pnv-phb3-root (...) dev: pnv-phb3, id "" index = 0 (0x0) chip-id = 0 (0x0) x-config-reg-migration-enabled = true bypass-iommu = false bus: pnv-phb3-root.0 type pnv-phb3-root Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220105212338.49899-11-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-12ppc/pnv: Move num_phbs under Pnv8ChipCédric Le Goater
It is not used elsewhere so that's where it belongs. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220105212338.49899-10-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-12ppc/pnv: Reparent user created PHB3 devices to the PnvChipCédric Le Goater
The powernv machine uses the object hierarchy to populate the device tree and each device should be parented to the chip it belongs to. This is not the case for user created devices which are parented to the container "/unattached". Make sure a PHB3 device is parented to its chip by reparenting the object if necessary. Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220105212338.49899-8-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-12ppc/pnv: Introduce support for user created PHB3 devicesCédric Le Goater
PHB3 devices and PCI devices can now be added to the powernv8 machine using : -device pnv-phb3,chip-id=0,index=1 \ -device nec-usb-xhci,bus=pci.1,addr=0x0 The 'index' property identifies the PHB3 in the chip. In case of user created devices, a lookup on 'chip-id' is required to assign the owning chip. Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220105212338.49899-7-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-12pnv_phb4.c: make pnv-phb4-root-port user creatableDaniel Henrique Barboza
We want to create only the absolutely minimal amount of devices when running with -nodefaults. The root port is something that the machine can boot up without. But, to do that, we need to provide a way for the user to add them by hand. This patch makes pnv-phb4-root-port user creatable and then uses the pnv_phb_attach_root_port() helper to add a pnv_phb4_root_port only when running with default settings. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220105212338.49899-5-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-12ppc/pnv: Attach PHB3 root port device when defaults are enabledCédric Le Goater
This cleanups the PHB3 model a bit more since the root port is an independent device and it will ease our task when adding user created PHB3s. pnv_phb_attach_root_port() is made public in pnv.c so it can be reused with the pnv_phb4 root port later. Signed-off-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220105212338.49899-4-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-11Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into stagingPeter Maydell
virtio: revert config interrupt changes Lots of fallout from config interrupt changes. Author wants to rework the patches. Let's revert quickly so others don't suffer meanwhile. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> # gpg: Signature made Mon 10 Jan 2022 21:03:44 GMT # gpg: using RSA key 5D09FD0871C8F85B94CA8A0D281F0DB8D28D5469 # gpg: issuer "mst@redhat.com" # gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>" [full] # gpg: aka "Michael S. Tsirkin <mst@redhat.com>" [full] # Primary key fingerprint: 0270 606B 6F3C DF3D 0B17 0970 C350 3912 AFBE 8E67 # Subkey fingerprint: 5D09 FD08 71C8 F85B 94CA 8A0D 281F 0DB8 D28D 5469 * remotes/mst/tags/for_upstream: Revert "virtio: introduce macro IRTIO_CONFIG_IRQ_IDX" Revert "virtio-pci: decouple notifier from interrupt process" Revert "virtio-pci: decouple the single vector from the interrupt process" Revert "vhost: introduce new VhostOps vhost_set_config_call" Revert "vhost-vdpa: add support for config interrupt" Revert "virtio: add support for configure interrupt" Revert "vhost: add support for configure interrupt" Revert "virtio-net: add support for configure interrupt" Revert "virtio-mmio: add support for configure interrupt" Revert "virtio-pci: add support for configure interrupt" Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-01-10Revert "virtio: introduce macro IRTIO_CONFIG_IRQ_IDX"Michael S. Tsirkin
This reverts commit bf1d85c166c19af95dbd27b1faba1d2909732323. Fixes: bf1d85c166 ("virtio: introduce macro IRTIO_CONFIG_IRQ_IDX") Cc: "Cindy Lu" <lulu@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-01-10Revert "vhost: introduce new VhostOps vhost_set_config_call"Michael S. Tsirkin
This reverts commit 88062372340d33090b7f089ed3b1a00f530a8914. Fixes: 8806237234 ("vhost: introduce new VhostOps vhost_set_config_call") Cc: "Cindy Lu" <lulu@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-01-10Revert "virtio: add support for configure interrupt"Michael S. Tsirkin
This reverts commit 081f864f56307551f59c5e934e3f30a7290d0faa. Fixes: 081f864f56 ("virtio: add support for configure interrupt") Cc: "Cindy Lu" <lulu@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-01-10Revert "vhost: add support for configure interrupt"Michael S. Tsirkin
This reverts commit f7220a7ce21604a4bc6260ccca4dc9068c1f27f2. Fixes: f7220a7ce2 ("vhost: add support for configure interrupt") Cc: "Cindy Lu" <lulu@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-01-08hw/riscv: virt: Allow support for 32 coresAlistair Francis
Linux supports up to 32 cores for both 32-bit and 64-bit RISC-V, so let's set that as the maximum for the virt board. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/435 Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Anup Patel <anup.patel@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Message-Id: <20220105213937.1113508-9-alistair.francis@opensource.wdc.com>
2022-01-07Merge tag 'for_upstream' of git://git.kernel.org/pub/scm/virt/kvm/mst/qemu ↵Richard Henderson
into staging virtio,pci,pc: features,fixes,cleanups New virtio mem options. A vhost-user cleanup. Control over smbios entry point type. Config interrupt support for vdpa. Fixes, cleanups all over the place. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> # gpg: Signature made Fri 07 Jan 2022 04:30:41 PM PST # gpg: using RSA key 5D09FD0871C8F85B94CA8A0D281F0DB8D28D5469 # gpg: issuer "mst@redhat.com" # gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>" [undefined] # gpg: aka "Michael S. Tsirkin <mst@redhat.com>" [undefined] # gpg: WARNING: This key is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: 0270 606B 6F3C DF3D 0B17 0970 C350 3912 AFBE 8E67 # Subkey fingerprint: 5D09 FD08 71C8 F85B 94CA 8A0D 281F 0DB8 D28D 5469 * tag 'for_upstream' of git://git.kernel.org/pub/scm/virt/kvm/mst/qemu: (55 commits) tests: acpi: Add updated TPM related tables acpi: tpm: Add missing device identification objects tests: acpi: prepare for updated TPM related tables virtio/vhost-vsock: don't double close vhostfd, remove redundant cleanup hw/scsi/vhost-scsi: don't double close vhostfd on error hw/scsi/vhost-scsi: don't leak vqs on error docs: reSTify virtio-balloon-stats documentation and move to docs/interop hw/i386/pc: Add missing property descriptions acpihp: simplify acpi_pcihp_disable_root_bus tests: acpi: SLIC: update expected blobs tests: acpi: add SLIC table test tests: acpi: whitelist expected blobs before changing them acpi: fix QEMU crash when started with SLIC table intel-iommu: correctly check passthrough during translation virtio-mem: Set "unplugged-inaccessible=auto" for the 7.0 machine on x86 virtio-mem: Support VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE linux-headers: sync VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE MAINTAINERS: Add a separate entry for acpi/VIOT tables virtio: signal after wrapping packed used_idx virtio-mem: Support "prealloc=on" option ... Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2022-01-07virtio-mem: Support VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLEDavid Hildenbrand
With VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE, we signal the VM that reading unplugged memory is not supported. We have to fail feature negotiation in case the guest does not support VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE. First, VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE is required to properly handle memory backends (or architectures) without support for the shared zeropage in the hypervisor cleanly. Without the shared zeropage, even reading an unpopulated virtual memory location can populate real memory and consequently consume memory in the hypervisor. We have a guaranteed shared zeropage only on MAP_PRIVATE anonymous memory. Second, we want VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE to be the default long-term as even populating the shared zeropage can be problematic: for example, without THP support (possible) or without support for the shared huge zeropage with THP (unlikely), the PTE page tables to hold the shared zeropage entries can consume quite some memory that cannot be reclaimed easily. Third, there are other optimizations+features (e.g., protection of unplugged memory, reducing the total memory slot size and bitmap sizes) that will require VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE. We really only support x86 targets with virtio-mem for now (and Linux similarly only support x86), but that might change soon, so prepare for different targets already. Add a new "unplugged-inaccessible" tristate property for x86 targets: - "off" will keep VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE unset and legacy guests working. - "on" will set VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE and stop legacy guests from using the device. - "auto" selects the default based on support for the shared zeropage. Warn in case the property is set to "off" and we don't have support for the shared zeropage. For existing compat machines, the property will default to "off", to not change the behavior but eventually warn about a problematic setup. Short-term, we'll set the property default to "auto" for new QEMU machines. Mid-term, we'll set the property default to "on" for new QEMU machines. Long-term, we'll deprecate the parameter and disallow legacy guests completely. The property has to match on the migration source and destination. "auto" will result in the same VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE setting as long as the qemu command line (esp. memdev) match -- so "auto" is good enough for migration purposes and the parameter doesn't have to be migrated explicitly. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20211217134039.29670-3-david@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-01-07virtio-mem: Support "prealloc=on" optionDavid Hildenbrand
For scarce memory resources, such as hugetlb, we want to be able to prealloc such memory resources in order to not crash later on access. On simple user errors we could otherwise easily run out of memory resources an crash the VM -- pretty much undesired. For ordinary memory devices, such as DIMMs, we preallocate memory via the memory backend for such use cases; however, with virtio-mem we're dealing with sparse memory backends; preallocating the whole memory backend destroys the whole purpose of virtio-mem. Instead, we want to preallocate memory when actually exposing memory to the VM dynamically, and fail plugging memory gracefully + warn the user in case preallocation fails. A common use case for hugetlb will be using "reserve=off,prealloc=off" for the memory backend and "prealloc=on" for the virtio-mem device. This way, no huge pages will be reserved for the process, but we can recover if there are no actual huge pages when plugging memory. Libvirt is already prepared for this. Note that preallocation cannot protect from the OOM killer -- which holds true for any kind of preallocation in QEMU. It's primarily useful only for scarce memory resources such as hugetlb, or shared file-backed memory. It's of little use for ordinary anonymous memory that can be swapped, KSM merged, ... but we won't forbid it. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20211217134611.31172-9-david@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-01-07hw/intc/arm_gicv3_its: Fix various off-by-one errorsPeter Maydell
The ITS code has to check whether various parameters passed in commands are in-bounds, where the limit is defined in terms of the number of bits that are available for the parameter. (For example, the GITS_TYPER.Devbits ID register field specifies the number of DeviceID bits minus 1, and device IDs passed in the MAPTI and MAPD command packets must fit in that many bits.) Currently we have off-by-one bugs in many of these bounds checks. The typical problem is that we define a max_foo as 1 << n. In the Devbits example, we set s->dt.max_ids = 1UL << (GITS_TYPER.Devbits + 1). However later when we do the bounds check we write if (devid > s->dt.max_ids) { /* command error */ } which incorrectly permits a devid of 1 << n. These bugs will not cause QEMU crashes because the ID values being checked are only used for accesses into tables held in guest memory which we access with address_space_*() functions, but they are incorrect behaviour of our emulation. Fix them by standardizing on this pattern: * bounds limits are named num_foos and are the 2^n value (equal to the number of valid foo values) * bounds checks are either if (fooid < num_foos) { good } or if (fooid >= num_foos) { bad } In this commit we fix the handling of the number of IDs in the device table and the collection table, and the number of commands that will fit in the command queue. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
2022-01-07hw/intc/arm_gicv3_its: Remove maxids union from TableDescPeter Maydell
The TableDesc struct defines properties of the in-guest-memory tables which the guest tells us about by writing to the GITS_BASER<n> registers. This struct currently has a union 'maxids', but all the fields of the union have the same type (uint32_t) and do the same thing (record one-greater-than the maximum ID value that can be used as an index into the table). We're about to add another table type (the GICv4 vPE table); rather than adding another specifically-named union field for that table type with the same type as the other union fields, remove the union entirely and just have a 'uint32_t max_ids' struct field. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
2022-01-07Add dummy Aspeed AST2600 Display Port MCU (DPMCU)Troy Lee
AST2600 Display Port MCU introduces 0x18000000~0x1803FFFF as it's memory and io address. If guest machine try to access DPMCU memory, it will cause a fatal error. Signed-off-by: Troy Lee <troy_lee@aspeedtech.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-id: 20211210083034.726610-1-troy_lee@aspeedtech.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-01-07hw/i386: expose a "smbios-entry-point-type" PC machine propertyEduardo Habkost
The i440fx and Q35 machine types are both hardcoded to use the legacy SMBIOS 2.1 (32-bit) entry point. This is a sensible conservative choice because SeaBIOS only supports SMBIOS 2.1 EDK2, however, can also support SMBIOS 3.0 (64-bit) entry points, and QEMU already uses this on the ARM virt machine type. This adds a property to allow the choice of SMBIOS entry point versions For example to opt in to 64-bit SMBIOS entry point: $QEMU -machine q35,smbios-entry-point-type=64 Based on a patch submitted by Daniel Berrangé. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20211026151100.1691925-4-ehabkost@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2022-01-07hw/smbios: Use qapi for SmbiosEntryPointTypeEduardo Habkost
This prepares for exposing the SMBIOS entry point type as a machine property on x86. Based on a patch from Daniel P. Berrangé. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20211026151100.1691925-3-ehabkost@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Acked-by: Markus Armbruster <armbru@redhat.com>
2022-01-07smbios: Rename SMBIOS_ENTRY_POINT_* enumsEduardo Habkost
Rename the enums to match the naming style used by QAPI, and to use "32" and "64" instead of "20" and "31". This will allow us to more easily move the enum to the QAPI schema later. About the naming choice: "SMBIOS 2.1 entry point"/"SMBIOS 3.0 entry point" and "32-bit entry point"/"64-bit entry point" are synonymous in the SMBIOS specification. However, the phrases "32-bit entry point" and "64-bit entry point" are used more often. The new names also avoid confusion between the entry point format and the actual SMBIOS version reported in the entry point structure. For example: currently the 32-bit entry point actually report SMBIOS 2.8 support, not 2.1. Based on portions of a patch submitted by Daniel P. Berrangé. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20211026151100.1691925-2-ehabkost@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-01-07pci: Export the pci_intx() functionFrederic Barrat
Move the pci_intx() definition to the PCI header file, so that it can be called from other PCI files. It is used by the next patch. Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20211116170133.724751-3-fbarrat@linux.ibm.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Cédric Le Goater <clg@kaod.org>
2022-01-06Merge tag 'linux-user-for-7.0-pull-request' of ↵Richard Henderson
https://gitlab.com/laurent_vivier/qemu into staging linux-user pull request 20220106 update netlink entries nios2 fixes /proc/self/maps fixes set/getscheduler update prctl cleanup and fixes target_signal.h cleanup and some trivial fixes # gpg: Signature made Thu 06 Jan 2022 02:41:07 AM PST # gpg: using RSA key CD2F75DDC8E3A4DC2E4F5173F30C38BD3F2FBE3C # gpg: issuer "laurent@vivier.eu" # gpg: Good signature from "Laurent Vivier <lvivier@redhat.com>" [undefined] # gpg: aka "Laurent Vivier <laurent@vivier.eu>" [undefined] # gpg: aka "Laurent Vivier (Red Hat) <lvivier@redhat.com>" [undefined] # gpg: WARNING: This key is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: CD2F 75DD C8E3 A4DC 2E4F 5173 F30C 38BD 3F2F BE3C * tag 'linux-user-for-7.0-pull-request' of https://gitlab.com/laurent_vivier/qemu: (27 commits) linux-user: netlink: update IFLA_BRPORT entries linux-user: netlink: Add IFLA_VFINFO_LIST linux-user: netlink: update IFLA entries linux-user/syscall.c: malloc to g_try_malloc linux-user/nios2: Use set_sigmask in do_rt_sigreturn linux-user/nios2: Fix sigmask in setup_rt_frame linux-user/nios2: Fix EA vs PC confusion linux-user/nios2: Map a real kuser page linux-user/elfload: Rename ARM_COMMPAGE to HI_COMMPAGE linux-user/nios2: Fixes for signal frame setup linux-user/nios2: Properly emulate EXCP_TRAP linux-user/syscall.c: fix missed flag for shared memory in open_self_maps linux-user: call set/getscheduler set/getparam directly linux-user: add sched_getattr support linux-user/signal: Map exit signals in SIGCHLD siginfo_t target/sh4: Implement prctl_unalign_sigbus target/hppa: Implement prctl_unalign_sigbus target/alpha: Implement prctl_unalign_sigbus linux-user: Add code for PR_GET/SET_UNALIGN linux-user: Disable more prctl subcodes ... Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2022-01-06vhost: add support for configure interruptCindy Lu
Add functions to support configure interrupt. The configure interrupt process will start in vhost_dev_start and stop in vhost_dev_stop. Also add the functions to support vhost_config_pending and vhost_config_mask, for masked_config_notifier, we only use the notifier saved in vq 0. Signed-off-by: Cindy Lu <lulu@redhat.com> Message-Id: <20211104164827.21911-8-lulu@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-01-06virtio: add support for configure interruptCindy Lu
Add the functions to support the configure interrupt in virtio The function virtio_config_guest_notifier_read will notify the guest if there is an configure interrupt. The function virtio_config_set_guest_notifier_fd_handler is to set the fd hander for the notifier Signed-off-by: Cindy Lu <lulu@redhat.com> Message-Id: <20211104164827.21911-7-lulu@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-01-06vhost: introduce new VhostOps vhost_set_config_callCindy Lu
This patch introduces new VhostOps vhost_set_config_call. This function allows the vhost to set the event fd to kernel Signed-off-by: Cindy Lu <lulu@redhat.com> Message-Id: <20211104164827.21911-5-lulu@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-01-06virtio: introduce macro IRTIO_CONFIG_IRQ_IDXCindy Lu
To support configure interrupt for vhost-vdpa Introduce VIRTIO_CONFIG_IRQ_IDX -1 as configure interrupt's queue index, Then we can reuse the functions guest_notifier_mask and guest_notifier_pending. Add the check of queue index in these drivers, if the driver does not support configure interrupt, the function will just return Signed-off-by: Cindy Lu <lulu@redhat.com> Message-Id: <20211104164827.21911-2-lulu@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-01-06linux-user: Add code for PR_GET/SET_UNALIGNRichard Henderson
This requires extra work for each target, but adds the common syscall code, and the necessary flag in CPUState. Reviewed-by: Warner Losh <imp@bsdimp.com> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20211227150127.2659293-4-richard.henderson@linaro.org> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2022-01-05hw: Add compat machines for 7.0Cornelia Huck
Add 7.0 machine types for arm/i440fx/q35/s390x/spapr. Signed-off-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Acked-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20211217143948.289995-1-cohuck@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>