summaryrefslogtreecommitdiffstats
path: root/include
Commit message (Collapse)AuthorAgeFilesLines
* hw/block/nvme: bump to v1.4Klaus Jensen2021-02-081-1/+2
| | | | | | | | | | | With the new CMB logic in place, bump the implemented specification version to v1.4 by default. This requires adding the setting the CNTRLTYPE field and modifying the VWC field since 0x00 is no longer a valid value for bits 2:1. Reviewed-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
* hw/block/nvme: move cmb logic to v1.4Padmakar Kalghatgi2021-02-081-12/+97
| | | | | | | | | | | | | | | Implement v1.4 logic for configuring the Controller Memory Buffer. By default, the v1.4 scheme will be used (CMB must be explicitly enabled by the host), so drivers that only support v1.3 will not be able to use the CMB anymore. To retain the v1.3 behavior, set the boolean 'legacy-cmb' nvme device parameter. Reviewed-by: Keith Busch <kbusch@kernel.org> Reviewed-by: Minwoo Im <minwoo.im.dev@gmail.com> Signed-off-by: Padmakar Kalghatgi <p.kalghatgi@samsung.com> Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
* hw/block/nvme: rename PMR/CMB shift/mask fieldsKlaus Jensen2021-02-081-9/+9
| | | | | | | | Use the correct field names. Reviewed-by: Minwoo Im <minwoo.im.dev@gmail.com> Reviewed-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
* hw/block/nvme: indicate CMB support through controller capabilities registerAndrzej Jakowski2021-02-081-3/+7
| | | | | | | | | | | | This patch sets CMBS bit in controller capabilities register when user configures NVMe driver with CMB support, so capabilites are correctly reported to guest OS. Signed-off-by: Andrzej Jakowski <andrzej.jakowski@linux.intel.com> Reviewed-by: Maxim Levitsky <mlevitsky@gmail.com> Reviewed-by: Minwoo Im <minwoo.im.dev@gmail.com> Reviewed-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
* hw/block/nvme: trigger async event during injecting smart warningzhenwei pi2021-02-081-0/+1
| | | | | | | | | | | | During smart critical warning injection by setting property from QMP command, also try to trigger asynchronous event. Suggested by Keith, if a event has already been raised, there is no need to enqueue the duplicate event any more. Signed-off-by: zhenwei pi <pizhenwei@bytedance.com> [k.jensen: fix typo in commit message] Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
* hw/block/nvme: add smart_critical_warning propertyzhenwei pi2021-02-081-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is a very low probability that hitting physical NVMe disk hardware critical warning case, it's hard to write & test a monitor agent service. For debugging purposes, add a new 'smart_critical_warning' property to emulate this situation. The orignal version of this change is implemented by adding a fixed property which could be initialized by QEMU command line. Suggested by Philippe & Klaus, rework like current version. Test with this patch: 1, change smart_critical_warning property for a running VM: #virsh qemu-monitor-command nvme-upstream '{ "execute": "qom-set", "arguments": { "path": "/machine/peripheral-anon/device[0]", "property": "smart_critical_warning", "value":16 } }' 2, run smartctl in guest #smartctl -H -l error /dev/nvme0n1 === START OF SMART DATA SECTION === SMART overall-health self-assessment test result: FAILED! - volatile memory backup device has failed Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: zhenwei pi <pizhenwei@bytedance.com> Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
* nvme: introduce bit 5 for critical warningzhenwei pi2021-02-081-0/+1
| | | | | | | | | | According to NVM Express v1.4, Section 5.14.1.2 ("SMART / Health Information"), introduce bit 5 for "Persistent Memory Region has become read-only or unreliable". Signed-off-by: zhenwei pi <pizhenwei@bytedance.com> [k.jensen: minor brush ups in commit message] Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
* hw/block/nvme: enum style fixKlaus Jensen2021-02-081-2/+2
| | | | | | | | Align with existing style and use a typedef for header-file enums. Signed-off-by: Klaus Jensen <k.jensen@samsung.com> Tested-by: Dmitry Fomichev <dmitry.fomichev@wdc.com> Reviewed-by: Dmitry Fomichev <dmitry.fomichev@wdc.com>
* nvme: Make ZNS-related definitionsDmitry Fomichev2021-02-081-1/+113
| | | | | | | | | | Define values and structures that are needed to support Zoned Namespace Command Set (NVMe TP 4053). Signed-off-by: Dmitry Fomichev <dmitry.fomichev@wdc.com> Acked-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
* hw/block/nvme: Support allocated CNS command variantsNiklas Cassel2021-02-081-8/+12
| | | | | | | | | | | | | | | | | | | | | | | Many CNS commands have "allocated" command variants. These include a namespace as long as it is allocated, that is a namespace is included regardless if it is active (attached) or not. While these commands are optional (they are mandatory for controllers supporting the namespace attachment command), our QEMU implementation is more complete by actually providing support for these CNS values. However, since our QEMU model currently does not support the namespace attachment command, these new allocated CNS commands will return the same result as the active CNS command variants. The reason for not hooking up this command completely is because the NVMe specification requires the namespace management command to be supported if the namespace attachment command is supported. Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com> Signed-off-by: Dmitry Fomichev <dmitry.fomichev@wdc.com> Reviewed-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
* hw/block/nvme: Add support for Namespace TypesNiklas Cassel2021-02-081-14/+50
| | | | | | | | | | | | | | | | | | | | | | | Define the structures and constants required to implement Namespace Types support. Namespace Types introduce a new command set, "I/O Command Sets", that allows the host to retrieve the command sets associated with a namespace. Introduce support for the command set and enable detection for the NVM Command Set. The new workflows for identify commands rely heavily on zero-filled identify structs. E.g., certain CNS commands are defined to return a zero-filled identify struct when an inactive namespace NSID is supplied. Add a helper function in order to avoid code duplication when reporting zero-filled identify structures. Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com> Signed-off-by: Dmitry Fomichev <dmitry.fomichev@wdc.com> Reviewed-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
* hw/block/nvme: Add Commands Supported and Effects logDmitry Fomichev2021-02-081-0/+19
| | | | | | | | | | | | | | | | | | | This log page becomes necessary to implement to allow checking for Zone Append command support in Zoned Namespace Command Set. This commit adds the code to report this log page for NVM Command Set only. The parts that are specific to zoned operation will be added later in the series. All incoming admin and i/o commands are now only processed if their corresponding support bits are set in this log. This provides an easy way to control what commands to support and what not to depending on set CC.CSS. Signed-off-by: Dmitry Fomichev <dmitry.fomichev@wdc.com> Reviewed-by: Niklas Cassel <Niklas.Cassel@wdc.com> Reviewed-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
* nvme: add namespace I/O optimization fields to shared headerKlaus Jensen2021-02-081-1/+6
| | | | | | | | | | | This adds the NPWG, NPWA, NPDG, NPDA and NOWS family of fields to the shared nvme.h header for use by later patches. Signed-off-by: Klaus Jensen <k.jensen@samsung.com> Cc: Stefan Hajnoczi <stefanha@redhat.com> Cc: Fam Zheng <fam@euphon.net> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Minwoo Im <minwoo.im.dev@gmail.com>
* hw/block/nvme: add dulbe supportKlaus Jensen2021-02-081-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for reporting the Deallocated or Unwritten Logical Block Error (DULBE). Rely on the block status flags reported by the block layer and consider any block with the BDRV_BLOCK_ZERO flag to be deallocated. Multiple factors affect when a Write Zeroes command result in deallocation of blocks. * the underlying file system block size * the blockdev format * the 'discard' and 'logical_block_size' parameters format | discard | wz (512B) wz (4KiB) wz (64KiB) ----------------------------------------------------- qcow2 ignore n n y qcow2 unmap n n y raw ignore n y y raw unmap n y y So, this works best with an image in raw format and 4KiB LBAs, since holes can then be punched on a per-block basis (this assumes a file system with a 4kb block size, YMMV). A qcow2 image, uses a cluster size of 64KiB by default and blocks will only be marked deallocated if a full cluster is zeroed or discarded. However, this *is* consistent with the spec since Write Zeroes "should" deallocate the block if the Deallocate attribute is set and "may" deallocate if the Deallocate attribute is not set. Thus, we always try to deallocate (the BDRV_REQ_MAY_UNMAP flag is always set). Signed-off-by: Klaus Jensen <k.jensen@samsung.com> Reviewed-by: Keith Busch <kbusch@kernel.org>
* Merge remote-tracking branch 'remotes/dg-gitlab/tags/cgs-pull-request' into ↵Peter Maydell2021-02-088-20/+102
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | staging Generalize memory encryption models A number of hardware platforms are implementing mechanisms whereby the hypervisor does not have unfettered access to guest memory, in order to mitigate the security impact of a compromised hypervisor. AMD's SEV implements this with in-cpu memory encryption, and Intel has its own memory encryption mechanism. POWER has an upcoming mechanism to accomplish this in a different way, using a new memory protection level plus a small trusted ultravisor. s390 also has a protected execution environment. The current code (committed or draft) for these features has each platform's version configured entirely differently. That doesn't seem ideal for users, or particularly for management layers. AMD SEV introduces a notionally generic machine option "machine-encryption", but it doesn't actually cover any cases other than SEV. This series is a proposal to at least partially unify configuration for these mechanisms, by renaming and generalizing AMD's "memory-encryption" property. It is replaced by a "confidential-guest-support" property pointing to a platform specific object which configures and manages the specific details. Note to Ram Pai: the documentation I've included for PEF is very minimal. If you could send a patch expanding on that, it would be very helpful. Changes since v8: * Rebase * Fixed some cosmetic typos Changes since v7: * Tweaked and clarified meaning of the 'ready' flag * Polished the interface to the PEF internals * Shifted initialization for s390 PV later (I hope I've finally got this after apply_cpu_model() where it needs to be) Changes since v6: * Moved to using OBJECT_DECLARE_TYPE and OBJECT_DEFINE_TYPE macros * Assorted minor fixes Changes since v5: * Renamed from "securable guest memory" to "confidential guest support" * Simpler reworking of x86 boot time flash encryption * Added a bunch of documentation * Fixed some compile errors on POWER Changes since v4: * Renamed from "host trust limitation" to "securable guest memory", which I think is marginally more descriptive * Re-organized initialization, because the previous model called at kvm_init didn't work for s390 * Assorted fixes to the s390 implementation; rudimentary testing (gitlab CI) only Changes since v3: * Rebased * Added first cut at handling of s390 protected virtualization Changes since RFCv2: * Rebased * Removed preliminary SEV cleanups (they've been merged) * Changed name to "host trust limitation" * Added migration blocker to the PEF code (based on SEV's version) Changes since RFCv1: * Rebased * Fixed some errors pointed out by Dave Gilbert # gpg: Signature made Mon 08 Feb 2021 06:07:27 GMT # gpg: using RSA key 75F46586AE61A66CC44E87DC6C38CACA20D9B392 # gpg: Good signature from "David Gibson <david@gibson.dropbear.id.au>" [full] # gpg: aka "David Gibson (Red Hat) <dgibson@redhat.com>" [full] # gpg: aka "David Gibson (ozlabs.org) <dgibson@ozlabs.org>" [full] # gpg: aka "David Gibson (kernel.org) <dwg@kernel.org>" [unknown] # Primary key fingerprint: 75F4 6586 AE61 A66C C44E 87DC 6C38 CACA 20D9 B392 * remotes/dg-gitlab/tags/cgs-pull-request: s390: Recognize confidential-guest-support option confidential guest support: Alter virtio default properties for protected guests spapr: PEF: prevent migration spapr: Add PEF based confidential guest support confidential guest support: Update documentation confidential guest support: Move SEV initialization into arch specific code confidential guest support: Introduce cgs "ready" flag sev: Add Error ** to sev_kvm_init() confidential guest support: Rework the "memory-encryption" property confidential guest support: Move side effect out of machine_set_memory_encryption() sev: Remove false abstraction of flash encryption confidential guest support: Introduce new confidential guest support class qom: Allow optional sugar props Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
| * s390: Recognize confidential-guest-support optionDavid Gibson2021-02-081-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * spapr: Add PEF based confidential guest supportDavid Gibson2021-02-081-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * confidential guest support: Introduce cgs "ready" flagDavid Gibson2021-02-081-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The platform specific details of mechanisms for implementing confidential guest support may require setup at various points during initialization. Thus, it's not really feasible to have a single cgs initialization hook, but instead each mechanism needs its own initialization calls in arch or machine specific code. However, to make it harder to have a bug where a mechanism isn't properly initialized under some circumstances, we want to have a common place, late in boot, where we verify that cgs has been initialized if it was requested. This patch introduces a ready flag to the ConfidentialGuestSupport base type to accomplish this, which we verify in qemu_machine_creation_done(). Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org>
| * sev: Add Error ** to sev_kvm_init()David Gibson2021-02-081-1/+1
| | | | | | | | | | | | | | | | | | This allows failures to be reported richly and idiomatically. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Cornelia Huck <cohuck@redhat.com>
| * confidential guest support: Rework the "memory-encryption" propertyDavid Gibson2021-02-082-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * sev: Remove false abstraction of flash encryptionDavid Gibson2021-02-082-18/+2Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When AMD's SEV memory encryption is in use, flash memory banks (which are initialed by pc_system_flash_map()) need to be encrypted with the guest's key, so that the guest can read them. That's abstracted via the kvm_memcrypt_encrypt_data() callback in the KVM state.. except, that it doesn't really abstract much at all. For starters, the only call site is in code specific to the 'pc' family of machine types, so it's obviously specific to those and to x86 to begin with. But it makes a bunch of further assumptions that need not be true about an arbitrary confidential guest system based on memory encryption, let alone one based on other mechanisms: * it assumes that the flash memory is defined to be encrypted with the guest key, rather than being shared with hypervisor * it assumes that that hypervisor has some mechanism to encrypt data into the guest, even though it can't decrypt it out, since that's the whole point * the interface assumes that this encrypt can be done in place, which implies that the hypervisor can write into a confidential guests's memory, even if what it writes isn't meaningful So really, this "abstraction" is actually pretty specific to the way SEV works. So, this patch removes it and instead has the PC flash initialization code call into a SEV specific callback. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cornelia Huck <cohuck@redhat.com>
| * confidential guest support: Introduce new confidential guest support classDavid Gibson2021-02-082-0/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Several architectures have mechanisms which are designed to protect guest memory from interference or eavesdropping by a compromised hypervisor. AMD SEV does this with in-chip memory encryption and Intel's TDX can do similar things. POWER's Protected Execution Framework (PEF) accomplishes a similar goal using an ultravisor and new memory protection features, instead of encryption. To (partially) unify handling for these, this introduces a new ConfidentialGuestSupport QOM base class. "Confidential" is kind of vague, but "confidential computing" seems to be the buzzword about these schemes, and "secure" or "protected" are often used in connection to unrelated things (such as hypervisor-from-guest or guest-from-guest security). The "support" in the name is significant because in at least some of the cases it requires the guest to take specific actions in order to protect itself from hypervisor eavesdropping. Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
| * qom: Allow optional sugar propsGreg Kurz2021-02-081-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Global properties have an @optional field, which allows to apply a given property to a given type even if one of its subclasses doesn't support it. This is especially used in the compat code when dealing with the "disable-modern" and "disable-legacy" properties and the "virtio-pci" type. Allow object_register_sugar_prop() to set this field as well. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <159738953558.377274.16617742952571083440.stgit@bahia.lan> Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
* | utils/fifo8: add VMSTATE_FIFO8_TEST macroMark Cave-Ayland2021-02-071-6/+10
|/ | | | | | | | | Rewrite the existing VMSTATE_FIFO8 macro to use VMSTATE_FIFO8_TEST as per the standard pattern in include/migration/vmstate.h. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20210128221728.14887-3-mark.cave-ayland@ilande.co.uk>
* accel: introduce AccelCPUClass extending CPUClassClaudio Fontana2021-02-052-0/+42
| | | | | | | | | | | | | | | 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>
* accel: replace struct CpusAccel with AccelOpsClassClaudio Fontana2021-02-053-21/+52
| | | | | | | | | | | | | | | This will allow us to centralize the registration of the cpus.c module accelerator operations (in accel/accel-softmmu.c), and trigger it automatically using object hierarchy lookup from the new accel_init_interfaces() initialization step, depending just on which accelerators are available in the code. Rename all tcg-cpus.c, kvm-cpus.c, etc to tcg-accel-ops.c, kvm-accel-ops.c, etc, matching the object type names. Signed-off-by: Claudio Fontana <cfontana@suse.de> Message-Id: <20210204163931.7358-18-cfontana@suse.de> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
* accel: extend AccelState and AccelClass to user-modeClaudio Fontana2021-02-055-10/+12
| | | | | | | | | | | 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>
* cpu: tcg_ops: move to tcg-cpu-ops.h, keep a pointer in CPUClassClaudio Fontana2021-02-052-99/+101
| | | | | | | | | | | | | | | | | | | 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>
* cpu: move debug_check_watchpoint to tcg_opsClaudio Fontana2021-02-051-3/+6
| | | | | | | | | | | | | 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>
* cpu: move adjust_watchpoint_address to tcg_opsClaudio Fontana2021-02-051-1/+5
| | | | | | | | | | | | | | 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>
* cpu: move do_unaligned_access to tcg_opsClaudio Fontana2021-02-051-6/+7
| | | | | | | | | | | | | | 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>
* cpu: move cc->transaction_failed to tcg_opsClaudio Fontana2021-02-051-15/+13Star
| | | | | | | | | | | | | | | 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>
* cpu: move cc->do_interrupt to tcg_opsClaudio Fontana2021-02-051-2/+2
| | | | | | | | 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>
* cpu: Move debug_excp_handler to tcg_opsEduardo Habkost2021-02-051-2/+2
| | | | | | | | | 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>
* cpu: Move tlb_fill to tcg_opsEduardo Habkost2021-02-051-9/+12
| | | | | | | | | | | | [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>
* cpu: Move cpu_exec_* to tcg_opsEduardo Habkost2021-02-051-6/+6
| | | | | | | | | | | 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>
* cpu: Move synchronize_from_tb() to tcg_opsEduardo Habkost2021-02-051-9/+13
| | | | | | | | | 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>
* accel/tcg: split TCG-only code from cpu_exec_realizefnClaudio Fontana2021-02-052-2/+11
| | | | | | | | | | | 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>
* cpu: Introduce TCGCpuOperations structEduardo Habkost2021-02-051-1/+15
| | | | | | | | | | | | | | | | 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>
* tcg/tci: Make tci_tb_ptr thread-localRichard Henderson2021-02-051-1/+1
| | | | | | | | | | | | | Each thread must have its own pc, even under TCI. Remove the GETPC ifdef, because GETPC is always available for helpers, and thus is always required. Move the assignment under INDEX_op_call, because the value is only visible when we make a call to a helper function. Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20210204014509.882821-6-richard.henderson@linaro.org>
* exec/cpu-defs: Remove TCG backends dependencyPhilippe Mathieu-Daudé2021-02-051-3/+0Star
| | | | | | | | | | | | | | | | | | | | | | | "exec/cpu-defs.h" contains generic CPU definitions for the TCG frontends (mostly related to TLB). TCG backends definitions aren't relevant here. See tcg/README description: 4) Backend tcg-target.h contains the target specific definitions. tcg-target.c.inc contains the target specific code; it is #included by tcg/tcg.c, rather than being a standalone C file. So far only "tcg/tcg.h" requires these headers. Remove the "target-tcg.h" header dependency on TCG frontends, so we don't have to rebuild all frontends when hacking a single backend. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210204191423.1754158-1-f4bug@amsat.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
* acpi: Permit OEM ID and OEM table ID fields to be changedMarian Postevca2021-02-059-9/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* pci: add romsize propertyPaolo Bonzini2021-02-051-0/+1
| | | | | | | | | | | | | | | | | | | | | | 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>
* display/ui: add a callback to indicate GL state is flushedMarc-André Lureau2021-02-042-1/+3
| | | | | | | | | | | | | | | | | | 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>
* virtio-gpu: avoid re-entering cmdq processingMarc-André Lureau2021-02-041-0/+1
| | | | | | | | | | 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>
* ui: add egl dmabuf import to gtkglareaMarc-André Lureau2021-02-041-0/+2
| | | | | | | | GtkGLArea is used on wayland, where EGL is usually available. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20210204105232.834642-17-marcandre.lureau@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* ui: check gtk-egl dmabuf supportMarc-André Lureau2021-02-041-0/+1
| | | | | | Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20210204105232.834642-16-marcandre.lureau@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* ui: add qemu_egl_has_dmabuf helperMarc-André Lureau2021-02-041-0/+1
| | | | | | Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20210204105232.834642-15-marcandre.lureau@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* ui: add a DCLOps callback to check dmabuf supportMarc-André Lureau2021-02-041-0/+2
| | | | | | Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20210204105232.834642-13-marcandre.lureau@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* ui: add an optional get_flags callback to GraphicHwOpsMarc-André Lureau2021-02-041-0/+9
| | | | | | | | | Those flags can be used to express different requirements for the display or other needs. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20210204105232.834642-12-marcandre.lureau@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2024-12-22 08:25:52 +0100