summaryrefslogtreecommitdiffstats
path: root/target
Commit message (Collapse)AuthorAgeFilesLines
* Disable AES-NI instructions in CPUID reportHEADmasterLouis Burda2023-02-081-0/+3
|
* i386/sev: Fix segfault retrieving SEV capabilitiesCarlos Bilbao2022-10-281-0/+1
| | | | | | | | | Return from sev_get_capabilities when sev_common is not on. This fixes a segmentation fault when retrieving SEV capabilities, for example with libvirt. Signed-off-by: Alexey Kardashevskiy <Alexey.Kardashevskiy@amd.com> Signed-off-by: Carlos Bilbao <carlos.bilbao@amd.com>
* i386/sev: fill XCR0_IN/XSS_IN according to initial/base XSAVE stateMichael Roth2022-02-091-1/+4
| | | | | | | | | Previously these fields were ignored in WIP SEV-SNP support for linux guests, but the latest versions search for explicitly for XCR0_IN=1/XSS_IN=0 when search the CPUID table for CPUID leaves 0xD/0x0 and 0xD/0x1, so set them accordingly in QEMU. Signed-off-by: Michael Roth <michael.roth@amd.com>
* i386/sev: fix launch measurement crash for SEV-SNPMichael Roth2022-02-091-1/+3
| | | | | | | | | | Launch measurement measurement is not supported for SEV-SNP guests since it is reported later for checking during attestation workflow. For SEV-SNP, QEMU's launch measurement is meant to be a no-op, but currently results in a crash. Fix that. Reported-by: Niteesh Dubey <niteesh@us.ibm.com> Signed-off-by: Michael Roth <michael.roth@amd.com>
* i386:sev: skip hashing the kernel for the SEV-SNP guestBrijesh Singh2021-10-271-0/+5
| | | | Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
* i386/sev: update query-sev QAPI format to handle SEV-SNPMichael Roth2021-10-243-16/+38
| | | | | | | | | | | | | | | | | | | Most of the current 'query-sev' command is relevant to both legacy SEV/SEV-ES guests and SEV-SNP guests, with 2 exceptions: - 'policy' is a 64-bit field for SEV-SNP, not 32-bit, and the meaning of the bit positions has changed - 'handle' is not relevant to SEV-SNP To address this, this patch adds a new 'sev-type' field that can be used as a discriminator to select between SEV and SEV-SNP-specific fields/formats without breaking compatibility for existing management tools (so long as management tools that add support for launching SEV-SNP guest update their handling of query-sev appropriately). The corresponding HMP command has also been fixed up similarly. Signed-off-by: Michael Roth <michael.roth@amd.com>
* i386/sev: sev-snp: add support for CPUID validationMichael Roth2021-10-241-1/+154
| | | | | | | | | | | | | | | SEV-SNP firmware allows a special guest page to be populated with a table of guest CPUID values so that they can be validated through firmware before being loaded into encrypted guest memory where they can be used in place of hypervisor-provided values[1]. As part of SEV-SNP guest initialization, use this process to validate the CPUID entries reported by KVM_GET_CPUID2 prior to initial guest start. [1]: SEV SNP Firmware ABI Specification, Rev. 0.8, 8.13.2.6 Signed-off-by: Michael Roth <michael.roth@amd.com>
* target/i386: add new EPYC CPU versions with updated cache_infoMichael Roth2021-10-241-0/+184
| | | | | | | | | | | This patch introduces new EPYC cpu versions: EPYC-v4, EPYC-Rome-v3, and EPYC-Milan-v2. The only difference vs. older models is an updated cache_info with the 'complex_indexing' bit unset, since this bit is not currently defined for AMD and may cause problems should it be used for something else in the future. Setting this bit will also cause CPUID validation failures when running SEV-SNP guests. Signed-off-by: Michael Roth <michael.roth@amd.com>
* target/i386: allow versioned CPUs to specify new cache_infoMichael Roth2021-10-241-3/+33
| | | | | | | | | | | | New EPYC CPUs versions require small changes to their cache_info's. Because current QEMU x86 CPU definition does not support cache versions, we would have to declare a new CPU type for each such case. To avoid this duplication, the patch allows new cache_info pointers to be specificed for a new CPU version. Co-developed-by: Wei Huang <wei.huang2@amd.com> Signed-off-by: Wei Huang <wei.huang2@amd.com> Signed-off-by: Michael Roth <michael.roth@amd.com>
* target/i386: set SEV-SNP CPUID bit when SNP enabledMichael Roth2021-10-241-0/+1
| | | | | | SNP guests will rely on this bit to determine certain feature support. Signed-off-by: Michael Roth <michael.roth@amd.com>
* i386/sev: populate secrets and cpuid page and finalize the SNP launchBrijesh Singh2021-10-242-2/+109
| | | | | | | | | | | | | | | | | | | | | | | | During the SNP guest launch sequence, a special secrets and cpuid page needs to be populated by the SEV-SNP firmware. The secrets page contains the VM Platform Communication Key (VMPCKs) used by the guest to send and receive secure messages to the PSP. And CPUID page will contain the CPUID value filtered through the PSP. The guest BIOS (OVMF) reserves these pages in MEMFD and location of it is available through the SEV metadata descriptor. While finalizing the guest boot flow, iterates through all the descriptors and call the SNP_LAUNCH_UPDATE command to populate secrets and cpuid pages. In order to support early boot code, the OVMF may ask hypervisor to request the pre-validation of certain memory range. If such range is present the call SNP_LAUNCH_UPDATE command to validate those address range without affecting the measurement. See the SEV-SNP specification for further details. Finally, call the SNP_LAUNCH_FINISH to finalize the guest boot. Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Signed-off-by: Michael Roth <michael.roth@amd.com>
* i386/sev: add support to encrypt BIOS when SEV-SNP is enabledBrijesh Singh2021-10-233-4/+55
| | | | | | | | The KVM_SEV_SNP_LAUNCH_UPDATE command is used for encrypting the bios image used for booting the SEV-SNP guest. Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Signed-off-by: Michael Roth <michael.roth@amd.com>
* i386/sev: add the SNP launch start contextBrijesh Singh2021-10-232-1/+29
| | | | | | | | The SNP_LAUNCH_START is called first to create a cryptographic launch context within the firmware. Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Signed-off-by: Michael Roth <michael.roth@amd.com>
* i386/sev: initialize SNP contextBrijesh Singh2021-10-234-5/+34
| | | | | | | | | | When SEV-SNP is enabled, the KVM_SNP_INIT command is used to initialize the platform. The command checks whether SNP is enabled in the KVM, if enabled then it allocates a new ASID from the SNP pool and calls the firmware to initialize the all the resources. Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Signed-off-by: Michael Roth <michael.roth@amd.com>
* i386/sev: introduce 'sev-snp-guest' objectBrijesh Singh2021-10-231-1/+266
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SEV-SNP support relies on a different set of properties/state than the existing 'sev-guest' object. This patch introduces the 'sev-snp-guest' object, which can be used to configure an SEV-SNP guest. For example, a default-configured SEV-SNP guest with no additional information passed in for use with attestation: -object sev-snp-guest,id=sev0 or a fully-specified SEV-SNP guest where all spec-defined binary blobs are passed in as base64-encoded strings: -object sev-snp-guest,id=sev0, \ policy=0x30000, \ init-flags=0, \ id-block=YWFhYWFhYWFhYWFhYWFhCg==, \ id-auth=CxHK/OKLkXGn/KpAC7Wl1FSiisWDbGTEKz..., \ auth-key-enabled=on, \ host-data=LNkCWBRC5CcdGXirbNUV1OrsR28s..., \ guest-visible-workarounds=AA==, \ See the QAPI schema updates included in this patch for more usage details. In some cases these blobs may be up to 4096 characters, but this is generally well below the default limit for linux hosts where command-line sizes are defined by the sysconf-configurable ARG_MAX value, which defaults to 2097152 characters for Ubuntu hosts, for example. Co-developed-by: Michael Roth <michael.roth@amd.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Signed-off-by: Michael Roth <michael.roth@amd.com>
* linux-header: add the SNP specific commandBrijesh Singh2021-10-221-0/+6
| | | | | | | | Sync the kvm.h and psp-sev.h with the kernel to include the SNP specific commands. Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Signed-off-by: Michael Roth <michael.roth@amd.com>
* i386/sev: introduce "sev-common" type to encapsulate common SEV stateMichael Roth2021-10-131-137/+192
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently all SEV/SEV-ES functionality is managed through a single 'sev-guest' QOM type. With upcoming support for SEV-SNP, taking this same approach won't work well since some of the properties/state managed by 'sev-guest' is not applicable to SEV-SNP, which will instead rely on a new QOM type with its own set of properties/state. To prepare for this, this patch moves common state into an abstract 'sev-common' parent type to encapsulate properties/state that is common to both SEV/SEV-ES and SEV-SNP, leaving only SEV/SEV-ES-specific properties/state in the current 'sev-guest' type. This should not affect current behavior or command-line options. As part of this patch, some related changes are also made: - a static 'sev_guest' variable is currently used to keep track of the 'sev-guest' instance. SEV-SNP would similarly introduce an 'sev_snp_guest' static variable. But these instances are now available via qdev_get_machine()->cgs, so switch to using that instead and drop the static variable. - 'sev_guest' is currently used as the name for the static variable holding a pointer to the 'sev-guest' instance. Re-purpose the name as a local variable referring the 'sev-guest' instance, and use that consistently throughout the code so it can be easily distinguished from sev-common/sev-snp-guest instances. - 'sev' is generally used as the name for local variables holding a pointer to the 'sev-guest' instance. In cases where that now points to common state, use the name 'sev_common'; in cases where that now points to state specific to 'sev-guest' instance, use the name 'sev_guest' Signed-off-by: Michael Roth <michael.roth@amd.com>
* target/s390x: move tcg_gen_insn_start to s390x_tr_insn_startRichard Henderson2021-10-121-2/+8
| | | | | | | | | | | | | We use INDEX_op_insn_start to make the start of instruction boundaries. If we don't do it in the .insn_start hook things get confused especially now plugins want to use that marking to identify the start of instructions and will bomb out if it sees instrumented ops before the first instruction boundary. Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20211011185332.166763-1-richard.henderson@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
* target/riscv: Set mstatus_hs.[SD|FS] bits if Clean and V=1 in mark_fs_dirty()Frank Chang2021-10-072-13/+21
| | | | | | | | | | | | | | | | | | | When V=1, both vsstauts.FS and HS-level sstatus.FS are in effect. Modifying the floating-point state when V=1 causes both fields to be set to 3 (Dirty). However, it's possible that HS-level sstatus.FS is Clean and VS-level vsstatus.FS is Dirty at the time mark_fs_dirty() is called when V=1. We can't early return for this case because we still need to set sstatus.FS to Dirty according to spec. Signed-off-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Vincent Chen <vincent.chen@sifive.com> Tested-by: Vincent Chen <vincent.chen@sifive.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20210921020234.123448-1-frank.chang@sifive.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
* target/riscv: Remove RVB (replaced by Zb[abcs])Philipp Tomsich2021-10-073-33/+0
| | | | | | | | | | | | | | | | | With everything classified as Zb[abcs] and pre-0.93 draft-B instructions that are not part of Zb[abcs] removed, we can remove the remaining support code for RVB. Note that RVB has been retired for good and misa.B will neither mean 'some' or 'all of' Zb*: https://lists.riscv.org/g/tech-bitmanip/message/532 Signed-off-by: Philipp Tomsich <philipp.tomsich@vrull.eu> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Message-id: 20210911140016.834071-16-philipp.tomsich@vrull.eu Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
* target/riscv: Add zext.h instructions to Zbb, removing pack/packu/packhPhilipp Tomsich2021-10-072-77/+21
| | | | | | | | | | | | | | | | | The 1.0.0 version of Zbb does not contain pack/packu/packh. However, a zext.h instruction is provided (built on pack/packh from pre-0.93 draft-B) is available. This commit adds zext.h and removes the pack* instructions. Note that the encodings for zext.h are different between RV32 and RV64, which is handled through REQUIRE_32BIT. Signed-off-by: Philipp Tomsich <philipp.tomsich@vrull.eu> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20210911140016.834071-15-philipp.tomsich@vrull.eu Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
* target/riscv: Add rev8 instruction, removing grev/greviPhilipp Tomsich2021-10-074-79/+15
| | | | | | | | | | | | | | | | | | | | The 1.0.0 version of Zbb does not contain grev/grevi. Instead, a rev8 instruction (equivalent to the rev8 pseudo-instruction built on grevi from pre-0.93 draft-B) is available. This commit adds the new rev8 instruction and removes grev/grevi. Note that there is no W-form of this instruction (both a sign-extending and zero-extending 32-bit version can easily be synthesized by following rev8 with either a srai or srli instruction on RV64) and that the opcode encodings for rev8 in RV32 and RV64 are different. Signed-off-by: Philipp Tomsich <philipp.tomsich@vrull.eu> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20210911140016.834071-14-philipp.tomsich@vrull.eu Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
* target/riscv: Add a REQUIRE_32BIT macroPhilipp Tomsich2021-10-071-0/+6
| | | | | | | | | | | | | With the changes to Zb[abcs], there's some encodings that are different in RV64 and RV32 (e.g., for rev8 and zext.h). For these, we'll need a helper macro allowing us to select on RV32, as well. Signed-off-by: Philipp Tomsich <philipp.tomsich@vrull.eu> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Message-id: 20210911140016.834071-13-philipp.tomsich@vrull.eu Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
* target/riscv: Add orc.b instruction for Zbb, removing gorc/gorciPhilipp Tomsich2021-10-074-55/+18
| | | | | | | | | | | | | | | The 1.0.0 version of Zbb does not contain gorc/gorci. Instead, a orc.b instruction (equivalent to the orc.b pseudo-instruction built on gorci from pre-0.93 draft-B) is available, mainly targeting string-processing workloads. This commit adds the new orc.b instruction and removed gorc/gorci. Signed-off-by: Philipp Tomsich <philipp.tomsich@vrull.eu> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20210911140016.834071-12-philipp.tomsich@vrull.eu Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
* target/riscv: Reassign instructions to the Zbb-extensionPhilipp Tomsich2021-10-072-41/+50
| | | | | | | | | | | | | This reassigns the instructions that are part of Zbb into it, with the notable exceptions of the instructions (rev8, zext.w and orc.b) that changed due to gorci, grevi and pack not being part of Zb[abcs]. Signed-off-by: Philipp Tomsich <philipp.tomsich@vrull.eu> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Acked-by: Bin Meng <bmeng.cn@gmail.com> Message-id: 20210911140016.834071-11-philipp.tomsich@vrull.eu Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
* target/riscv: Add instructions of the Zbc-extensionPhilipp Tomsich2021-10-074-1/+65
| | | | | | | | | | | | | | | | | The following instructions are part of Zbc: - clmul - clmulh - clmulr Note that these instructions were already defined in the pre-0.93 and the 0.93 draft-B proposals, but had not been omitted in the earlier addition of draft-B to QEmu. Signed-off-by: Philipp Tomsich <philipp.tomsich@vrull.eu> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20210911140016.834071-10-philipp.tomsich@vrull.eu Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
* target/riscv: Reassign instructions to the Zbs-extensionPhilipp Tomsich2021-10-072-18/+24
| | | | | | | | | | | | | The following instructions are part of Zbs: - b{set,clr,ext,inv} - b{set,clr,ext,inv}i Signed-off-by: Philipp Tomsich <philipp.tomsich@vrull.eu> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Acked-by: Bin Meng <bmeng.cn@gmail.com> Message-id: 20210911140016.834071-9-philipp.tomsich@vrull.eu Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
* target/riscv: Remove shift-one instructions (proposed Zbo in pre-0.93 draft-B)Philipp Tomsich2021-10-072-78/+0
| | | | | | | | | | | | | | The Zb[abcs] ratification package does not include the proposed shift-one instructions. There currently is no clear plan to whether these (or variants of them) will be ratified as Zbo (or a different extension) or what the timeframe for such a decision could be. Signed-off-by: Philipp Tomsich <philipp.tomsich@vrull.eu> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Acked-by: Bin Meng <bmeng.cn@gmail.com> Message-id: 20210911140016.834071-8-philipp.tomsich@vrull.eu Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
* target/riscv: Remove the W-form instructions from ZbsPhilipp Tomsich2021-10-072-63/+0
| | | | | | | | | | | | | | | | Zbs 1.0.0 (just as the 0.93 draft-B before) does not provide for W-form instructions for Zbs (single-bit instructions). Remove them. Note that these instructions had already been removed for the 0.93 version of the draft-B extention and have not been present in the binutils patches circulating in January 2021. Signed-off-by: Philipp Tomsich <philipp.tomsich@vrull.eu> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Acked-by: Bin Meng <bmeng.cn@gmail.com> Message-id: 20210911140016.834071-7-philipp.tomsich@vrull.eu Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
* target/riscv: Reassign instructions to the Zba-extensionPhilipp Tomsich2021-10-072-13/+23
| | | | | | | | | | | | | | | The following instructions are part of Zba: - add.uw (RV64 only) - sh[123]add (RV32 and RV64) - sh[123]add.uw (RV64-only) - slli.uw (RV64-only) Signed-off-by: Philipp Tomsich <philipp.tomsich@vrull.eu> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Acked-by: Bin Meng <bmeng.cn@gmail.com> Message-id: 20210911140016.834071-6-philipp.tomsich@vrull.eu Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
* target/riscv: Add x-zba, x-zbb, x-zbc and x-zbs propertiesPhilipp Tomsich2021-10-072-0/+8
| | | | | | | | | | | | | | | | | The bitmanipulation ISA extensions will be ratified as individual small extension packages instead of a large B-extension. The first new instructions through the door (these have completed public review) are Zb[abcs]. This adds new 'x-zba', 'x-zbb', 'x-zbc' and 'x-zbs' properties for these in target/riscv/cpu.[ch]. Signed-off-by: Philipp Tomsich <philipp.tomsich@vrull.eu> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Message-id: 20210911140016.834071-5-philipp.tomsich@vrull.eu Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
* target/riscv: clwz must ignore high bits (use shift-left & changed logic)Philipp Tomsich2021-10-071-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Assume clzw being executed on a register that is not sign-extended, such as for the following sequence that uses (1ULL << 63) | 392 as the operand to clzw: bseti a2, zero, 63 addi a2, a2, 392 clzw a3, a2 The correct result of clzw would be 23, but the current implementation returns -32 (as it performs a 64bit clz, which results in 0 leading zero bits, and then subtracts 32). Fix this by changing the implementation to: 1. shift the original register up by 32 2. performs a target-length (64bit) clz 3. return 32 if no bits are set Marking this instruction as 'w-form' (i.e., setting ctx->w) would not correctly model the behaviour, as the instruction should not perform a zero-extensions on the input (after all, it is not a .uw instruction) and the result is always in the range 0..32 (so neither a sign-extension nor a zero-extension on the result will ever be needed). Consequently, we do not set ctx->w and mark the instruction as EXT_NONE. Signed-off-by: Philipp Tomsich <philipp.tomsich@vrull.eu> Reviewed-by: LIU Zhiwei<zhiwei_liu@c-sky.com> Message-id: 20210911140016.834071-4-philipp.tomsich@vrull.eu Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
* target/riscv: fix clzw implementation to operate on arg1Philipp Tomsich2021-10-071-1/+1
| | | | | | | | | | | | | The refactored gen_clzw() uses ret as its argument, instead of arg1. Fix it. Signed-off-by: Philipp Tomsich <philipp.tomsich@vrull.eu> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20210911140016.834071-3-philipp.tomsich@vrull.eu Fixes: 60903915050 ("target/riscv: Add DisasExtend to gen_unary") Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
* target/riscv: Introduce temporary in gen_add_uw()Philipp Tomsich2021-10-071-2/+4
| | | | | | | | | | | | | | Following the recent changes in translate.c, gen_add_uw() causes failures on CF3 and SPEC2017 due to the reuse of arg1. Fix these regressions by introducing a temporary. Signed-off-by: Philipp Tomsich <philipp.tomsich@vrull.eu> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20210911140016.834071-2-philipp.tomsich@vrull.eu Fixes: 191d1dafae9c ("target/riscv: Add DisasExtend to gen_arith*") Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
* Merge remote-tracking branch 'remotes/quic/tags/pull-hex-20211006' into stagingRichard Henderson2021-10-067-58/+78
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Change from Philippe - Use tcg_constant_* Change from Philippe - Remove unused TCG temp Change from Taylor - Probe the stores in a packet at start of commit # gpg: Signature made Wed 06 Oct 2021 08:44:13 AM PDT # gpg: using RSA key 7B0244FB12DE4422 # gpg: Good signature from "Taylor Simpson (Rock on) <tsimpson@quicinc.com>" [marginal] # gpg: WARNING: This key is not certified with sufficiently trusted signatures! # gpg: It is not certain that the signature belongs to the owner. # Primary key fingerprint: 3635 C788 CE62 B91F D4C5 9AB4 7B02 44FB 12DE 4422 * remotes/quic/tags/pull-hex-20211006: target/hexagon: Use tcg_constant_* target/hexagon: Remove unused TCG temporary from predicated loads Hexagon (target/hexagon) probe the stores in a packet at start of commit Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
| * target/hexagon: Use tcg_constant_*Philippe Mathieu-Daudé2021-10-065-53/+25
| | | | | | | | | | | | | | | | | | | | Replace uses of tcg_const_* with the allocate and free close together. Inspired-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Taylor Simpson <tsimpson@quicinc.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20211003004750.3608983-3-f4bug@amsat.org>
| * target/hexagon: Remove unused TCG temporary from predicated loadsPhilippe Mathieu-Daudé2021-10-061-2/+0
| | | | | | | | | | | | | | | | | | | | The gen_pred_cancel() function, introduced in commit a646e99cb90 (Hexagon macros) doesn't use the 'one' TCG temporary; remove it. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Taylor Simpson <tsimpson@quicinc.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20211003004750.3608983-2-f4bug@amsat.org>
| * Hexagon (target/hexagon) probe the stores in a packet at start of commitTaylor Simpson2021-10-063-3/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a packet has 2 stores, either both commit or neither commit. At the beginning of gen_commit_packet, we check for multiple stores. If there are multiple stores, call a helper that will probe each of them before proceeding with the commit. Note that we don't call the probe helper for packets with only one store. Therefore, we call process_store_log before anything else involved in committing the packet. We also fix a typo in the comment in process_store_log. Test case added in tests/tcg/hexagon/hex_sigsegv.c Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Taylor Simpson <tsimpson@quicinc.com> Message-Id: <1633036599-7637-1-git-send-email-tsimpson@quicinc.com>
* | tcg: Rename TCGMemOpIdx to MemOpIdxRichard Henderson2021-10-057-26/+26
| | | | | | | | | | | | | | | | | | We're about to move this out of tcg.h, so rename it as we did when moving MemOp. Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
* | tcg: Expand MO_SIZE to 3 bitsRichard Henderson2021-10-052-2/+2
|/ | | | | | | | | | | We have lacked expressive support for memory sizes larger than 64-bits for a while. Fixing that requires adjustment to several points where we used this for array indexing, and two places that develop -Wswitch warnings after the change. Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
* target/xtensa: list cores in a text filePaolo Bonzini2021-10-053-2/+14
| | | | | | | | | | Avoid that leftover files affect the build; instead, use the same mechanism that was in place before the Meson transition of updating a file from import_core.sh. Starting with Meson 0.57, the file can be easily read from the filesystem module, so do that instead of using run_command. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* hexagon: use env keyword argument to pass PYTHONPATHPaolo Bonzini2021-10-051-1/+2
| | | | | | This feature is new in meson 0.57 and allows getting rid of the "env" wrapper. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* sev/i386: Introduce sev_add_kernel_loader_hashes for measured linux bootDov Murik2021-10-053-0/+154
| | | | | | | | | | | | | | | | | | | | | Add the sev_add_kernel_loader_hashes function to calculate the hashes of the kernel/initrd/cmdline and fill a designated OVMF encrypted hash table area. For this to work, OVMF must support an encrypted area to place the data which is advertised via a special GUID in the OVMF reset table. The hashes of each of the files is calculated (or the string in the case of the cmdline with trailing '\0' included). Each entry in the hashes table is GUID identified and since they're passed through the sev_encrypt_flash interface, the hashes will be accumulated by the AMD PSP measurement (SEV_LAUNCH_MEASURE). Co-developed-by: James Bottomley <jejb@linux.ibm.com> Signed-off-by: James Bottomley <jejb@linux.ibm.com> Signed-off-by: Dov Murik <dovmurik@linux.ibm.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20210930054915.13252-2-dovmurik@linux.ibm.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* target/sh4: Use lookup_symbol in sh4_tr_disas_logRichard Henderson2021-10-041-1/+1
| | | | | | | | | | | The correct thing to do has been present but commented out since the initial commit of the sh4 translator. Fixes: fdf9b3e831e Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210929130316.121330-1-richard.henderson@linaro.org> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
* i386: Change the default Hyper-V version to match WS2016Vitaly Kuznetsov2021-10-011-3/+3
| | | | | | | | | | | | | KVM implements some Hyper-V 2016 functions so providing WS2008R2 version is somewhat incorrect. While generally guests shouldn't care about it and always check feature bits, it is known that some tools in Windows actually check version info. For compatibility reasons make the change for 6.2 machine types only. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20210902093530.345756-9-vkuznets@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* i386: Make Hyper-V version id configurableVitaly Kuznetsov2021-10-013-15/+33
| | | | | | | | | | | | | | | | | | Currently, we hardcode Hyper-V version id (CPUID 0x40000002) to WS2008R2 and it is known that certain tools in Windows check this. It seems useful to provide some flexibility by making it possible to change this info at will. CPUID information is defined in TLFS as: EAX: Build Number EBX Bits 31-16: Major Version Bits 15-0: Minor Version ECX Service Pack EDX Bits 31-24: Service Branch Bits 23-0: Service Number Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20210902093530.345756-8-vkuznets@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* i386: Implement pseudo 'hv-avic' ('hv-apicv') enlightenmentVitaly Kuznetsov2021-10-014-1/+15
| | | | | | | | | | | | | | | The enlightenment allows to use Hyper-V SynIC with hardware APICv/AVIC enabled. Normally, Hyper-V SynIC disables these hardware features and suggests the guest to use paravirtualized AutoEOI feature. Linux-4.15 gains support for conditional APICv/AVIC disablement, the feature stays on until the guest tries to use AutoEOI feature with SynIC. With 'HV_DEPRECATING_AEOI_RECOMMENDED' bit exposed, modern enough Windows/ Hyper-V versions should follow the recommendation and not use the (unwanted) feature. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20210902093530.345756-7-vkuznets@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* i386: Move HV_APIC_ACCESS_RECOMMENDED bit setting to hyperv_fill_cpuids()Vitaly Kuznetsov2021-10-011-3/+6
| | | | | | | | | | | | In preparation to enabling Hyper-V + APICv/AVIC move HV_APIC_ACCESS_RECOMMENDED setting out of kvm_hyperv_properties[]: the 'real' feature bit for the vAPIC features is HV_APIC_ACCESS_AVAILABLE, HV_APIC_ACCESS_RECOMMENDED is a recommendation to use the feature which we may not always want to give. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20210902093530.345756-6-vkuznets@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* i386: Support KVM_CAP_HYPERV_ENFORCE_CPUIDVitaly Kuznetsov2021-10-013-0/+11
| | | | | | | | | | | | | By default, KVM allows the guest to use all currently supported Hyper-V enlightenments when Hyper-V CPUID interface was exposed, regardless of if some features were not announced in guest visible CPUIDs. hv-enforce-cpuid feature alters this behavior and only allows the guest to use exposed Hyper-V enlightenments. The feature is supported by Linux >= 5.14 and is not enabled by default in QEMU. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20210902093530.345756-5-vkuznets@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* i386: Support KVM_CAP_ENFORCE_PV_FEATURE_CPUIDVitaly Kuznetsov2021-10-013-0/+15
| | | | | | | | | | | | By default, KVM allows the guest to use all currently supported PV features even when they were not announced in guest visible CPUIDs. Introduce a new "kvm-pv-enforce-cpuid" flag to limit the supported feature set to the exposed features. The feature is supported by Linux >= 5.10 and is not enabled by default in QEMU. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20210902093530.345756-4-vkuznets@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
generated by cgit v1.2.3-71-gd317 (git 2.46.0) at 2026-02-09 04:09:35 +0000