aboutsummaryrefslogtreecommitdiff
path: root/hw
AgeCommit message (Collapse)AuthorFilesLines
2020-02-13hw/char/exynos4210_uart: Fix memleaks in exynos4210_uart_initChen Qun1-2/+3
It's easy to reproduce as follow: virsh qemu-monitor-command vm1 --pretty '{"execute": "device-list-properties", "arguments":{"typename":"exynos4210.uart"}}' ASAN shows memory leak stack: #1 0xfffd896d71cb in g_malloc0 (/lib64/libglib-2.0.so.0+0x571cb) #2 0xaaad270beee3 in timer_new_full /qemu/include/qemu/timer.h:530 #3 0xaaad270beee3 in timer_new /qemu/include/qemu/timer.h:551 #4 0xaaad270beee3 in timer_new_ns /qemu/include/qemu/timer.h:569 #5 0xaaad270beee3 in exynos4210_uart_init /qemu/hw/char/exynos4210_uart.c:677 #6 0xaaad275c8f4f in object_initialize_with_type /qemu/qom/object.c:516 #7 0xaaad275c91bb in object_new_with_type /qemu/qom/object.c:684 #8 0xaaad2755df2f in qmp_device_list_properties /qemu/qom/qom-qmp-cmds.c:152 Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Chen Qun <kuhn.chenqun@huawei.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20200213025603.149432-1-kuhn.chenqun@huawei.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13hw/arm: ast2600: Wire up EHCI controllersGuenter Roeck1-0/+23
Initialize EHCI controllers on AST2600 using the existing TYPE_PLATFORM_EHCI. After this change, booting ast2600-evb into Linux successfully instantiates a USB interface after the necessary changes are made to its devicetree files. ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver ehci-platform: EHCI generic platform driver ehci-platform 1e6a3000.usb: EHCI Host Controller ehci-platform 1e6a3000.usb: new USB bus registered, assigned bus number 1 ehci-platform 1e6a3000.usb: irq 25, io mem 0x1e6a3000 ehci-platform 1e6a3000.usb: USB 2.0 started, EHCI 1.00 usb usb1: Manufacturer: Linux 5.5.0-09825-ga0802f2d0ef5-dirty ehci_hcd usb 1-1: new high-speed USB device number 2 using ehci-platform Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Niek Linnenbank <nieklinnenbank@gmail.com> Message-id: 20200207174548.9087-1-linux@roeck-us.net Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13hw/arm: ast2400/ast2500: Wire up EHCI controllersGuenter Roeck1-0/+25
Initialize EHCI controllers on AST2400 and AST2500 using the existing TYPE_PLATFORM_EHCI. After this change, booting ast2500-evb into Linux successfully instantiates a USB interface. ehci-platform 1e6a3000.usb: EHCI Host Controller ehci-platform 1e6a3000.usb: new USB bus registered, assigned bus number 1 ehci-platform 1e6a3000.usb: irq 21, io mem 0x1e6a3000 ehci-platform 1e6a3000.usb: USB 2.0 started, EHCI 1.00 usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.05 usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: EHCI Host Controller Signed-off-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20200206183437.3979-1-linux@roeck-us.net Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13arm/acpi: simplify the description of PCI _CRSHeyi Guo1-1/+0
The original code defines a named object for the resource template but then returns the resource template object itself; the resulted output is like below: Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings { Name (RBUF, ResourceTemplate () { WordBusNumber (ResourceProducer, MinFixed, MaxFixed, PosDecode, 0x0000, // Granularity 0x0000, // Range Minimum 0x00FF, // Range Maximum 0x0000, // Translation Offset 0x0100, // Length ,, ) ...... }) Return (ResourceTemplate () { WordBusNumber (ResourceProducer, MinFixed, MaxFixed, PosDecode, 0x0000, // Granularity 0x0000, // Range Minimum 0x00FF, // Range Maximum 0x0000, // Translation Offset 0x0100, // Length ,, ) ...... }) } So the named object "RBUF" is actually useless. The more natural way is to return RBUF instead, or simply drop RBUF definition. Choose the latter one to simplify the code. Signed-off-by: Heyi Guo <guoheyi@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-id: 20200204014325.16279-7-guoheyi@huawei.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13arm/acpi: fix duplicated _UID of PCI interrupt link devicesHeyi Guo1-1/+1
Using _UID of 0 for all PCI interrupt link devices absolutely violates the spec. Simply increase one by one. Signed-off-by: Heyi Guo <guoheyi@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-id: 20200204014325.16279-6-guoheyi@huawei.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13arm/acpi: fix PCI _PRT definitionHeyi Guo1-5/+5
The address field in each _PRT mapping package should be constructed with high word for device# and low word for function#, so it is wrong to use bus_no as the high word. The existing code adds a bunch useless entries with device #s above 31. Enumerate all possible slots (i.e. PCI_SLOT_MAX) instead. Signed-off-by: Heyi Guo <guoheyi@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-id: 20200204014325.16279-5-guoheyi@huawei.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13arm/virt/acpi: remove _ADR from devices identified by _HIDHeyi Guo1-8/+0
According to ACPI spec, _ADR should be used for device on a bus that has a standard enumeration algorithm, but not for device which is on system bus and must be enumerated by OSPM. And it is not recommended to contain both _HID and _ADR in a single device. See ACPI 6.3, section 6.1, top of page 343: A device object must contain either an _HID object or an _ADR object, but should not contain both. (https://uefi.org/sites/default/files/resources/ACPI_6_3_May16.pdf) Signed-off-by: Heyi Guo <guoheyi@huawei.com> Acked-by: Igor Mammedov <imammedo@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-id: 20200204014325.16279-4-guoheyi@huawei.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13arm/virt/acpi: remove meaningless sub device "RP0" from PCI0Heyi Guo1-4/+0
The sub device "RP0" under PCI0 in ACPI/DSDT does not contain any method or property other than "_ADR", so it is safe to remove it. Signed-off-by: Heyi Guo <guoheyi@huawei.com> Acked-by: "Michael S. Tsirkin" <mst@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-id: 20200204014325.16279-3-guoheyi@huawei.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13i.MX: Add support for WDT on i.MX6Roman Kapl1-0/+21
Uses the i.MX2 rudimentary watchdog driver. Signed-off-by: Roman Kapl <rka@sysgo.com> Message-id: 20200207095529.11309-1-rka@sysgo.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> [PMM: removed accidental duplicate #include line] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13i.MX: Fix inverted register bits in wdt code.Roman Kapl1-1/+1
Documentation says for WDA '0: Assert WDOG output.' and for SRS '0: Assert system reset signal.'. Signed-off-by: Roman Kapl <rka@sysgo.com> Message-id: 20200207095409.11227-1-rka@sysgo.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-10Merge remote-tracking branch 'remotes/stefanha/tags/block-pull-request' into ↵Peter Maydell1-1/+2
staging Pull request # gpg: Signature made Mon 10 Feb 2020 09:23:42 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/tags/block-pull-request: hw/core: Allow setting 'virtio-blk-device.scsi' property on OSX host block: fix crash on zero-length unaligned write and read Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-10Merge remote-tracking branch 'remotes/gkurz/tags/9p-next-2020-02-08' into ↵Peter Maydell4-0/+56
staging 9p patches: - some more protocol sanity checks - qtest for readdir - Christian Schoenebeck now official reviewer # gpg: Signature made Sat 08 Feb 2020 08:38:10 GMT # gpg: using RSA key B4828BAF943140CEF2A3491071D4D5E5822F73D6 # gpg: Good signature from "Greg Kurz <groug@kaod.org>" [full] # gpg: aka "Gregory Kurz <gregory.kurz@free.fr>" [full] # gpg: aka "[jpeg image of size 3330]" [full] # Primary key fingerprint: B482 8BAF 9431 40CE F2A3 4910 71D4 D5E5 822F 73D6 * remotes/gkurz/tags/9p-next-2020-02-08: MAINTAINERS: 9pfs: Add myself as reviewer tests/virtio-9p: added readdir test hw/9pfs/9p-synth: added directory for readdir test 9pfs: validate count sent by client with T_readdir 9pfs: require msize >= 4096 tests/virtio-9p: add terminating null in v9fs_string_read() Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-08hw/9pfs/9p-synth: added directory for readdir testChristian Schoenebeck2-0/+24
This will provide the following virtual files by the 9pfs synth driver: - /ReadDirDir/ReadDirFile99 - /ReadDirDir/ReadDirFile98 ... - /ReadDirDir/ReadDirFile1 - /ReadDirDir/ReadDirFile0 This virtual directory and its virtual 100 files will be used by the upcoming 9pfs readdir tests. Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Reviewed-by: Greg Kurz <groug@kaod.org> Message-Id: <5408c28c8de25dd575b745cef63bf785305ccef2.1579567020.git.qemu_oss@crudebyte.com> Signed-off-by: Greg Kurz <groug@kaod.org>
2020-02-089pfs: validate count sent by client with T_readdirChristian Schoenebeck1-0/+9
A good 9p client sends T_readdir with "count" parameter that's sufficiently smaller than client's initially negotiated msize (maximum message size). We perform a check for that though to avoid the server to be interrupted with a "Failed to encode VirtFS reply type 41" transport error message by bad clients. This count value constraint uses msize - 11, because 11 is the header size of R_readdir. Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Reviewed-by: Greg Kurz <groug@kaod.org> Message-Id: <3990d3891e8ae2074709b56449e96ab4b4b93b7d.1579567020.git.qemu_oss@crudebyte.com> [groug: added comment ] Signed-off-by: Greg Kurz <groug@kaod.org>
2020-02-089pfs: require msize >= 4096Christian Schoenebeck2-0/+23
A client establishes a session by sending a Tversion request along with a 'msize' parameter which client uses to suggest server a maximum message size ever to be used for communication (for both requests and replies) between client and server during that session. If client suggests a 'msize' smaller than 4096 then deny session by server immediately with an error response (Rlerror for "9P2000.L" clients or Rerror for "9P2000.u" clients) instead of replying with Rversion. So far any msize submitted by client with Tversion was simply accepted by server without any check. Introduction of some minimum msize makes sense, because e.g. a msize < 7 would not allow any subsequent 9p operation at all, because 7 is the size of the header section common by all 9p message types. A substantial higher value of 4096 was chosen though to prevent potential issues with some message types. E.g. Rreadlink may yield up to a size of PATH_MAX which is usually 4096, and like almost all 9p message types, Rreadlink is not allowed to be truncated by the 9p protocol. This chosen size also prevents a similar issue with Rreaddir responses (provided client always sends adequate 'count' parameter with Treaddir), because even though directory entries retrieval may be split up over several T/Rreaddir messages; a Rreaddir response must not truncate individual directory entries though. So msize should be large enough to return at least one directory entry with the longest possible file name supported by host. Most file systems support a max. file name length of 255. Largest known file name lenght limit would be currently ReiserFS with max. 4032 bytes, which is also covered by this min. msize value because 4032 + 35 < 4096. Furthermore 4096 is already the minimum msize of the Linux kernel's 9pfs client. Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Reviewed-by: Greg Kurz <groug@kaod.org> Message-Id: <8ceecb7fb9fdbeabbe55c04339349a36929fb8e3.1579567019.git.qemu_oss@crudebyte.com> Signed-off-by: Greg Kurz <groug@kaod.org>
2020-02-07hw/core: Allow setting 'virtio-blk-device.scsi' property on OSX hostPhilippe Mathieu-Daudé1-1/+2
Commit ed65fd1a2750 ("virtio-blk: switch off scsi-passthrough by default") changed the default value of the 'scsi' property of virtio-blk, which is only available on Linux hosts. It also added an unconditional compat entry for 2.4 or earlier machines. Trying to set this property on a pre-2.5 machine on OSX, we get: Unexpected error in object_property_find() at qom/object.c:1201: qemu-system-x86_64: -device virtio-blk-pci,id=scsi0,drive=drive0: can't apply global virtio-blk-device.scsi=true: Property '.scsi' not found Fix this error by marking the property optional. Fixes: ed65fd1a27 ("virtio-blk: switch off scsi-passthrough by default") Suggested-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-id: 20200207001404.1739-1-philmd@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2020-02-07stellaris: delay timer_new to avoid memleaksPan Nengyuan1-1/+6
There is a memory leak when we call 'device_list_properties' with typename = stellaris-gptm. It's easy to reproduce as follow: virsh qemu-monitor-command vm1 --pretty '{"execute": "device-list-properties", "arguments": {"typename": "stellaris-gptm"}}' This patch delay timer_new in realize to fix it. Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20200205070659.22488-4-pannengyuan@huawei.com Cc: qemu-arm@nongnu.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-07stm32f2xx_timer: delay timer_new to avoid memleaksPan Nengyuan1-0/+5
There is a memory leak when we call 'device_list_properties' with typename = stm32f2xx_timer. It's easy to reproduce as follow: virsh qemu-monitor-command vm1 --pretty '{"execute": "device-list-properties", "arguments": {"typename": "stm32f2xx_timer"}}' This patch delay timer_new to fix this memleaks. Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20200205070659.22488-3-pannengyuan@huawei.com Cc: Alistair Francis <alistair@alistair23.me> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-07armv7m_systick: delay timer_new to avoid memleaksPan Nengyuan1-0/+6
There is a memory leak when we call 'device_list_properties' with typename = armv7m_systick. It's easy to reproduce as follow: virsh qemu-monitor-command vm1 --pretty '{"execute": "device-list-properties", "arguments": {"typename": "armv7m_systick"}}' This patch delay timer_new to fix this memleaks. Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com> Message-id: 20200205070659.22488-2-pannengyuan@huawei.com Cc: qemu-arm@nongnu.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-07bcm2835_dma: Re-initialize xlen in TD modeRene Stange1-1/+3
TD (two dimensions) DMA mode did not work, because the xlen variable has not been re-initialized before each additional ylen run through in bcm2835_dma_update(). Fix it. Signed-off-by: Rene Stange <rsta2@o2online.de> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-07bcm2835_dma: Fix the ylen loop in TD modeRene Stange1-2/+2
In TD (two dimensions) DMA mode ylen has to be increased by one after reading it from the TXFR_LEN register, because a value of zero has to result in one run through of the ylen loop. This has been tested on a real Raspberry Pi 3 Model B+. In the previous implementation the ylen loop was not passed at all for a value of zero. Signed-off-by: Rene Stange <rsta2@o2online.de> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-06hw/vfio: Move the IGD quirk code to a separate fileThomas Huth5-611/+642
The IGD quirk code defines a separate device, the so-called "vfio-pci-igd-lpc-bridge" which shows up as a user-creatable device in all QEMU binaries that include the vfio code. This is a little bit unfortunate for two reasons: First, this device is completely useless in binaries like qemu-system-s390x. Second we also would like to disable it in downstream RHEL which currently requires some extra patches there since the device does not have a proper Kconfig-style switch yet. So it would be good if the device could be disabled more easily, thus let's move the code to a separate file instead and introduce a proper Kconfig switch for it which gets only enabled by default if we also have CONFIG_PC_PCI enabled. Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2020-02-06aspeed/i2c: Prevent uninitialized warningMiroslav Rezanina1-1/+1
Compiler reports uninitialized warning for cmd_flags variable. Adding NULL initialization to prevent this warning. Signed-off-by: Miroslav Rezanina <mrezanin@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <07957dcab31f65de3dd30efa91e6b9152ac79879.1579598240.git.mrezanin@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2020-02-06hw/i386/vmmouse: Fix crash when using the vmmouse on a machine without vmportThomas Huth1-0/+6
QEMU currently crashes when the user tries to use the "vmmouse" on a machine without vmport, e.g.: $ x86_64-softmmu/qemu-system-x86_64 -machine microvm -device vmmouse Segmentation fault (core dumped) or: $ x86_64-softmmu/qemu-system-x86_64 -device vmmouse -M pc,vmport=off Segmentation fault (core dumped) Let's avoid the crash by checking for the vmport device first. Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Message-Id: <20200129112954.4282-1-thuth@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2020-02-06hw/bt: Remove empty Kconfig fileThomas Huth1-0/+0
While removing the bluetooth code some weeks ago, I had to leave the hw/bt/Kconfig file around. Otherwise some of the builds would have been broken since the generated dependency files tried to include it before they were rebuilt. Meanwhile, all those dependency files should have been updated, so we can remove the empty Kconfig file now, too. Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Message-Id: <20200123064525.6935-1-thuth@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2020-02-06hw/timer/m48t59: Convert debug printf()s to trace eventsPhilippe Mathieu-Daudé3-11/+11
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Hervé Poussineau <hpoussin@reactos.org> Message-Id: <20200117165809.31067-3-philmd@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2020-02-06hw/smbios/smbios: Remove unused includePhilippe Mathieu-Daudé1-1/+0
Nothing from "sysemu/cpus.h" is used by smbios.c, remove the include. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <20200109112504.32622-1-philmd@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2020-02-04hw/hppa/Kconfig: LASI chipset requires PARALLEL portPhilippe Mathieu-Daudé1-0/+1
The PARISC Lasi chipset emulation requires some of the common parallel support and fails to build on a --without-default-devices: LINK hppa-softmmu/qemu-system-hppa /usr/bin/ld: hw/hppa/lasi.o: in function `lasi_init': hw/hppa/lasi.c:324: undefined reference to `parallel_mm_init' collect2: error: ld returned 1 exit status make[1]: *** [Makefile:206: qemu-system-hppa] Error 1 Fixes: 376b851909d Reported-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200129192350.27143-1-philmd@redhat.com> Acked-by: Helge Deller <deller@gmx.de> Signed-off-by: Thomas Huth <thuth@redhat.com>
2020-02-04hw/input: Do not enable CONFIG_PCKBD by defaultThomas Huth2-1/+1
The i8042 PS/2 Controller should not be enabled by default. It has to be selected by machines or chipsets (e.g. SuperIO chipsets). Message-Id: <20200115113748.24757-1-thuth@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2020-02-04hw/*/Makefile.objs: Move many .o files to common-objsThomas Huth16-41/+40
We have many files that apparently do not depend on the target CPU configuration, i.e. which can be put into common-obj-y instead of obj-y. This way, the code can be shared for example between qemu-system-arm and qemu-system-aarch64, or the various big and little endian variants like qemu-system-sh4 and qemu-system-sh4eb, so that we do not have to compile the code multiple times anymore. Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20200130133841.10779-1-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2020-02-04trivial: Remove xenfb_enabled from sysemu.hThomas Huth1-1/+1
The define is only used in one other place. Move the code there instead of keeping this xen-specific define in sysemu.h. Message-Id: <20200121161747.10569-1-thuth@redhat.com> Acked-by: Paul Durrant <paul@xen.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2020-02-03ppc: spapr: Activate the FWNMI functionalityAravinda Prasad1-1/+2
This patch sets the default value of SPAPR_CAP_FWNMI_MCE to SPAPR_CAP_ON for machine type 5.0. Signed-off-by: Aravinda Prasad <arawinda.p@gmail.com> Signed-off-by: Ganesh Goudar <ganeshgr@linux.ibm.com> Message-Id: <20200130184423.20519-8-ganeshgr@linux.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-02-03migration: Include migration support for machine check handlingAravinda Prasad3-1/+64
This patch includes migration support for machine check handling. Especially this patch blocks VM migration requests until the machine check error handling is complete as these errors are specific to the source hardware and is irrelevant on the target hardware. Signed-off-by: Aravinda Prasad <arawinda.p@gmail.com> [Do not set FWNMI cap in post_load, now its done in .apply hook] Signed-off-by: Ganesh Goudar <ganeshgr@linux.ibm.com> Message-Id: <20200130184423.20519-7-ganeshgr@linux.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-02-03ppc: spapr: Handle "ibm,nmi-register" and "ibm,nmi-interlock" RTAS callsAravinda Prasad2-0/+69
This patch adds support in QEMU to handle "ibm,nmi-register" and "ibm,nmi-interlock" RTAS calls. The machine check notification address is saved when the OS issues "ibm,nmi-register" RTAS call. This patch also handles the case when multiple processors experience machine check at or about the same time by handling "ibm,nmi-interlock" call. In such cases, as per PAPR, subsequent processors serialize waiting for the first processor to issue the "ibm,nmi-interlock" call. The second processor that also received a machine check error waits till the first processor is done reading the error log. The first processor issues "ibm,nmi-interlock" call when the error log is consumed. Signed-off-by: Aravinda Prasad <arawinda.p@gmail.com> [Register fwnmi RTAS calls in core_rtas_register_types() where other RTAS calls are registered] Signed-off-by: Ganesh Goudar <ganeshgr@linux.ibm.com> Message-Id: <20200130184423.20519-6-ganeshgr@linux.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-02-03target/ppc: Build rtas error log upon an MCEAravinda Prasad2-1/+245
Upon a machine check exception (MCE) in a guest address space, KVM causes a guest exit to enable QEMU to build and pass the error to the guest in the PAPR defined rtas error log format. This patch builds the rtas error log, copies it to the rtas_addr and then invokes the guest registered machine check handler. The handler in the guest takes suitable action(s) depending on the type and criticality of the error. For example, if an error is unrecoverable memory corruption in an application inside the guest, then the guest kernel sends a SIGBUS to the application. For recoverable errors, the guest performs recovery actions and logs the error. Signed-off-by: Aravinda Prasad <arawinda.p@gmail.com> [Assume SLOF has allocated enough room for rtas error log] Signed-off-by: Ganesh Goudar <ganeshgr@linux.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20200130184423.20519-5-ganeshgr@linux.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-02-03target/ppc: Handle NMI guest exitAravinda Prasad2-0/+45
Memory error such as bit flips that cannot be corrected by hardware are passed on to the kernel for handling. If the memory address in error belongs to guest then the guest kernel is responsible for taking suitable action. Patch [1] enhances KVM to exit guest with exit reason set to KVM_EXIT_NMI in such cases. This patch handles KVM_EXIT_NMI exit. [1] https://www.spinics.net/lists/kvm-ppc/msg12637.html (e20bbd3d and related commits) Signed-off-by: Aravinda Prasad <arawinda.p@gmail.com> Signed-off-by: Ganesh Goudar <ganeshgr@linux.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Message-Id: <20200130184423.20519-4-ganeshgr@linux.ibm.com> [dwg: #ifdefs to fix compile for 32-bit target] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-02-03ppc: spapr: Introduce FWNMI capabilityAravinda Prasad2-0/+20
Introduce fwnmi an spapr capability and add a helper function which tries to enable it, which would be used by following patch of the series. This patch by itself does not change the existing behavior. Signed-off-by: Aravinda Prasad <arawinda.p@gmail.com> [eliminate cap_ppc_fwnmi, add fwnmi cap to migration state and reprhase the commit message] Signed-off-by: Ganesh Goudar <ganeshgr@linux.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20200130184423.20519-3-ganeshgr@linux.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-02-03spapr: Enable DD2.3 accelerated count cache flush in pseries-5.0 machineDavid Gibson2-5/+21
For POWER9 DD2.2 cpus, the best current Spectre v2 indirect branch mitigation is "count cache disabled", which is configured with: -machine cap-ibs=fixed-ccd However, this option isn't available on DD2.3 CPUs with KVM, because they don't have the count cache disabled. For POWER9 DD2.3 cpus, it is "count cache flush with assist", configured with: -machine cap-ibs=workaround,cap-ccf-assist=on However this option isn't available on DD2.2 CPUs with KVM, because they don't have the special CCF assist instruction this relies on. On current machine types, we default to "count cache flush w/o assist", that is: -machine cap-ibs=workaround,cap-ccf-assist=off This runs, with mitigation on both DD2.2 and DD2.3 host cpus, but has a fairly significant performance impact. It turns out we can do better. The special instruction that CCF assist uses to trigger a count cache flush is a no-op on earlier CPUs, rather than trapping or causing other badness. It doesn't, of itself, implement the mitigation, but *if* we have count-cache-disabled, then the count cache flush is unnecessary, and so using the count cache flush mitigation is harmless. Therefore for the new pseries-5.0 machine type, enable cap-ccf-assist by default. Along with that, suppress throwing an error if cap-ccf-assist is selected but KVM doesn't support it, as long as KVM *is* giving us count-cache-disabled. To allow TCG to work out of the box, even though it doesn't implement the ccf flush assist, downgrade the error in that case to a warning. This matches several Spectre mitigations where we allow TCG to operate for debugging, since we don't really make guarantees about TCG security properties anyway. While we're there, make the TCG warning for this case match that for other mitigations. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Tested-by: Michael Ellerman <mpe@ellerman.id.au>
2020-02-02ppc/pnv: change the PowerNV machine devices to be non user creatableCédric Le Goater8-1/+12
The PowerNV machine emulates an OpenPOWER system and the PowerNV chip devices are models of the internal logic of the POWER processor. They can not be instantiated by the user on the QEMU command line. The PHB3/PHB4 devices could be an exception in the future after some rework on how the device tree is built. For the moment, exclude them also. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20200129113720.7404-1-clg@kaod.org> Tested-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-02-02ppc/pnv: Add models for POWER8 PHB3 PCIe Host bridgeCédric Le Goater6-3/+1982
This is a model of the PCIe Host Bridge (PHB3) found on a POWER8 processor. It includes the PowerBus logic interface (PBCQ), IOMMU support, a single PCIe Gen.3 Root Complex, and support for MSI and LSI interrupt sources as found on a POWER8 system using the XICS interrupt controller. The POWER8 processor comes in different flavors: Venice, Murano, Naple, each having a different number of PHBs. To make things simpler, the models provides 3 PHB3 per chip. Some platforms, like the Firestone, can also couple PHBs on the first chip to provide more bandwidth but this is too specific to model in QEMU. XICS requires some adjustment to support the PHB3 MSI. The changes are provided here but they could be decoupled in prereq patches. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20200127144506.11132-3-clg@kaod.org> [dwg: Use device_class_set_props()] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-02-02ppc/pnv: Add models for POWER9 PHB4 PCIe Host bridgeBenjamin Herrenschmidt5-0/+2141
These changes introduces models for the PCIe Host Bridge (PHB4) of the POWER9 processor. It includes the PowerBus logic interface (PBCQ), IOMMU support, a single PCIe Gen.4 Root Complex, and support for MSI and LSI interrupt sources as found on a POWER9 system using the XIVE interrupt controller. POWER9 processor comes with 3 PHB4 PEC (PCI Express Controller) and each PEC can have several PHBs. By default, * PEC0 provides 1 PHB (PHB0) * PEC1 provides 2 PHBs (PHB1 and PHB2) * PEC2 provides 3 PHBs (PHB3, PHB4 and PHB5) Each PEC has a set "global" registers and some "per-stack" (per-PHB) registers. Those are organized in two XSCOM ranges, the "Nest" range and the "PCI" range, each range contains both some "PEC" registers and some "per-stack" registers. No default device layout is provided and PCI devices can be added on any of the available PCIe Root Port (pcie.0 .. 2 of a Power9 chip) with address 0x0 as the firwware (skiboot) only accepts a single device per root port. To run a simple system with a network and a storage adapters, use a command line options such as : -device e1000e,netdev=net0,mac=C0:FF:EE:00:00:02,bus=pcie.0,addr=0x0 -netdev bridge,id=net0,helper=/usr/libexec/qemu-bridge-helper,br=virbr0,id=hostnet0 -device megasas,id=scsi0,bus=pcie.1,addr=0x0 -drive file=$disk,if=none,id=drive-scsi0-0-0-0,format=qcow2,cache=none -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=2 If more are needed, include a bridge. Multi chip is supported, each chip adding its set of PHB4 controllers and its PCI busses. The model doesn't emulate the EEH error handling. This model is not ready for hotplug yet. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> [ clg: - numerous cleanups - commit log - fix for broken LSI support - PHB pic printinfo - large QOM rework ] Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20200127144506.11132-2-clg@kaod.org> [dwg: Use device_class_set_props()] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-02-02hw/ppc/Kconfig: Enable TPM_SPAPR as part of PSERIES configStefan Berger1-1/+1
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20200121152935.649898-6-stefanb@linux.ibm.com> [dwg: Use default in Kconfig rather than select to avoid breaking Windows host build] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-02-02tpm_spapr: Support suspend and resumeStefan Berger2-1/+53
Extend the tpm_spapr frontend with VM suspend and resume support. Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com> Message-Id: <20200121152935.649898-5-stefanb@linux.ibm.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-02-02tpm_spapr: Support TPM for ppc64 using CRQ based interfaceStefan Berger4-0/+398
Implement support for TPM on ppc64 by implementing the vTPM CRQ interface as a frontend. It can use the tpm_emulator driver backend with the external swtpm. The Linux vTPM driver for ppc64 works with this emulation. This TPM emulator also handles the TPM 2 case. Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20200121152935.649898-4-stefanb@linux.ibm.com> [dwg: Use device_class_set_props(), tweak Kconfig] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-02-02spapr: Implement get_dt_compatible() callbackStefan Berger1-2/+9
For devices that cannot be statically initialized, implement a get_dt_compatible() callback that allows us to ask the device for the 'compatible' value. Signed-off-by: Stefan Berger <stefanb@linux.ibm.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20200121152935.649898-3-stefanb@linux.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-02-02tpm: Move tpm_tis_show_buffer to tpm_util.cStefan Berger4-29/+33
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20200121152935.649898-2-stefanb@linux.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-02-02ppc/pnv: Add support for "hostboot" modeCédric Le Goater3-2/+34
When the "hb-mode" option is activated on the powernv machine, the firmware is mapped at 0x8000000 and the HRMOR of the HW threads are set to the same address. The PNOR mapping on the FW address space of the LPC bus is left enabled to let the firmware load any other images required to boot the host. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20200127144154.10170-4-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-02-02ppc/pnv: remove useless "core-pir" property alias.Cédric Le Goater1-15/+13
Commit 158e17a65e1a ("ppc/pnv: Link "chip" property to PnvCore::chip pointer") introduced some cleanups of the PnvCore realize handler. Let's continue by reworking a bit the interface of the PnvCore handlers for the CPU threads. These changes make the "core-pir" property alias unused. Remove it. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20200127144154.10170-3-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-02-02spapr: Don't allow multiple active vCPUs at CASGreg Kurz1-0/+12
According to the description of "ibm,client-architecture-support" that can found in LoPAPR "B.6.2.3 Root Node Methods": If multiple partition processors or threads are active at the time of the ibm,client-architecture-support method call, or an error is detected in the format of the ibm,architecture.vec structure, the err? boolean shall be TRUE; else FALSE. We certainly don't want to temper with the platform or with the PCR of the other vCPUs if they happen to be active. Ensure we have only one active vCPU and fail CAS otherwise. This is just for conformance and robustness, it doesn't fix any known bugs. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <157969867170.571404.12117797348882189656.stgit@bahia.lan> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-02-02spapr: Fail CAS if option vector table cannot be parsedGreg Kurz1-0/+8
Most of the option vector helpers have assertions to check their arguments aren't null. The guest can provide an arbitrary address for the CAS structure that would result in such null arguments. Fail CAS with H_PARAMETER and print a warning instead of aborting QEMU. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <157925255250.397143.10855183619366882459.stgit@bahia.lan> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
generated by cgit v1.1 at 2025-01-01 03:09:59 +0000