Revision tags: v8.2.4 |
|
#
9f07e47a |
| 08-May-2024 |
Paolo Bonzini <pbonzini@redhat.com> |
target/i386: remove PCOMMIT from TCG, deprecate property
The PCOMMIT instruction was never included in any physical processor. TCG implements it as a no-op instruction, but its utility is debatable
target/i386: remove PCOMMIT from TCG, deprecate property
The PCOMMIT instruction was never included in any physical processor. TCG implements it as a no-op instruction, but its utility is debatable to say the least. Drop it from the decoder since it is only available with "-cpu max", which does not guarantee migration compatibility across versions, and deprecate the property just in case someone is using it as "pcommit=off".
Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
#
b776569a |
| 03-May-2024 |
Babu Moger <babu.moger@amd.com> |
target/i386: Fix CPUID encoding of Fn8000001E_ECX
Observed the following failure while booting the SEV-SNP guest and the guest fails to boot with the smp parameters: "-smp 192,sockets=1,dies=12,core
target/i386: Fix CPUID encoding of Fn8000001E_ECX
Observed the following failure while booting the SEV-SNP guest and the guest fails to boot with the smp parameters: "-smp 192,sockets=1,dies=12,cores=8,threads=2".
qemu-system-x86_64: sev_snp_launch_update: SNP_LAUNCH_UPDATE ret=-5 fw_error=22 'Invalid parameter' qemu-system-x86_64: SEV-SNP: CPUID validation failed for function 0x8000001e, index: 0x0. provided: eax:0x00000000, ebx: 0x00000100, ecx: 0x00000b00, edx: 0x00000000 expected: eax:0x00000000, ebx: 0x00000100, ecx: 0x00000300, edx: 0x00000000 qemu-system-x86_64: SEV-SNP: failed update CPUID page
Reason for the failure is due to overflowing of bits used for "Node per processor" in CPUID Fn8000001E_ECX. This field's width is 3 bits wide and can hold maximum value 0x7. With dies=12 (0xB), it overflows and spills over into the reserved bits. In the case of SEV-SNP, this causes CPUID enforcement failure and guest fails to boot.
The PPR documentation for CPUID_Fn8000001E_ECX [Node Identifiers] ================================================================= Bits Description 31:11 Reserved.
10:8 NodesPerProcessor: Node per processor. Read-only. ValidValues: Value Description 0h 1 node per processor. 7h-1h Reserved.
7:0 NodeId: Node ID. Read-only. Reset: Fixed,XXh. =================================================================
As in the spec, the valid value for "node per processor" is 0 and rest are reserved.
Looking back at the history of decoding of CPUID_Fn8000001E_ECX, noticed that there were cases where "node per processor" can be more than 1. It is valid only for pre-F17h (pre-EPYC) architectures. For EPYC or later CPUs, the linux kernel does not use this information to build the L3 topology.
Also noted that the CPUID Function 0x8000001E_ECX is available only when TOPOEXT feature is enabled. This feature is enabled only for EPYC(F17h) or later processors. So, previous generation of processors do not not enumerate 0x8000001E_ECX leaf.
There could be some corner cases where the older guests could enable the TOPOEXT feature by running with -cpu host, in which case legacy guests might notice the topology change. To address those cases introduced a new CPU property "legacy-multi-node". It will be true for older machine types to maintain compatibility. By default, it will be false, so new decoding will be used going forward.
The documentation is taken from Preliminary Processor Programming Reference (PPR) for AMD Family 19h Model 11h, Revision B1 Processors 55901 Rev 0.25 - Oct 6, 2022.
Cc: qemu-stable@nongnu.org Fixes: 31ada106d891 ("Simplify CPUID_8000_001E for AMD") Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537 Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Signed-off-by: Babu Moger <babu.moger@amd.com> Message-ID: <0ee4b0a8293188a53970a2b0e4f4ef713425055e.1714757834.git.babu.moger@amd.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
Revision tags: v8.2.3, v7.2.11, v9.0.0, v9.0.0-rc4, v9.0.0-rc3, v9.0.0-rc2, v9.0.0-rc1, v9.0.0-rc0, v8.2.2, v7.2.10, v8.2.1, v8.1.5, v7.2.9, v8.1.4, v7.2.8, v8.2.0, v8.2.0-rc4, v8.2.0-rc3 |
|
#
e92dd332 |
| 05-Dec-2023 |
Philippe Mathieu-Daudé <philmd@linaro.org> |
target: Define TCG_GUEST_DEFAULT_MO in 'cpu-param.h'
accel/tcg/ files requires the following definitions:
- TARGET_LONG_BITS - TARGET_PAGE_BITS - TARGET_PHYS_ADDR_SPACE_BITS - TCG_GUEST_DEF
target: Define TCG_GUEST_DEFAULT_MO in 'cpu-param.h'
accel/tcg/ files requires the following definitions:
- TARGET_LONG_BITS - TARGET_PAGE_BITS - TARGET_PHYS_ADDR_SPACE_BITS - TCG_GUEST_DEFAULT_MO
The first 3 are defined in "cpu-param.h". The last one in "cpu.h", with a bunch of definitions irrelevant for TCG. By moving the TCG_GUEST_DEFAULT_MO definition to "cpu-param.h", we can simplify various accel/tcg includes.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Acked-by: Nicholas Piggin <npiggin@gmail.com> Message-Id: <20231211212003.21686-4-philmd@linaro.org>
show more ...
|
Revision tags: v8.2.3, v7.2.11, v9.0.0, v9.0.0-rc4, v9.0.0-rc3, v9.0.0-rc2, v9.0.0-rc1, v9.0.0-rc0, v8.2.2, v7.2.10, v8.2.1, v8.1.5, v7.2.9, v8.1.4, v7.2.8, v8.2.0, v8.2.0-rc4, v8.2.0-rc3 |
|
#
e92dd332 |
| 05-Dec-2023 |
Philippe Mathieu-Daudé <philmd@linaro.org> |
target: Define TCG_GUEST_DEFAULT_MO in 'cpu-param.h'
accel/tcg/ files requires the following definitions:
- TARGET_LONG_BITS - TARGET_PAGE_BITS - TARGET_PHYS_ADDR_SPACE_BITS - TCG_GUEST_DEF
target: Define TCG_GUEST_DEFAULT_MO in 'cpu-param.h'
accel/tcg/ files requires the following definitions:
- TARGET_LONG_BITS - TARGET_PAGE_BITS - TARGET_PHYS_ADDR_SPACE_BITS - TCG_GUEST_DEFAULT_MO
The first 3 are defined in "cpu-param.h". The last one in "cpu.h", with a bunch of definitions irrelevant for TCG. By moving the TCG_GUEST_DEFAULT_MO definition to "cpu-param.h", we can simplify various accel/tcg includes.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Acked-by: Nicholas Piggin <npiggin@gmail.com> Message-Id: <20231211212003.21686-4-philmd@linaro.org>
show more ...
|
#
513ba32d |
| 18-Mar-2024 |
Gerd Hoffmann <kraxel@redhat.com> |
target/i386: add guest-phys-bits cpu property
Allows to set guest-phys-bits (cpuid leaf 80000008, eax[23:16]) via -cpu $model,guest-phys-bits=$nr.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> M
target/i386: add guest-phys-bits cpu property
Allows to set guest-phys-bits (cpuid leaf 80000008, eax[23:16]) via -cpu $model,guest-phys-bits=$nr.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-ID: <20240318155336.156197-3-kraxel@redhat.com> Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
#
513ba32d |
| 18-Mar-2024 |
Gerd Hoffmann <kraxel@redhat.com> |
target/i386: add guest-phys-bits cpu property
Allows to set guest-phys-bits (cpuid leaf 80000008, eax[23:16]) via -cpu $model,guest-phys-bits=$nr.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> M
target/i386: add guest-phys-bits cpu property
Allows to set guest-phys-bits (cpuid leaf 80000008, eax[23:16]) via -cpu $model,guest-phys-bits=$nr.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-ID: <20240318155336.156197-3-kraxel@redhat.com> Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
#
2cc68629 |
| 11-Mar-2024 |
Paolo Bonzini <pbonzini@redhat.com> |
target/i386: fix direction of "32-bit MMU" test
The low bit of MMU indices for x86 TCG indicates whether the processor is in 32-bit mode and therefore linear addresses have to be masked to 32 bits.
target/i386: fix direction of "32-bit MMU" test
The low bit of MMU indices for x86 TCG indicates whether the processor is in 32-bit mode and therefore linear addresses have to be masked to 32 bits. However, the index was computed incorrectly, leading to possible conflicts in the TLB for any address above 4G.
Analyzed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Fixes: b1661801c18 ("target/i386: Fix physical address truncation", 2024-02-28) Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2206 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
#
b1661801 |
| 22-Dec-2023 |
Paolo Bonzini <pbonzini@redhat.com> |
target/i386: Fix physical address truncation
The address translation logic in get_physical_address() will currently truncate physical addresses to 32 bits unless long mode is enabled. This is incorr
target/i386: Fix physical address truncation
The address translation logic in get_physical_address() will currently truncate physical addresses to 32 bits unless long mode is enabled. This is incorrect when using physical address extensions (PAE) outside of long mode, with the result that a 32-bit operating system using PAE to access memory above 4G will experience undefined behaviour.
The truncation code was originally introduced in commit 33dfdb5 ("x86: only allow real mode to access 32bit without LMA"), where it applied only to translations performed while paging is disabled (and so cannot affect guests using PAE).
Commit 9828198 ("target/i386: Add MMU_PHYS_IDX and MMU_NESTED_IDX") rearranged the code such that the truncation also applied to the use of MMU_PHYS_IDX and MMU_NESTED_IDX. Commit 4a1e9d4 ("target/i386: Use atomic operations for pte updates") brought this truncation into scope for page table entry accesses, and is the first commit for which a Windows 10 32-bit guest will reliably fail to boot if memory above 4G is present.
The truncation code however is not completely redundant. Even though the maximum address size for any executed instruction is 32 bits, helpers for operations such as BOUND, FSAVE or XSAVE may ask get_physical_address() to translate an address outside of the 32-bit range, if invoked with an argument that is close to the 4G boundary. Likewise for processor accesses, for example TSS or IDT accesses, when EFER.LMA==0.
So, move the address truncation in get_physical_address() so that it applies to 32-bit MMU indexes, but not to MMU_PHYS_IDX and MMU_NESTED_IDX.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2040 Fixes: 4a1e9d4d11c ("target/i386: Use atomic operations for pte updates", 2022-10-18) Cc: qemu-stable@nongnu.org Co-developed-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
#
90f64153 |
| 02-Jan-2024 |
Paolo Bonzini <pbonzini@redhat.com> |
target/i386: use separate MMU indexes for 32-bit accesses
Accesses from a 32-bit environment (32-bit code segment for instruction accesses, EFER.LMA==0 for processor accesses) have to mask away the
target/i386: use separate MMU indexes for 32-bit accesses
Accesses from a 32-bit environment (32-bit code segment for instruction accesses, EFER.LMA==0 for processor accesses) have to mask away the upper 32 bits of the address. While a bit wasteful, the easiest way to do so is to use separate MMU indexes. These days, QEMU anyway is compiled with a fixed value for NB_MMU_MODES. Split MMU_USER_IDX, MMU_KSMAP_IDX and MMU_KNOSMAP_IDX in two.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
#
5f97afe2 |
| 02-Jan-2024 |
Paolo Bonzini <pbonzini@redhat.com> |
target/i386: introduce function to query MMU indices
Remove knowledge of specific MMU indexes (other than MMU_NESTED_IDX and MMU_PHYS_IDX) from mmu_translate(). This will make it possible to split
target/i386: introduce function to query MMU indices
Remove knowledge of specific MMU indexes (other than MMU_NESTED_IDX and MMU_PHYS_IDX) from mmu_translate(). This will make it possible to split 32-bit and 64-bit MMU indexes.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
#
774204cf |
| 11-Jan-2024 |
Bui Quang Minh <minhquangbui99@gmail.com> |
apic, i386/tcg: add x2apic transitions
This commit adds support for x2APIC transitions when writing to MSR_IA32_APICBASE register and finally adds CPUID_EXT_X2APIC to TCG_EXT_FEATURES.
The set_base
apic, i386/tcg: add x2apic transitions
This commit adds support for x2APIC transitions when writing to MSR_IA32_APICBASE register and finally adds CPUID_EXT_X2APIC to TCG_EXT_FEATURES.
The set_base in APICCommonClass now returns an integer to indicate error in execution. apic_set_base return -1 on invalid APIC state transition, accelerator can use this to raise appropriate exception.
Signed-off-by: Bui Quang Minh <minhquangbui99@gmail.com> Message-Id: <20240111154404.5333-4-minhquangbui99@gmail.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
#
b5ee0468 |
| 11-Jan-2024 |
Bui Quang Minh <minhquangbui99@gmail.com> |
apic: add support for x2APIC mode
This commit extends the APIC ID to 32-bit long and remove the 255 max APIC ID limit in userspace APIC. The array that manages local APICs is now dynamically allocat
apic: add support for x2APIC mode
This commit extends the APIC ID to 32-bit long and remove the 255 max APIC ID limit in userspace APIC. The array that manages local APICs is now dynamically allocated based on the max APIC ID of created x86 machine. Also, new x2APIC IPI destination determination scheme, self IPI and x2APIC mode register access are supported.
Signed-off-by: Bui Quang Minh <minhquangbui99@gmail.com> Message-Id: <20240111154404.5333-3-minhquangbui99@gmail.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
#
b2101358 |
| 11-Jan-2024 |
Bui Quang Minh <minhquangbui99@gmail.com> |
i386/tcg: implement x2APIC registers MSR access
This commit creates apic_register_read/write which are used by both apic_mem_read/write for MMIO access and apic_msr_read/write for MSR access.
The a
i386/tcg: implement x2APIC registers MSR access
This commit creates apic_register_read/write which are used by both apic_mem_read/write for MMIO access and apic_msr_read/write for MSR access.
The apic_msr_read/write returns -1 on error, accelerator can use this to raise the appropriate exception.
Signed-off-by: Bui Quang Minh <minhquangbui99@gmail.com> Message-Id: <20240111154404.5333-2-minhquangbui99@gmail.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
#
a120d320 |
| 29-Jan-2024 |
Richard Henderson <richard.henderson@linaro.org> |
include/exec: Implement cpu_mmu_index generically
For user-only mode, use MMU_USER_IDX. For system mode, use CPUClass.mmu_index.
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-b
include/exec: Implement cpu_mmu_index generically
For user-only mode, use MMU_USER_IDX. For system mode, use CPUClass.mmu_index.
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
show more ...
|
#
ace0c5fe |
| 28-Jan-2024 |
Richard Henderson <richard.henderson@linaro.org> |
target/i386: Populate CPUClass.mmu_index
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
|
Revision tags: v8.2.0-rc2, v8.2.0-rc1, v7.2.7, v8.1.3, v8.2.0-rc0, v8.1.2 |
|
#
e7bbb7cb |
| 11-Oct-2023 |
Paolo Bonzini <pbonzini@redhat.com> |
target/i386: introduce flags writeback mechanism
ALU instructions can write to both memory and flags. If the CC_SRC* and CC_DST locations have been written already when a memory access causes a fau
target/i386: introduce flags writeback mechanism
ALU instructions can write to both memory and flags. If the CC_SRC* and CC_DST locations have been written already when a memory access causes a fault, the value in CC_SRC* and CC_DST might be interpreted with the wrong CC_OP (the one that is in effect before the instruction.
Besides just using the wrong result for the flags, something like subtracting -1 can have disastrous effects if the current CC_OP is CC_OP_EFLAGS: this is because QEMU does not expect bits outside the ALU flags to be set in CC_SRC, and env->eflags can end up set to all-ones. In the case of the attached testcase, this sets IOPL to 3 and would cause an assertion failure if SUB is moved to the new decoder.
This mechanism is not really needed for BMI instructions, which can only write to a register, but put it to use anyway for cleanliness. In the case of BZHI, the code has to be modified slightly to ensure that decode->cc_src is written, otherwise the new assertions trigger.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
#
2455e9cf |
| 25-Oct-2023 |
Paolo Bonzini <pbonzini@redhat.com> |
target/i386: clean up cpu_cc_compute_all
cpu_cc_compute_all() has an argument that is always equal to CC_OP for historical reasons (dating back to commit a7812ae4123, "TCG variable type checking.",
target/i386: clean up cpu_cc_compute_all
cpu_cc_compute_all() has an argument that is always equal to CC_OP for historical reasons (dating back to commit a7812ae4123, "TCG variable type checking.", 2008-11-17, which added the argument to helper_cc_compute_all). It does not make sense for the argument to have any other value, so remove it and clean up some lines that are not too long anymore.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
#
b5e0d5d2 |
| 12-Dec-2023 |
Richard Henderson <richard.henderson@linaro.org> |
target/i386: Fix 32-bit wrapping of pc/eip computation
In 32-bit mode, pc = eip + cs_base is also 32-bit, and must wrap. Failure to do so results in incorrect memory exceptions to the guest. Before
target/i386: Fix 32-bit wrapping of pc/eip computation
In 32-bit mode, pc = eip + cs_base is also 32-bit, and must wrap. Failure to do so results in incorrect memory exceptions to the guest. Before 732d548732ed, this was implicitly done via truncation to target_ulong but only in qemu-system-i386, not qemu-system-x86_64.
To fix this, we must add conditional zero-extensions. Since we have to test for 32 vs 64-bit anyway, note that cs_base is always zero in 64-bit mode.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2022 Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20231212172510.103305-1-richard.henderson@linaro.org>
show more ...
|
#
aa1878fb |
| 24-Oct-2023 |
Zhao Liu <zhao1.liu@intel.com> |
hw/cpu: Update the comments of nr_cores and nr_dies
In the nr_threads' comment, specify it represents the number of threads in the "core" to avoid confusion.
Also add comment for nr_dies in CPUX86S
hw/cpu: Update the comments of nr_cores and nr_dies
In the nr_threads' comment, specify it represents the number of threads in the "core" to avoid confusion.
Also add comment for nr_dies in CPUX86State.
Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Tested-by: Babu Moger <babu.moger@amd.com> Tested-by: Yongwei Ma <yongwei.ma@intel.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20231024090323.1859210-5-zhao1.liu@linux.intel.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
show more ...
|
#
9348028e |
| 13-Oct-2023 |
Philippe Mathieu-Daudé <philmd@linaro.org> |
target: Move ArchCPUClass definition to 'cpu.h'
The OBJECT_DECLARE_CPU_TYPE() macro forward-declares each ArchCPUClass type. These forward declarations are sufficient for code in hw/ to use the QOM
target: Move ArchCPUClass definition to 'cpu.h'
The OBJECT_DECLARE_CPU_TYPE() macro forward-declares each ArchCPUClass type. These forward declarations are sufficient for code in hw/ to use the QOM definitions. No need to expose these structure definitions. Keep each local to their target/ by moving them to the corresponding "cpu.h" header.
Suggested-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20231013140116.255-13-philmd@linaro.org>
show more ...
|
#
2d56be5a |
| 06-Oct-2023 |
Philippe Mathieu-Daudé <philmd@linaro.org> |
target: Declare FOO_CPU_TYPE_NAME/SUFFIX in 'cpu-qom.h'
Hegerogeneous code needs access to the FOO_CPU_TYPE_NAME() macro to resolve target CPU types. Move the declaration (along with the required FO
target: Declare FOO_CPU_TYPE_NAME/SUFFIX in 'cpu-qom.h'
Hegerogeneous code needs access to the FOO_CPU_TYPE_NAME() macro to resolve target CPU types. Move the declaration (along with the required FOO_CPU_TYPE_SUFFIX) to "cpu-qom.h".
"target/foo/cpu-qom.h" is supposed to be target agnostic (include-able by any target). Add such mention in the header.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Acked-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20231013140116.255-7-philmd@linaro.org>
show more ...
|
#
6ee45fac |
| 13-Oct-2023 |
Philippe Mathieu-Daudé <philmd@linaro.org> |
target: Unify QOM style
Enforce the style described by commit 067109a11c ("docs/devel: mention the spacing requirement for QOM"):
The first declaration of a storage or class structure should al
target: Unify QOM style
Enforce the style described by commit 067109a11c ("docs/devel: mention the spacing requirement for QOM"):
The first declaration of a storage or class structure should always be the parent and leave a visual space between that declaration and the new code. It is also useful to separate backing for properties (options driven by the user) and internal state to make navigation easier.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Message-Id: <20231013140116.255-2-philmd@linaro.org>
show more ...
|
#
aa1878fb |
| 24-Oct-2023 |
Zhao Liu <zhao1.liu@intel.com> |
hw/cpu: Update the comments of nr_cores and nr_dies
In the nr_threads' comment, specify it represents the number of threads in the "core" to avoid confusion.
Also add comment for nr_dies in CPUX86S
hw/cpu: Update the comments of nr_cores and nr_dies
In the nr_threads' comment, specify it represents the number of threads in the "core" to avoid confusion.
Also add comment for nr_dies in CPUX86State.
Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Tested-by: Babu Moger <babu.moger@amd.com> Tested-by: Yongwei Ma <yongwei.ma@intel.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20231024090323.1859210-5-zhao1.liu@linux.intel.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
show more ...
|
#
9348028e |
| 13-Oct-2023 |
Philippe Mathieu-Daudé <philmd@linaro.org> |
target: Move ArchCPUClass definition to 'cpu.h'
The OBJECT_DECLARE_CPU_TYPE() macro forward-declares each ArchCPUClass type. These forward declarations are sufficient for code in hw/ to use the QOM
target: Move ArchCPUClass definition to 'cpu.h'
The OBJECT_DECLARE_CPU_TYPE() macro forward-declares each ArchCPUClass type. These forward declarations are sufficient for code in hw/ to use the QOM definitions. No need to expose these structure definitions. Keep each local to their target/ by moving them to the corresponding "cpu.h" header.
Suggested-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20231013140116.255-13-philmd@linaro.org>
show more ...
|
#
2d56be5a |
| 06-Oct-2023 |
Philippe Mathieu-Daudé <philmd@linaro.org> |
target: Declare FOO_CPU_TYPE_NAME/SUFFIX in 'cpu-qom.h'
Hegerogeneous code needs access to the FOO_CPU_TYPE_NAME() macro to resolve target CPU types. Move the declaration (along with the required FO
target: Declare FOO_CPU_TYPE_NAME/SUFFIX in 'cpu-qom.h'
Hegerogeneous code needs access to the FOO_CPU_TYPE_NAME() macro to resolve target CPU types. Move the declaration (along with the required FOO_CPU_TYPE_SUFFIX) to "cpu-qom.h".
"target/foo/cpu-qom.h" is supposed to be target agnostic (include-able by any target). Add such mention in the header.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Acked-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20231013140116.255-7-philmd@linaro.org>
show more ...
|