aboutsummaryrefslogtreecommitdiff
path: root/include/hw
AgeCommit message (Collapse)Author
2021-02-17Merge remote-tracking branch 'remotes/bonzini-gitlab/tags/for-upstream' into ↵Peter Maydell
staging * HVF fixes * Extra qos-test debugging output (Christian) * SEV secret address autodetection (James) * SEV-ES support (Thomas) * Relocatable paths bugfix (Stefan) * RR fix (Pavel) * EventNotifier fix (Greg) # gpg: Signature made Tue 16 Feb 2021 16:15:59 GMT # gpg: using RSA key F13338574B662389866C7682BFFBD25F78C7AE83 # gpg: issuer "pbonzini@redhat.com" # gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>" [full] # gpg: aka "Paolo Bonzini <pbonzini@redhat.com>" [full] # Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4 E2F7 7E15 100C CD36 69B1 # Subkey fingerprint: F133 3857 4B66 2389 866C 7682 BFFB D25F 78C7 AE83 * remotes/bonzini-gitlab/tags/for-upstream: (21 commits) replay: fix icount request when replaying clock access event_notifier: Set ->initialized earlier in event_notifier_init() hvf: Fetch cr4 before evaluating CPUID(1) target/i386/hvf: add rdmsr 35H MSR_CORE_THREAD_COUNT hvf: x86: Remove unused definitions target/i386/hvf: add vmware-cpuid-freq cpu feature hvf: Guard xgetbv call util/cutils: Skip "." when looking for next directory component tests/qtest/qos-test: dump QEMU command if verbose tests/qtest/qos-test: dump environment variables if verbose tests/qtest/qos-test: dump qos graph if verbose libqos/qgraph_internal: add qos_printf() and qos_printf_literal() libqos/qgraph: add qos_node_create_driver_named() sev/i386: Enable an SEV-ES guest based on SEV policy kvm/i386: Use a per-VM check for SMM capability sev/i386: Don't allow a system reset under an SEV-ES guest sev/i386: Allow AP booting under SEV-ES sev/i386: Require in-kernel irqchip support for SEV-ES guests sev/i386: Add initial support for SEV-ES sev: update sev-inject-launch-secret to make gpa optional ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-02-16pc: add parser for OVMF reset blockJames Bottomley
OVMF is developing a mechanism for depositing a GUIDed table just below the known location of the reset vector. The table goes backwards in memory so all entries are of the form <data>|len|<GUID> Where <data> is arbtrary size and type, <len> is a uint16_t and describes the entire length of the entry from the beginning of the data to the end of the guid. The foot of the table is of this form and <len> for this case describes the entire size of the table. The table foot GUID is defined by OVMF as 96b582de-1fb2-45f7-baea-a366c55a082d and if the table is present this GUID is just below the reset vector, 48 bytes before the end of the firmware file. Add a parser for the ovmf reset block which takes a copy of the block, if the table foot guid is found, minus the footer and a function for later traversal to return the data area of any specified GUIDs. Signed-off-by: James Bottomley <jejb@linux.ibm.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20210204193939.16617-2-jejb@linux.ibm.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-02-16hw/i2c: Implement NPCM7XX SMBus Module FIFO ModeHao Wu
This patch implements the FIFO mode of the SMBus module. In FIFO, the user transmits or receives at most 16 bytes at a time. The FIFO mode allows the module to transmit large amount of data faster than single byte mode. Since we only added the device in a patch that is only a few commits away in the same patch set. We do not increase the VMstate version number in this special case. Reviewed-by: Doug Evans<dje@google.com> Reviewed-by: Tyrong Ting<kfting@nuvoton.com> Signed-off-by: Hao Wu <wuhaotsh@google.com> Reviewed-by: Corey Minyard <cminyard@mvista.com> Message-id: 20210210220426.3577804-6-wuhaotsh@google.com Acked-by: Corey Minyard <cminyard@mvista.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-02-16hw/i2c: Implement NPCM7XX SMBus Module Single ModeHao Wu
This commit implements the single-byte mode of the SMBus. Each Nuvoton SoC has 16 System Management Bus (SMBus). These buses compliant with SMBus and I2C protocol. This patch implements the single-byte mode of the SMBus. In this mode, the user sends or receives a byte each time. The SMBus device transmits it to the underlying i2c device and sends an interrupt back to the QEMU guest. Reviewed-by: Doug Evans<dje@google.com> Reviewed-by: Tyrong Ting<kfting@nuvoton.com> Signed-off-by: Hao Wu <wuhaotsh@google.com> Reviewed-by: Corey Minyard <cminyard@mvista.com> Message-id: 20210210220426.3577804-2-wuhaotsh@google.com Acked-by: Corey Minyard <cminyard@mvista.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-02-11arm: Update infocenter.arm.com URLsPeter Maydell
Update infocenter.arm.com URLs for various pieces of Arm documentation to the new developer.arm.com equivalents. (There is a redirection in place from the old URLs, but we might as well update our comments in case the redirect ever disappears in future.) This patch covers all the URLs which are not MPS2/SSE-200/IoTKit related (those are dealt with in a different patch). Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20210205171456.19939-1-peter.maydell@linaro.org
2021-02-10Merge remote-tracking branch ↵Peter Maydell
'remotes/stefanha-gitlab/tags/block-pull-request' into staging Pull request v4: * Add PCI_EXPRESS Kconfig dependency to fix s390x in "multi-process: setup PCI host bridge for remote device" [Philippe and Thomas] # gpg: Signature made Wed 10 Feb 2021 09:26:14 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: (27 commits) docs: fix Parallels Image "dirty bitmap" section multi-process: perform device reset in the remote process multi-process: Retrieve PCI info from remote process multi-process: create IOHUB object to handle irq multi-process: Synchronize remote memory multi-process: PCI BAR read/write handling for proxy & remote endpoints multi-process: Forward PCI config space acceses to the remote process multi-process: add proxy communication functions multi-process: introduce proxy object multi-process: setup memory manager for remote device multi-process: Associate fd of a PCIDevice with its object multi-process: Initialize message handler in remote device multi-process: define MPQemuMsg format and transmission functions io: add qio_channel_readv_full_all_eof & qio_channel_readv_full_all helpers io: add qio_channel_writev_full_all helper multi-process: setup a machine object for remote device process multi-process: setup PCI host bridge for remote device multi-process: Add config option for multi-process QEMU memory: alloc RAM from file at offset multi-process: add configure and usage information ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-02-10multi-process: perform device reset in the remote processElena Ufimtseva
Perform device reset in the remote process when QEMU performs device reset. This is required to reset the internal state (like registers, etc...) of emulated devices Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com> Signed-off-by: John G Johnson <john.g.johnson@oracle.com> Signed-off-by: Jagannathan Raman <jag.raman@oracle.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-id: 7cb220a51f565dc0817bd76e2f540e89c2d2b850.1611938319.git.jag.raman@oracle.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2021-02-10multi-process: create IOHUB object to handle irqJagannathan Raman
IOHUB object is added to manage PCI IRQs. It uses KVM_IRQFD ioctl to create irqfd to injecting PCI interrupts to the guest. IOHUB object forwards the irqfd to the remote process. Remote process uses this fd to directly send interrupts to the guest, bypassing QEMU. Signed-off-by: John G Johnson <john.g.johnson@oracle.com> Signed-off-by: Jagannathan Raman <jag.raman@oracle.com> Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-id: 51d5c3d54e28a68b002e3875c59599c9f5a424a1.1611938319.git.jag.raman@oracle.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2021-02-10multi-process: Synchronize remote memoryJagannathan Raman
Add ProxyMemoryListener object which is used to keep the view of the RAM in sync between QEMU and remote process. A MemoryListener is registered for system-memory AddressSpace. The listener sends SYNC_SYSMEM message to the remote process when memory listener commits the changes to memory, the remote process receives the message and processes it in the handler for SYNC_SYSMEM message. Signed-off-by: Jagannathan Raman <jag.raman@oracle.com> Signed-off-by: John G Johnson <john.g.johnson@oracle.com> Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-id: 04fe4e6a9ca90d4f11ab6f59be7652f5b086a071.1611938319.git.jag.raman@oracle.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2021-02-10multi-process: PCI BAR read/write handling for proxy & remote endpointsJagannathan Raman
Proxy device object implements handler for PCI BAR writes and reads. The handler uses BAR_WRITE/BAR_READ message to communicate to the remote process with the BAR address and value to be written/read. The remote process implements handler for BAR_WRITE/BAR_READ message. Signed-off-by: Jagannathan Raman <jag.raman@oracle.com> Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com> Signed-off-by: John G Johnson <john.g.johnson@oracle.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-id: a8b76714a9688be5552c4c92d089bc9e8a4707ff.1611938319.git.jag.raman@oracle.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2021-02-10multi-process: Forward PCI config space acceses to the remote processElena Ufimtseva
The Proxy Object sends the PCI config space accesses as messages to the remote process over the communication channel Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com> Signed-off-by: Jagannathan Raman <jag.raman@oracle.com> Signed-off-by: John G Johnson <john.g.johnson@oracle.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-id: d3c94f4618813234655356c60e6f0d0362ff42d6.1611938319.git.jag.raman@oracle.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2021-02-10multi-process: add proxy communication functionsElena Ufimtseva
Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com> Signed-off-by: Jagannathan Raman <jag.raman@oracle.com> Signed-off-by: John G Johnson <john.g.johnson@oracle.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-id: d54edb4176361eed86b903e8f27058363b6c83b3.1611938319.git.jag.raman@oracle.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2021-02-10multi-process: introduce proxy objectElena Ufimtseva
Defines a PCI Device proxy object as a child of TYPE_PCI_DEVICE. Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com> Signed-off-by: Jagannathan Raman <jag.raman@oracle.com> Signed-off-by: John G Johnson <john.g.johnson@oracle.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-id: b5186ebfedf8e557044d09a768846c59230ad3a7.1611938319.git.jag.raman@oracle.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2021-02-10multi-process: setup memory manager for remote deviceJagannathan Raman
SyncSysMemMsg message format is defined. It is used to send file descriptors of the RAM regions to remote device. RAM on the remote device is configured with a set of file descriptors. Old RAM regions are deleted and new regions, each with an fd, is added to the RAM. Signed-off-by: Jagannathan Raman <jag.raman@oracle.com> Signed-off-by: John G Johnson <john.g.johnson@oracle.com> Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-id: 7d2d1831d812e85f681e7a8ab99e032cf4704689.1611938319.git.jag.raman@oracle.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2021-02-10multi-process: Initialize message handler in remote deviceJagannathan Raman
Initializes the message handler function in the remote process. It is called whenever there's an event pending on QIOChannel that registers this function. Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com> Signed-off-by: John G Johnson <john.g.johnson@oracle.com> Signed-off-by: Jagannathan Raman <jag.raman@oracle.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-id: 99d38d8b93753a6409ac2340e858858cda59ab1b.1611938319.git.jag.raman@oracle.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2021-02-10multi-process: define MPQemuMsg format and transmission functionsElena Ufimtseva
Defines MPQemuMsg, which is the message that is sent to the remote process. This message is sent over QIOChannel and is used to command the remote process to perform various tasks. Define transmission functions used by proxy and by remote. Signed-off-by: Jagannathan Raman <jag.raman@oracle.com> Signed-off-by: John G Johnson <john.g.johnson@oracle.com> Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-id: 56ca8bcf95195b2b195b08f6b9565b6d7410bce5.1611938319.git.jag.raman@oracle.com [Replace struct iovec send[2] = {0} with {} to make clang happy as suggested by Peter Maydell <peter.maydell@linaro.org>. --Stefan] Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2021-02-10multi-process: setup a machine object for remote device processJagannathan Raman
x-remote-machine object sets up various subsystems of the remote device process. Instantiate PCI host bridge object and initialize RAM, IO & PCI memory regions. Signed-off-by: John G Johnson <john.g.johnson@oracle.com> Signed-off-by: Jagannathan Raman <jag.raman@oracle.com> Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-id: c537f38d17f90453ca610c6b70cf3480274e0ba1.1611938319.git.jag.raman@oracle.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2021-02-10multi-process: setup PCI host bridge for remote deviceJagannathan Raman
PCI host bridge is setup for the remote device process. It is implemented using remote-pcihost object. It is an extension of the PCI host bridge setup by QEMU. Remote-pcihost configures a PCI bus which could be used by the remote PCI device to latch on to. Signed-off-by: Jagannathan Raman <jag.raman@oracle.com> Signed-off-by: John G Johnson <john.g.johnson@oracle.com> Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-id: 0871ba857abb2eafacde07e7fe66a3f12415bfb2.1611938319.git.jag.raman@oracle.com [Added PCI_EXPRESS condition in hw/remote/Kconfig since remote-pcihost needs PCIe. This solves "make check" failure on s390x. Fix suggested by Philippe Mathieu-Daudé <philmd@redhat.com> and Thomas Huth <thuth@redhat.com>. --Stefan] Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2021-02-10spapr_numa.c: create spapr_numa_initial_nvgpu_numa_id() helperDaniel Henrique Barboza
We'll need to check the initial value given to spapr->gpu_numa_id when building the rtas DT, so put it in a helper for easier access and to avoid repetition. Tested-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20210128174213.1349181-3-danielhb413@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-02-10spapr: move spapr_machine_using_legacy_numa() to spapr_numa.cDaniel Henrique Barboza
This function is used only in spapr_numa.c. Tested-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20210128174213.1349181-2-danielhb413@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-02-10ppc/pnv: Introduce a LPC FW memory region attribute to map the PNORCédric Le Goater
This to map the PNOR from the machine init handler directly and finish the cleanup of the LPC model. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20210126171059.307867-8-clg@kaod.org> Reviewed-by: Joel Stanley <joel@jms.id.au> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-02-10ppc/xive: Add firmware bit when dumping the ENDsCédric Le Goater
ENDs allocated by OPAL for the HW thread VPs are tagged as owned by FW. Dump the state in 'info pic'. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20210126171059.307867-3-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-02-10spapr: Adjust firmware path of PCI devicesGreg Kurz
It is currently not possible to perform a strict boot from USB storage: $ qemu-system-ppc64 -accel kvm -nodefaults -nographic -serial stdio \ -boot strict=on \ -device qemu-xhci \ -device usb-storage,drive=disk,bootindex=0 \ -blockdev driver=file,node-name=disk,filename=fedora-ppc64le.qcow2 SLOF ********************************************************************** QEMU Starting Build Date = Jul 17 2020 11:15:24 FW Version = git-e18ddad8516ff2cf Press "s" to enter Open Firmware. Populating /vdevice methods Populating /vdevice/vty@71000000 Populating /vdevice/nvram@71000001 Populating /pci@800000020000000 00 0000 (D) : 1b36 000d serial bus [ usb-xhci ] No NVRAM common partition, re-initializing... Scanning USB XHCI: Initializing USB Storage SCSI: Looking for devices 101000000000000 DISK : "QEMU QEMU HARDDISK 2.5+" Using default console: /vdevice/vty@71000000 Welcome to Open Firmware Copyright (c) 2004, 2017 IBM Corporation All rights reserved. This program and the accompanying materials are made available under the terms of the BSD License available at http://www.opensource.org/licenses/bsd-license.php Trying to load: from: /pci@800000020000000/usb@0/storage@1/disk@101000000000000 ... E3405: No such device E3407: Load failed Type 'boot' and press return to continue booting the system. Type 'reset-all' and press return to reboot the system. Ready! 0 > The device tree handed over by QEMU to SLOF indeed contains: qemu,boot-list = "/pci@800000020000000/usb@0/storage@1/disk@101000000000000 HALT"; but the device node is named usb-xhci@0, not usb@0. This happens because the firmware names of PCI devices returned by get_boot_devices_list() come from pcibus_get_fw_dev_path(), while the sPAPR PHB code uses a different naming scheme for device nodes. This inconsistency has always been there but it was hidden for a long time because SLOF used to rename USB device nodes, until this commit, merged in QEMU 4.2.0 : commit 85164ad4ed9960cac842fa4cc067c6b6699b0994 Author: Alexey Kardashevskiy <aik@ozlabs.ru> Date: Wed Sep 11 16:24:32 2019 +1000 pseries: Update SLOF firmware image This fixes USB host bus adapter name in the device tree to match QEMU's one. Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Fortunately, sPAPR implements the firmware path provider interface. This provides a way to override the default firmware paths. Just factor out the sPAPR PHB naming logic from spapr_dt_pci_device() to a helper, and use it in the sPAPR firmware path provider hook. Fixes: 85164ad4ed99 ("pseries: Update SLOF firmware image") Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <20210122170157.246374-1-groug@kaod.org> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-02-08s390: Recognize confidential-guest-support optionDavid Gibson
At least some s390 cpu models support "Protected Virtualization" (PV), a mechanism to protect guests from eavesdropping by a compromised hypervisor. This is similar in function to other mechanisms like AMD's SEV and POWER's PEF, which are controlled by the "confidential-guest-support" machine option. s390 is a slightly special case, because we already supported PV, simply by using a CPU model with the required feature (S390_FEAT_UNPACK). To integrate this with the option used by other platforms, we implement the following compromise: - When the confidential-guest-support option is set, s390 will recognize it, verify that the CPU can support PV (failing if not) and set virtio default options necessary for encrypted or protected guests, as on other platforms. i.e. if confidential-guest-support is set, we will either create a guest capable of entering PV mode, or fail outright. - If confidential-guest-support is not set, guests might still be able to enter PV mode, if the CPU has the right model. This may be a little surprising, but shouldn't actually be harmful. To start a guest supporting Protected Virtualization using the new option use the command line arguments: -object s390-pv-guest,id=pv0 -machine confidential-guest-support=pv0 Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Tested-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>
2021-02-08spapr: Add PEF based confidential guest supportDavid Gibson
Some upcoming POWER machines have a system called PEF (Protected Execution Facility) which uses a small ultravisor to allow guests to run in a way that they can't be eavesdropped by the hypervisor. The effect is roughly similar to AMD SEV, although the mechanisms are quite different. Most of the work of this is done between the guest, KVM and the ultravisor, with little need for involvement by qemu. However qemu does need to tell KVM to allow secure VMs. Because the availability of secure mode is a guest visible difference which depends on having the right hardware and firmware, we don't enable this by default. In order to run a secure guest you need to create a "pef-guest" object and set the confidential-guest-support property to point to it. Note that this just *allows* secure guests, the architecture of PEF is such that the guest still needs to talk to the ultravisor to enter secure mode. Qemu has no direct way of knowing if the guest is in secure mode, and certainly can't know until well after machine creation time. To start a PEF-capable guest, use the command line options: -object pef-guest,id=pef0 -machine confidential-guest-support=pef0 Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org>
2021-02-08confidential guest support: Rework the "memory-encryption" propertyDavid Gibson
Currently the "memory-encryption" property is only looked at once we get to kvm_init(). Although protection of guest memory from the hypervisor isn't something that could really ever work with TCG, it's not conceptually tied to the KVM accelerator. In addition, the way the string property is resolved to an object is almost identical to how a QOM link property is handled. So, create a new "confidential-guest-support" link property which sets this QOM interface link directly in the machine. For compatibility we keep the "memory-encryption" property, but now implemented in terms of the new property. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Cornelia Huck <cohuck@redhat.com>
2021-02-05accel: introduce AccelCPUClass extending CPUClassClaudio Fontana
add a new optional interface to CPUClass, which allows accelerators to extend the CPUClass with additional accelerator-specific initializations. This will allow to separate the target cpu code that is specific to each accelerator, and register it automatically with object hierarchy lookup depending on accelerator code availability, as part of the accel_init_interfaces() initialization step. Signed-off-by: Claudio Fontana <cfontana@suse.de> Message-Id: <20210204163931.7358-19-cfontana@suse.de> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-05accel: extend AccelState and AccelClass to user-modeClaudio Fontana
Signed-off-by: Claudio Fontana <cfontana@suse.de> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> [claudio: rebased on Richard's splitwx work] Signed-off-by: Claudio Fontana <cfontana@suse.de> Message-Id: <20210204163931.7358-17-cfontana@suse.de> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-05cpu: tcg_ops: move to tcg-cpu-ops.h, keep a pointer in CPUClassClaudio Fontana
we cannot in principle make the TCG Operations field definitions conditional on CONFIG_TCG in code that is included by both common_ss and specific_ss modules. Therefore, what we can do safely to restrict the TCG fields to TCG-only builds, is to move all tcg cpu operations into a separate header file, which is only included by TCG, target-specific code. This leaves just a NULL pointer in the cpu.h for the non-TCG builds. This also tidies up the code in all targets a bit, having all TCG cpu operations neatly contained by a dedicated data struct. Signed-off-by: Claudio Fontana <cfontana@suse.de> Message-Id: <20210204163931.7358-16-cfontana@suse.de> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-05cpu: move debug_check_watchpoint to tcg_opsClaudio Fontana
commit 568496c0c0f1 ("cpu: Add callback to check architectural") and commit 3826121d9298 ("target-arm: Implement checking of fired") introduced an ARM-specific hack for cpu_check_watchpoint. Make debug_check_watchpoint optional, and move it to tcg_ops. Signed-off-by: Claudio Fontana <cfontana@suse.de> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20210204163931.7358-15-cfontana@suse.de> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-05cpu: move adjust_watchpoint_address to tcg_opsClaudio Fontana
commit 40612000599e ("arm: Correctly handle watchpoints for BE32 CPUs") introduced this ARM-specific, TCG-specific hack to adjust the address, before checking it with cpu_check_watchpoint. Make adjust_watchpoint_address optional and move it to tcg_ops. Signed-off-by: Claudio Fontana <cfontana@suse.de> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20210204163931.7358-14-cfontana@suse.de> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-05cpu: move do_unaligned_access to tcg_opsClaudio Fontana
make it consistently SOFTMMU-only. Signed-off-by: Claudio Fontana <cfontana@suse.de> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> [claudio: make the field presence in cpu.h unconditional, removing the ifdefs] Message-Id: <20210204163931.7358-12-cfontana@suse.de> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-05cpu: move cc->transaction_failed to tcg_opsClaudio Fontana
Signed-off-by: Claudio Fontana <cfontana@suse.de> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> [claudio: wrap target code around CONFIG_TCG and !CONFIG_USER_ONLY] avoiding its use in headers used by common_ss code (should be poisoned). Note: need to be careful with the use of CONFIG_USER_ONLY, Message-Id: <20210204163931.7358-11-cfontana@suse.de> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-05cpu: move cc->do_interrupt to tcg_opsClaudio Fontana
Signed-off-by: Claudio Fontana <cfontana@suse.de> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20210204163931.7358-10-cfontana@suse.de> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-05cpu: Move debug_excp_handler to tcg_opsEduardo Habkost
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Claudio Fontana <cfontana@suse.de> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20210204163931.7358-8-cfontana@suse.de> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-05cpu: Move tlb_fill to tcg_opsEduardo Habkost
[claudio: wrapped target code in CONFIG_TCG] Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Claudio Fontana <cfontana@suse.de> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20210204163931.7358-7-cfontana@suse.de> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-05cpu: Move cpu_exec_* to tcg_opsEduardo Habkost
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> [claudio: wrapped target code in CONFIG_TCG] Signed-off-by: Claudio Fontana <cfontana@suse.de> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20210204163931.7358-6-cfontana@suse.de> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-05cpu: Move synchronize_from_tb() to tcg_opsEduardo Habkost
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> [claudio: wrapped target code in CONFIG_TCG, reworded comments] Signed-off-by: Claudio Fontana <cfontana@suse.de> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20210204163931.7358-5-cfontana@suse.de> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-05accel/tcg: split TCG-only code from cpu_exec_realizefnClaudio Fontana
move away TCG-only code, make it compile only on TCG. Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> [claudio: moved the prototypes from hw/core/cpu.h to exec/cpu-all.h] Signed-off-by: Claudio Fontana <cfontana@suse.de> Message-Id: <20210204163931.7358-4-cfontana@suse.de> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-05cpu: Introduce TCGCpuOperations structEduardo Habkost
The TCG-specific CPU methods will be moved to a separate struct, to make it easier to move accel-specific code outside generic CPU code in the future. Start by moving tcg_initialize(). The new CPUClass.tcg_opts field may eventually become a pointer, but keep it an embedded struct for now, to make code conversion easier. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> [claudio: move TCGCpuOperations inside include/hw/core/cpu.h] Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20210204163931.7358-2-cfontana@suse.de> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-05acpi: Permit OEM ID and OEM table ID fields to be changedMarian Postevca
Qemu's ACPI table generation sets the fields OEM ID and OEM table ID to "BOCHS " and "BXPCxxxx" where "xxxx" is replaced by the ACPI table name. Some games like Red Dead Redemption 2 seem to check the ACPI OEM ID and OEM table ID for the strings "BOCHS" and "BXPC" and if they are found, the game crashes(this may be an intentional detection mechanism to prevent playing the game in a virtualized environment). This patch allows you to override these default values. The feature can be used in this manner: qemu -machine oem-id=ABCDEF,oem-table-id=GHIJKLMN The oem-id string can be up to 6 bytes in size, and the oem-table-id string can be up to 8 bytes in size. If the string are smaller than their respective sizes they will be padded with space. If either of these parameters is not set, the current default values will be used for the one missing. Note that the the OEM Table ID field will not be extended with the name of the table, but will use either the default name or the user provided one. This does not affect the -acpitable option (for user-defined ACPI tables), which has precedence over -machine option. Signed-off-by: Marian Postevca <posteuca@mutex.one> Message-Id: <20210119003216.17637-3-posteuca@mutex.one> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-02-05pci: add romsize propertyPaolo Bonzini
This property can be useful for distros to set up known-good ROM sizes for migration purposes. The VM will fail to start if the ROM is too large, and migration compatibility will not be broken if the ROM is too small. Note that even though romsize is a uint32_t, it has to be between 1 (because empty ROM files are not accepted, and romsize must be greater than the file) and 2^31 (because values above are not powers of two and are rejected). Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Message-Id: <20201218182736.1634344-1-pbonzini@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20210203131828.156467-3-pbonzini@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: David Edmondson <david.edmondson@oracle.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
2021-02-04display/ui: add a callback to indicate GL state is flushedMarc-André Lureau
Displaying rendered resources requires blocking qemu GPU to avoid extra framebuffer copies. For an external display, via Spice currently, there is a callback to block/unblock the rendering in the same thread. But with the vhost-user-gpu backend, the qemu process doesn't handle the rendering itself, and the blocking callback isn't effective. Instead, the backend must be notified when the display code is done. Fix this by adding a new GraphicHwOps callback to indicate the GL state is flushed, and we are done manipulating the shared GL resources. Call it from gtk and spice display. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20210204105232.834642-19-marcandre.lureau@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2021-02-04virtio-gpu: avoid re-entering cmdq processingMarc-André Lureau
The next patch will notify the GL context got flush, which will resume the queue processing. However, if this happens within the caller context, it will end up with a stack overflow flush/update loop. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20210204105232.834642-18-marcandre.lureau@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2021-02-04vhost-user-gpu: add a configuration flag for dmabuf usageMarc-André Lureau
Let's inform VirtioGPUBase that vhost-user-gpu require DMABUF messages. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20210204105232.834642-11-marcandre.lureau@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2021-02-02hw/ssi: imx_spi: Use a macro for number of chip selects supportedBin Meng
Avoid using a magic number (4) everywhere for the number of chip selects supported. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Juan Quintela <quintela@redhat.com> Message-id: 20210129132323.30946-2-bmeng.cn@gmail.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-01-29arm: Remove frq properties on CMSDK timer, dualtimer, watchdog, ARMSSEPeter Maydell
Now no users are setting the frq properties on the CMSDK timer, dualtimer, watchdog or ARMSSE SoC devices, we can remove the properties and the struct fields that back them. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Luc Michel <luc@lmichel.fr> Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20210128114145.20536-25-peter.maydell@linaro.org Message-id: 20210121190622.22000-25-peter.maydell@linaro.org
2021-01-29hw/arm/mps2: Inline CMSDK_APB_TIMER creationPeter Maydell
The old-style convenience function cmsdk_apb_timer_create() for creating CMSDK_APB_TIMER objects is used in only two places in mps2.c. Most of the rest of the code in that file uses the new "initialize in place" coding style. We want to connect up a Clock object which should be done between the object creation and realization; rather than adding a Clock* argument to the convenience function, convert the timer creation code in mps2.c to the same style as is used already for the watchdog, dualtimer and other devices, and delete the now-unused convenience function. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Luc Michel <luc@lmichel.fr> Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20210128114145.20536-13-peter.maydell@linaro.org Message-id: 20210121190622.22000-13-peter.maydell@linaro.org
2021-01-29hw/arm/armsse: Wire up clocksPeter Maydell
Create two input clocks on the ARMSSE devices, one for the normal MAINCLK, and one for the 32KHz S32KCLK, and wire these up to the appropriate devices. The old property-based clock frequency setting will remain in place until conversion is complete. This is a migration compatibility break for machines mps2-an505, mps2-an521, musca-a, musca-b1. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Luc Michel <luc@lmichel.fr> Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20210128114145.20536-12-peter.maydell@linaro.org Message-id: 20210121190622.22000-12-peter.maydell@linaro.org
2021-01-29hw/arm/armsse: Rename "MAINCLK" property to "MAINCLK_FRQ"Peter Maydell
While we transition the ARMSSE code from integer properties specifying clock frequencies to Clock objects, we want to have the device provide both at once. We want the final name of the main input Clock to be "MAINCLK", following the hardware name. Unfortunately creating an input Clock with a name X creates an under-the-hood QOM property X; for "MAINCLK" this clashes with the existing UINT32 property of that name. Rename the UINT32 property to MAINCLK_FRQ so it can coexist with the MAINCLK Clock; once the transition is complete MAINCLK_FRQ will be deleted. Commit created with: perl -p -i -e 's/MAINCLK/MAINCLK_FRQ/g' hw/arm/{armsse,mps2-tz,musca}.c include/hw/arm/armsse.h Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Luc Michel <luc@lmichel.fr> Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20210128114145.20536-11-peter.maydell@linaro.org Message-id: 20210121190622.22000-11-peter.maydell@linaro.org
generated by cgit v1.2.3 (git 2.26.2) at 2025-03-15 23:31:17 +0000