aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-10-01qtest/numa-test: Use detailed -smp CLIs in test_def_cpu_splitYanan Wang1-1/+2
Since commit 80d7835749 (qemu-options: rewrite help for -smp options), the preference of sockets/cores in -smp parsing is considered liable to change, and actually we are going to change it in a coming commit. So it'll be more stable to use detailed -smp CLIs in the testcases that have strong dependency on the parsing results. Currently, test_def_cpu_split use "-smp 8" and will get 8 CPU sockets based on current parsing rule. But if we change to prefer cores over sockets we will get one CPU socket with 8 cores, and this testcase will not get expected numa set by default on x86_64 (Ok on aarch64). So now explicitly use "-smp 8,sockets=8" to avoid affect from parsing logic change. Signed-off-by: Yanan Wang <wangyanan55@huawei.com> Reviewed-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20210929025816.21076-9-wangyanan55@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-10-01qtest/numa-test: Use detailed -smp CLIs in pc_dynamic_cpu_cfgYanan Wang1-1/+2
Since commit 80d7835749 (qemu-options: rewrite help for -smp options), the preference of sockets/cores in -smp parsing is considered liable to change, and actually we are going to change it in a coming commit. So it'll be more stable to use detailed -smp CLIs in testing if we have strong dependency on the parsing results. pc_dynamic_cpu_cfg currently assumes/needs that there will be 2 CPU sockets with "-smp 2". To avoid breaking the test because of parsing logic change, now explicitly use "-smp 2,sockets=2". Signed-off-by: Yanan Wang <wangyanan55@huawei.com> Reviewed-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20210929025816.21076-8-wangyanan55@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-10-01machine: Improve the error reporting of smp parsingYanan Wang2-27/+19
We have two requirements for a valid SMP configuration: the product of "sockets * cores * threads" must represent all the possible cpus, i.e., max_cpus, and then must include the initially present cpus, i.e., smp_cpus. So we only need to ensure 1) "sockets * cores * threads == maxcpus" at first and then ensure 2) "maxcpus >= cpus". With a reasonable order of the sanity check, we can simplify the error reporting code. When reporting an error message we also report the exact value of each topology member to make users easily see what's going on. Signed-off-by: Yanan Wang <wangyanan55@huawei.com> Reviewed-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Pankaj Gupta <pankaj.gupta@ionos.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20210929025816.21076-7-wangyanan55@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-10-01machine: Set the value of cpus to match maxcpus if it's omittedYanan Wang3-29/+40
Currently we directly calculate the omitted cpus based on the given incomplete collection of parameters. This makes some cmdlines like: -smp maxcpus=16 -smp sockets=2,maxcpus=16 -smp sockets=2,dies=2,maxcpus=16 -smp sockets=2,cores=4,maxcpus=16 not work. We should probably set the value of cpus to match maxcpus if it's omitted, which will make above configs start to work. So the calculation logic of cpus/maxcpus after this patch will be: When both maxcpus and cpus are omitted, maxcpus will be calculated from the given parameters and cpus will be set equal to maxcpus. When only one of maxcpus and cpus is given then the omitted one will be set to its counterpart's value. Both maxcpus and cpus may be specified, but maxcpus must be equal to or greater than cpus. Note: change in this patch won't affect any existing working cmdlines but allows more incomplete configs to be valid. Signed-off-by: Yanan Wang <wangyanan55@huawei.com> Reviewed-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20210929025816.21076-6-wangyanan55@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-10-01machine: Uniformly use maxcpus to calculate the omitted parametersYanan Wang2-30/+30
We are currently using maxcpus to calculate the omitted sockets but using cpus to calculate the omitted cores/threads. This makes cmdlines like: -smp cpus=8,maxcpus=16 -smp cpus=8,cores=4,maxcpus=16 -smp cpus=8,threads=2,maxcpus=16 work fine but the ones like: -smp cpus=8,sockets=2,maxcpus=16 -smp cpus=8,sockets=2,cores=4,maxcpus=16 -smp cpus=8,sockets=2,threads=2,maxcpus=16 break the sanity check. Since we require for a valid config that the product of "sockets * cores * threads" should equal to the maxcpus, we should uniformly use maxcpus to calculate their omitted values. Also the if-branch of "cpus == 0 || sockets == 0" was split into two branches of "cpus == 0" and "sockets == 0" so that we can clearly read that we are parsing the configuration with a preference on cpus over sockets over cores over threads. Note: change in this patch won't affect any existing working cmdlines but improves consistency and allows more incomplete configs to be valid. Signed-off-by: Yanan Wang <wangyanan55@huawei.com> Reviewed-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Pankaj Gupta <pankaj.gupta@ionos.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20210929025816.21076-5-wangyanan55@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-10-01machine: Minor refactor/fix for the smp parsersYanan Wang2-17/+24
To pave the way for the functional improvement in later patches, make some refactor/cleanup for the smp parsers, including using local maxcpus instead of ms->smp.max_cpus in the calculation, defaulting dies to 0 initially like other members, cleanup the sanity check for dies. We actually also fix a hidden defect by avoiding directly using the provided *zero value* in the calculation, which could cause a segment fault (e.g. using dies=0 in the calculation). Signed-off-by: Yanan Wang <wangyanan55@huawei.com> Reviewed-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20210929025816.21076-4-wangyanan55@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-10-01machine: Deprecate "parameter=0" SMP configurationsYanan Wang3-5/+36
In the SMP configuration, we should either provide a topology parameter with a reasonable value (greater than zero) or just omit it and QEMU will compute the missing value. The users shouldn't provide a configuration with any parameter of it specified as zero (e.g. -smp 8,sockets=0) which could possibly cause unexpected results in the -smp parsing. So we deprecate this kind of configurations since 6.2 by adding the explicit sanity check. Signed-off-by: Yanan Wang <wangyanan55@huawei.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20210929025816.21076-3-wangyanan55@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-10-01qapi/machine: Fix an incorrect comment of SMPConfigurationYanan Wang1-1/+1
The explanation of @cores should be "number of cores per die" but not "number of cores per thread". Let's fix it. Fixes: 1e63fe685804 ("machine: pass QAPI struct to mc->smp_parse") Signed-off-by: Yanan Wang <wangyanan55@huawei.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20210929025816.21076-2-wangyanan55@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-09-30Merge remote-tracking branch ↵Peter Maydell108-447/+3806
'remotes/pmaydell/tags/pull-target-arm-20210930' into staging target-arm queue: * allwinner-h3: Switch to SMC as PSCI conduit * arm: tcg: Adhere to SMCCC 1.3 section 5.2 * xlnx-zcu102, xlnx-versal-virt: Support BBRAM and eFUSE devices * gdbstub related code cleanups * Don't put FPEXC and FPSID in org.gnu.gdb.arm.vfp XML * Use _init vs _new convention in bus creation function names * sabrelite: Connect SPI flash CS line to GPIO3_19 # gpg: Signature made Thu 30 Sep 2021 16:11:20 BST # gpg: using RSA key E1A5C593CD419DE28E8315CF3C2525ED14360CDE # gpg: issuer "peter.maydell@linaro.org" # gpg: Good signature from "Peter Maydell <peter.maydell@linaro.org>" [ultimate] # gpg: aka "Peter Maydell <pmaydell@gmail.com>" [ultimate] # gpg: aka "Peter Maydell <pmaydell@chiark.greenend.org.uk>" [ultimate] # Primary key fingerprint: E1A5 C593 CD41 9DE2 8E83 15CF 3C25 25ED 1436 0CDE * remotes/pmaydell/tags/pull-target-arm-20210930: (22 commits) hw/arm: sabrelite: Connect SPI flash CS line to GPIO3_19 ide: Rename ide_bus_new() to ide_bus_init() qbus: Rename qbus_create() to qbus_new() qbus: Rename qbus_create_inplace() to qbus_init() pci: Rename pci_root_bus_new_inplace() to pci_root_bus_init() ipack: Rename ipack_bus_new_inplace() to ipack_bus_init() scsi: Replace scsi_bus_new() with scsi_bus_init(), scsi_bus_init_named() target/arm: Don't put FPEXC and FPSID in org.gnu.gdb.arm.vfp XML target/arm: Move gdbstub related code out of helper.c target/arm: Fix coding style issues in gdbstub code in helper.c configs: Don't include 32-bit-only GDB XML in aarch64 linux configs docs/system/arm: xlnx-versal-virt: BBRAM and eFUSE Usage hw/arm: xlnx-zcu102: Add Xilinx eFUSE device hw/arm: xlnx-zcu102: Add Xilinx BBRAM device hw/arm: xlnx-versal-virt: Add Xilinx eFUSE device hw/arm: xlnx-versal-virt: Add Xilinx BBRAM device hw/nvram: Introduce Xilinx battery-backed ram hw/nvram: Introduce Xilinx ZynqMP eFuse device hw/nvram: Introduce Xilinx Versal eFuse device hw/nvram: Introduce Xilinx eFuse QOM ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-09-30Merge remote-tracking branch 'remotes/bonzini-gitlab/tags/for-upstream' into ↵Peter Maydell64-38/+1397
staging * SGX implementation for x86 * Miscellaneous bugfixes * Fix dependencies from ROMs to qtests # gpg: Signature made Thu 30 Sep 2021 14:30:35 BST # 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: (33 commits) meson_options.txt: Switch the default value for the vnc option to 'auto' build-sys: add HAVE_IPPROTO_MPTCP memory: Add tracepoint for dirty sync memory: Name all the memory listeners target/i386: Fix memory leak in sev_read_file_base64() tests: qtest: bios-tables-test depends on the unpacked edk2 ROMs meson: unpack edk2 firmware even if --disable-blobs target/i386: Add the query-sgx-capabilities QMP command target/i386: Add HMP and QMP interfaces for SGX docs/system: Add SGX documentation to the system manual sgx-epc: Add the fill_device_info() callback support i440fx: Add support for SGX EPC q35: Add support for SGX EPC i386: acpi: Add SGX EPC entry to ACPI tables i386/pc: Add e820 entry for SGX EPC section(s) hw/i386/pc: Account for SGX EPC sections when calculating device memory hw/i386/fw_cfg: Set SGX bits in feature control fw_cfg accordingly Adjust min CPUID level to 0x12 when SGX is enabled i386: Propagate SGX CPUID sub-leafs to KVM i386: kvm: Add support for exposing PROVISIONKEY to guest ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-09-30Merge remote-tracking branch 'remotes/dg-gitlab/tags/ppc-for-6.2-20210930' ↵Peter Maydell35-445/+741
into staging ppc patch queue for 2021-09-30 Here's the next batch of ppc related patches for qemu-6.2. Highlights are: * Fixes for several TCG math instructions from the El Dorado Institute * A number of improvements to the powernv machine type * Support for a new DEVICE_UNPLUG_GUEST_ERROR QAPI event from Daniel Barboza * Support for the new FORM2 PAPR NUMA representation. This allows more specific NUMA distances, as well as asymmetric configurations * Fix for 64-bit decrementer (used on MicroWatt CPUs) * Assorted fixes and cleanups * A number of updates to MAINTAINERS Note that the DEVICE_UNPLUG_GUEST_ERROR stuff includes changes to files outside my normal area, but has suitable Acks. The MAINTAINERS updates are mostly about marking minor platforms unmaintained / orphaned, and moving some pieces away from myself and Greg. As we move onto other projects, we're going to need to drop more of the ppc maintainership, though we're hoping we can avoid too abrupt a change. # gpg: Signature made Thu 30 Sep 2021 06:42:41 BST # 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/ppc-for-6.2-20210930: (44 commits) MAINTAINERS: Demote sPAPR from "Supported" to "Maintained" MAINTAINERS: Add information for OpenPIC MAINTAINERS: Remove David & Greg as reviewers/co-maintainers of powernv MAINTAINERS: Orphan obscure ppc platforms MAINTAINERS: Remove David & Greg as reviewers for a number of boards MAINTAINERS: Remove machine specific files from ppc TCG CPUs entry spapr/xive: Fix kvm_xive_source_reset trace event spapr_numa.c: fixes in spapr_numa_FORM2_write_rtas_tables() hw/intc: openpic: Clean up the styles hw/intc: openpic: Drop Raven related codes hw/intc: openpic: Correct the reset value of IPIDR for FSL chipset target/ppc: Fix 64-bit decrementer target/ppc: Convert debug to trace events (decrementer and IRQ) spapr_numa.c: handle auto NUMA node with no distance info spapr_numa.c: FORM2 NUMA affinity support spapr: move FORM1 verifications to post CAS spapr_numa.c: rename numa_assoc_array to FORM1_assoc_array spapr_numa.c: parametrize FORM1 macros spapr_numa.c: scrap 'legacy_numa' concept spapr_numa.c: split FORM1 code into helpers ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-09-30meson_options.txt: Switch the default value for the vnc option to 'auto'Thomas Huth1-1/+1
There is no reason why VNC should always be enabled and not be set to the default value. We already switched the setting in the "configure" script in commit 3a6a1256d4 ("configure: Allow vnc to get disabled with --without-default-features"), so let's do that in meson_options.txt now, too. Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <20210903081358.956267-3-thuth@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-09-30build-sys: add HAVE_IPPROTO_MPTCPMarc-André Lureau4-5/+7
The QAPI schema shouldn't rely on C system headers #define, but on configure-time project #define, so we can express the build condition in a C-independent way. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20210907121943.3498701-3-marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-09-30memory: Add tracepoint for dirty syncPeter Xu2-0/+3
Trace at memory_region_sync_dirty_bitmap() for log_sync() or global_log_sync() on memory regions. One trace line should suffice when it finishes, so as to estimate the time used for each log sync process. Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <20210817013706.30986-1-peterx@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-09-30memory: Name all the memory listenersPeter Xu19-4/+33
Provide a name field for all the memory listeners. It can be used to identify which memory listener is which. Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> Message-Id: <20210817013553.30584-2-peterx@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-09-30target/i386: Fix memory leak in sev_read_file_base64()Peter Maydell1-1/+1
In sev_read_file_base64() we call g_file_get_contents(), which allocates memory for the file contents. We then base64-decode the contents (which allocates another buffer for the decoded data), but forgot to free the memory for the original file data. Use g_autofree to ensure that the file data is freed. Fixes: Coverity CID 1459997 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20210820165650.2839-1-peter.maydell@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-09-30tests: qtest: bios-tables-test depends on the unpacked edk2 ROMsPaolo Bonzini2-4/+5
Skip the test if bzip2 is not available, and run it after they are uncompressed. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20210923105529.3845741-2-pbonzini@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-09-30meson: unpack edk2 firmware even if --disable-blobsPaolo Bonzini3-11/+11
The edk2 firmware blobs are needed to run bios-tables-test. Unpack them if any UEFI-enabled target is selected, so that the test can run. This is a bit more than is actually necessary, since bios-tables-test does not run for all UEFI-enabled targets, but it is the easiest way to write this logic. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20210923105529.3845741-1-pbonzini@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-09-30target/i386: Add the query-sgx-capabilities QMP commandYang Zhong6-0/+97
Libvirt can use query-sgx-capabilities to get the host sgx capabilities to decide how to allocate SGX EPC size to VM. Signed-off-by: Yang Zhong <yang.zhong@intel.com> Message-Id: <20210910102258.46648-3-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-09-30target/i386: Add HMP and QMP interfaces for SGXYang Zhong8-0/+136
The QMP and HMP interfaces can be used by monitor or QMP tools to retrieve the SGX information from VM side when SGX is enabled on Intel platform. Signed-off-by: Yang Zhong <yang.zhong@intel.com> Message-Id: <20210910102258.46648-2-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-09-30docs/system: Add SGX documentation to the system manualSean Christopherson2-0/+166
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Yang Zhong <yang.zhong@intel.com> Message-Id: <20210719112136.57018-34-yang.zhong@intel.com> [Convert to reStructuredText, and adopt the standard === --- ~~~ headings suggested for example by Linux. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-09-30sgx-epc: Add the fill_device_info() callback supportYang Zhong3-4/+56
Since there is no fill_device_info() callback support, and when we execute "info memory-devices" command in the monitor, the segfault will be found. This patch will add this callback support and "info memory-devices" will show sgx epc memory exposed to guest. The result as below: qemu) info memory-devices Memory device [sgx-epc]: "" memaddr: 0x180000000 size: 29360128 memdev: /objects/mem1 Memory device [sgx-epc]: "" memaddr: 0x181c00000 size: 10485760 memdev: /objects/mem2 Signed-off-by: Yang Zhong <yang.zhong@intel.com> Message-Id: <20210719112136.57018-33-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-09-30i440fx: Add support for SGX EPCSean Christopherson1-0/+1
Enable SGX EPC virtualization, which is currently only support by KVM. Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Yang Zhong <yang.zhong@intel.com> Message-Id: <20210719112136.57018-22-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-09-30q35: Add support for SGX EPCSean Christopherson1-0/+1
Enable SGX EPC virtualization, which is currently only support by KVM. Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Yang Zhong <yang.zhong@intel.com> Message-Id: <20210719112136.57018-21-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-09-30i386: acpi: Add SGX EPC entry to ACPI tablesSean Christopherson1-0/+22
The ACPI Device entry for SGX EPC is essentially a hack whose primary purpose is to provide software with a way to autoprobe SGX support, e.g. to allow software to implement SGX support as a driver. Details on the individual EPC sections are not enumerated through ACPI tables, i.e. software must enumerate the EPC sections via CPUID. Furthermore, software expects to see only a single EPC Device in the ACPI tables regardless of the number of EPC sections in the system. However, several versions of Windows do rely on the ACPI tables to enumerate the address and size of the EPC. So, regardless of the number of EPC sections exposed to the guest, create exactly *one* EPC device with a _CRS entry that spans the entirety of all EPC sections (which are guaranteed to be contiguous in Qemu). Note, NUMA support for EPC memory is intentionally not considered as enumerating EPC NUMA information is not yet defined for bare metal. Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Yang Zhong <yang.zhong@intel.com> Message-Id: <20210719112136.57018-20-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-09-30i386/pc: Add e820 entry for SGX EPC section(s)Sean Christopherson1-0/+4
Note that SGX EPC is currently guaranteed to reside in a single contiguous chunk of memory regardless of the number of EPC sections. Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Yang Zhong <yang.zhong@intel.com> Message-Id: <20210719112136.57018-19-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-09-30hw/i386/pc: Account for SGX EPC sections when calculating device memorySean Christopherson2-1/+17
Add helpers to detect if SGX EPC exists above 4g, and if so, where SGX EPC above 4g ends. Use the helpers to adjust the device memory range if SGX EPC exists above 4g. For multiple virtual EPC sections, we just put them together physically contiguous for the simplicity because we don't support EPC NUMA affinity now. Once the SGX EPC NUMA support in the kernel SGX driver, we will support this in the future. Note that SGX EPC is currently hardcoded to reside above 4g. Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Yang Zhong <yang.zhong@intel.com> Message-Id: <20210719112136.57018-18-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-09-30hw/i386/fw_cfg: Set SGX bits in feature control fw_cfg accordinglySean Christopherson1-1/+11
Request SGX an SGX Launch Control to be enabled in FEATURE_CONTROL when the features are exposed to the guest. Our design is the SGX Launch Control bit will be unconditionally set in FEATURE_CONTROL, which is unlike host bios. Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Yang Zhong <yang.zhong@intel.com> Message-Id: <20210719112136.57018-17-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-09-30Adjust min CPUID level to 0x12 when SGX is enabledSean Christopherson1-0/+5
SGX capabilities are enumerated through CPUID_0x12. Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Yang Zhong <yang.zhong@intel.com> Message-Id: <20210719112136.57018-16-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-09-30i386: Propagate SGX CPUID sub-leafs to KVMSean Christopherson1-0/+19
The SGX sub-leafs are enumerated at CPUID 0x12. Indices 0 and 1 are always present when SGX is supported, and enumerate SGX features and capabilities. Indices >=2 are directly correlated with the platform's EPC sections. Because the number of EPC sections is dynamic and user defined, the number of SGX sub-leafs is "NULL" terminated. Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Yang Zhong <yang.zhong@intel.com> Message-Id: <20210719112136.57018-15-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-09-30i386: kvm: Add support for exposing PROVISIONKEY to guestSean Christopherson3-1/+35
If the guest want to fully use SGX, the guest needs to be able to access provisioning key. Add a new KVM_CAP_SGX_ATTRIBUTE to KVM to support provisioning key to KVM guests. Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Yang Zhong <yang.zhong@intel.com> Message-Id: <20210719112136.57018-14-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-09-30i386: Update SGX CPUID info according to hardware/KVM/user inputSean Christopherson6-1/+170
Expose SGX to the guest if and only if KVM is enabled and supports virtualization of SGX. While the majority of ENCLS can be emulated to some degree, because SGX uses a hardware-based root of trust, the attestation aspects of SGX cannot be emulated in software, i.e. ultimately emulation will fail as software cannot generate a valid quote/report. The complexity of partially emulating SGX in Qemu far outweighs the value added, e.g. an SGX specific simulator for userspace applications can emulate SGX for development and testing purposes. Note, access to the PROVISIONKEY is not yet advertised to the guest as KVM blocks access to the PROVISIONKEY by default and requires userspace to provide additional credentials (via ioctl()) to expose PROVISIONKEY. Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Yang Zhong <yang.zhong@intel.com> Message-Id: <20210719112136.57018-13-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-09-30i386: Add feature control MSR dependency when SGX is enabledSean Christopherson1-0/+5
SGX adds multiple flags to FEATURE_CONTROL to enable SGX and Flexible Launch Control. Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Yang Zhong <yang.zhong@intel.com> Message-Id: <20210719112136.57018-12-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-09-30i386: Add get/set/migrate support for SGX_LEPUBKEYHASH MSRsSean Christopherson4-1/+58
On real hardware, on systems that supports SGX Launch Control, those MSRs are initialized to digest of Intel's signing key; on systems that don't support SGX Launch Control, those MSRs are not available but hardware always uses digest of Intel's signing key in EINIT. KVM advertises SGX LC via CPUID if and only if the MSRs are writable. Unconditionally initialize those MSRs to digest of Intel's signing key when CPU is realized and reset to reflect the fact. This avoids potential bug in case kvm_arch_put_registers() is called before kvm_arch_get_registers() is called, in which case guest's virtual SGX_LEPUBKEYHASH MSRs will be set to 0, although KVM initializes those to digest of Intel's signing key by default, since KVM allows those MSRs to be updated by Qemu to support live migration. Save/restore the SGX Launch Enclave Public Key Hash MSRs if SGX Launch Control (LC) is exposed to the guest. Likewise, migrate the MSRs if they are writable by the guest. Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Kai Huang <kai.huang@intel.com> Signed-off-by: Yang Zhong <yang.zhong@intel.com> Message-Id: <20210719112136.57018-11-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-09-30i386: Add SGX CPUID leaf FEAT_SGX_12_1_EAXSean Christopherson2-0/+22
CPUID leaf 12_1_EAX is an Intel-defined feature bits leaf enumerating the platform's SGX capabilities that may be utilized by an enclave, e.g. whether or not an enclave can gain access to the provision key. Currently there are six capabilities: - INIT: set when the enclave has has been initialized by EINIT. Cannot be set by software, i.e. forced to zero in CPUID. - DEBUG: permits a debugger to read/write into the enclave. - MODE64BIT: the enclave runs in 64-bit mode - PROVISIONKEY: grants has access to the provision key - EINITTOKENKEY: grants access to the EINIT token key, i.e. the enclave can generate EINIT tokens - KSS: Key Separation and Sharing enabled for the enclave. Note that the entirety of CPUID.0x12.0x1, i.e. all registers, enumerates the allowed ATTRIBUTES (128 bits), but only bits 31:0 are directly exposed to the user (via FEAT_12_1_EAX). Bits 63:32 are currently all reserved and bits 127:64 correspond to the allowed XSAVE Feature Request Mask, which is calculated based on other CPU features, e.g. XSAVE, MPX, AVX, etc... and is not exposed to the user. Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Yang Zhong <yang.zhong@intel.com> Message-Id: <20210719112136.57018-10-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-09-30i386: Add SGX CPUID leaf FEAT_SGX_12_0_EBXSean Christopherson2-0/+22
CPUID leaf 12_0_EBX is an Intel-defined feature bits leaf enumerating the platform's SGX extended capabilities. Currently there is a single capabilitiy: - EXINFO: record information about #PFs and #GPs in the enclave's SSA Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Yang Zhong <yang.zhong@intel.com> Message-Id: <20210719112136.57018-9-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-09-30i386: Add SGX CPUID leaf FEAT_SGX_12_0_EAXSean Christopherson2-0/+21
CPUID leaf 12_0_EAX is an Intel-defined feature bits leaf enumerating the CPU's SGX capabilities, e.g. supported SGX instruction sets. Currently there are four enumerated capabilities: - SGX1 instruction set, i.e. "base" SGX - SGX2 instruction set for dynamic EPC management - ENCLV instruction set for VMM oversubscription of EPC - ENCLS-C instruction set for thread safe variants of ENCLS Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Yang Zhong <yang.zhong@intel.com> Message-Id: <20210719112136.57018-8-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-09-30i386: Add primary SGX CPUID and MSR definesSean Christopherson2-2/+14
Add CPUID defines for SGX and SGX Launch Control (LC), as well as defines for their associated FEATURE_CONTROL MSR bits. Define the Launch Enclave Public Key Hash MSRs (LE Hash MSRs), which exist when SGX LC is present (in CPUID), and are writable when SGX LC is enabled (in FEATURE_CONTROL). Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Yang Zhong <yang.zhong@intel.com> Message-Id: <20210719112136.57018-7-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-09-30vl: Add sgx compound properties to expose SGX EPC sections to guestSean Christopherson7-9/+94
Because SGX EPC is enumerated through CPUID, EPC "devices" need to be realized prior to realizing the vCPUs themselves, i.e. long before generic devices are parsed and realized. From a virtualization perspective, the CPUID aspect also means that EPC sections cannot be hotplugged without paravirtualizing the guest kernel (hardware does not support hotplugging as EPC sections must be locked down during pre-boot to provide EPC's security properties). So even though EPC sections could be realized through the generic -devices command, they need to be created much earlier for them to actually be usable by the guest. Place all EPC sections in a contiguous block, somewhat arbitrarily starting after RAM above 4g. Ensuring EPC is in a contiguous region simplifies calculations, e.g. device memory base, PCI hole, etc..., allows dynamic calculation of the total EPC size, e.g. exposing EPC to guests does not require -maxmem, and last but not least allows all of EPC to be enumerated in a single ACPI entry, which is expected by some kernels, e.g. Windows 7 and 8. The new compound properties command for sgx like below: ...... -object memory-backend-epc,id=mem1,size=28M,prealloc=on \ -object memory-backend-epc,id=mem2,size=10M \ -M sgx-epc.0.memdev=mem1,sgx-epc.1.memdev=mem2 Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Yang Zhong <yang.zhong@intel.com> Message-Id: <20210719112136.57018-6-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-09-30i386: Add 'sgx-epc' device to expose EPC sections to guestSean Christopherson3-0/+212
SGX EPC is enumerated through CPUID, i.e. EPC "devices" need to be realized prior to realizing the vCPUs themselves, which occurs long before generic devices are parsed and realized. Because of this, do not allow 'sgx-epc' devices to be instantiated after vCPUS have been created. The 'sgx-epc' device is essentially a placholder at this time, it will be fully implemented in a future patch along with a dedicated command to create 'sgx-epc' devices. Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Yang Zhong <yang.zhong@intel.com> Message-Id: <20210719112136.57018-5-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-09-30qom: Add memory-backend-epc ObjectOptions supportYang Zhong1-0/+19
Add the new 'memory-backend-epc' user creatable QOM object in the ObjectOptions to support SGX since v6.1, or the sgx backend object cannot bootup. Signed-off-by: Yang Zhong <yang.zhong@intel.com> Message-Id: <20210719112136.57018-4-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-09-30hostmem: Add hostmem-epc as a backend for SGX EPCSean Christopherson3-0/+111
EPC (Enclave Page Cahe) is a specialized type of memory used by Intel SGX (Software Guard Extensions). The SDM desribes EPC as: The Enclave Page Cache (EPC) is the secure storage used to store enclave pages when they are a part of an executing enclave. For an EPC page, hardware performs additional access control checks to restrict access to the page. After the current page access checks and translations are performed, the hardware checks that the EPC page is accessible to the program currently executing. Generally an EPC page is only accessed by the owner of the executing enclave or an instruction which is setting up an EPC page. Because of its unique requirements, Linux manages EPC separately from normal memory. Similar to memfd, the device /dev/sgx_vepc can be opened to obtain a file descriptor which can in turn be used to mmap() EPC memory. Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Yang Zhong <yang.zhong@intel.com> Message-Id: <20210719112136.57018-3-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-09-30Kconfig: Add CONFIG_SGX supportYang Zhong2-0/+6
Add new CONFIG_SGX for sgx support in the Qemu, and the Kconfig default enable sgx in the i386 platform. Signed-off-by: Yang Zhong <yang.zhong@intel.com> Message-Id: <20210719112136.57018-32-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-09-30memory: Add RAM_PROTECTED flag to skip IOMMU mappingsSean Christopherson4-2/+22
Add a new RAMBlock flag to denote "protected" memory, i.e. memory that looks and acts like RAM but is inaccessible via normal mechanisms, including DMA. Use the flag to skip protected memory regions when mapping RAM for DMA in VFIO. Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Yang Zhong <yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-09-30hw/arm: sabrelite: Connect SPI flash CS line to GPIO3_19Xuzhou Cheng1-1/+1
The Linux spi-imx driver does not work on QEMU. The reason is that the state of m25p80 loops in STATE_READING_DATA state after receiving RDSR command, the new command is ignored. Before sending a new command, CS line should be pulled high to make the state of m25p80 back to IDLE. Currently the SPI flash CS line is connected to the SPI controller, but on the real board, it's connected to GPIO3_19. This matches the ecspi1 device node in the board dts. ecspi1 node in imx6qdl-sabrelite.dtsi: &ecspi1 { cs-gpios = <&gpio3 19 GPIO_ACTIVE_LOW>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_ecspi1>; status = "okay"; flash: m25p80@0 { compatible = "sst,sst25vf016b", "jedec,spi-nor"; spi-max-frequency = <20000000>; reg = <0>; }; }; Should connect the SSI_GPIO_CS to GPIO3_19 when adding a spi-nor to spi1 on sabrelite machine. Verified this patch on Linux v5.14. Logs: # echo "01234567899876543210" > test # mtd_debug erase /dev/mtd0 0x0 0x1000 Erased 4096 bytes from address 0x00000000 in flash # mtd_debug write /dev/mtdblock0 0x0 20 test Copied 20 bytes from test to address 0x00000000 in flash # mtd_debug read /dev/mtdblock0 0x0 20 test_out Copied 20 bytes from address 0x00000000 in flash to test_out # cat test_out 01234567899876543210# Signed-off-by: Xuzhou Cheng <xuzhou.cheng@windriver.com> Reported-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20210927142825.491-1-xchengl.cn@gmail.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-09-30ide: Rename ide_bus_new() to ide_bus_init()Peter Maydell11-12/+12
The function ide_bus_new() does an in-place initialization. Rename it to ide_bus_init() to follow our _init vs _new convention. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Corey Minyard <cminyard@mvista.com> Reviewed-by: John Snow <jsnow@redhat.com> Acked-by: John Snow <jsnow@redhat.com> (Feel free to merge.) Message-id: 20210923121153.23754-7-peter.maydell@linaro.org
2021-09-30qbus: Rename qbus_create() to qbus_new()Peter Maydell14-14/+14
Rename the "allocate and return" qbus creation function to qbus_new(), to bring it into line with our _init vs _new convention. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Corey Minyard <cminyard@mvista.com> Message-id: 20210923121153.23754-6-peter.maydell@linaro.org
2021-09-30qbus: Rename qbus_create_inplace() to qbus_init()Peter Maydell32-61/+54
Rename qbus_create_inplace() to qbus_init(); this is more in line with our usual naming convention for functions that in-place initialize objects. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-id: 20210923121153.23754-5-peter.maydell@linaro.org
2021-09-30pci: Rename pci_root_bus_new_inplace() to pci_root_bus_init()Peter Maydell4-23/+23
Rename the pci_root_bus_new_inplace() function to pci_root_bus_init(); this brings the bus type in to line with a "_init for in-place init, _new for allocate-and-return" convention. To do this we need to rename the implementation-internal function that was using the pci_root_bus_init() name to pci_root_bus_internal_init(). Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-id: 20210923121153.23754-4-peter.maydell@linaro.org
2021-09-30ipack: Rename ipack_bus_new_inplace() to ipack_bus_init()Peter Maydell3-11/+11
Rename ipack_bus_new_inplace() to ipack_bus_init(), to bring it in to line with a "_init for in-place init, _new for allocate-and-return" convention. Drop the 'name' argument, because the only caller does not pass in a name. If a future caller does need to specify the bus name, we should create an ipack_bus_init_named() function at that point. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-id: 20210923121153.23754-3-peter.maydell@linaro.org
generated by cgit v1.1 at 2024-10-01 23:56:39 +0000