On 7/11/2025 6:21 PM, Zhao Liu wrote:
> Old Intel CPUs with CPUID level < 4, use CPUID 0x2 leaf (if available)
> to encode cache information.
>
> Introduce a cache model "legacy_intel_cpuid2_cache_info" for the CPUs
> with CPUID level < 4, based on legacy_l1d_cache, legacy_l1i_cache,
> legacy_l2_
On 6/26/2025 4:31 PM, Zhao Liu wrote:
> Host SapphireRapids CPU has 0x1f leaf by default, so that enable it for
> Guest CPU by default as well.
>
> Suggested-by: Igor Mammedov
> Signed-off-by: Zhao Liu
> ---
> Changes since RFC:
> * Rename the property to "x-force-cpuid-0x1f". (Igor)
> ---
>
On 6/26/2025 4:31 PM, Zhao Liu wrote:
> Host GraniteRapids CPU has 0x1f leaf by default, so that enable it for
> Guest CPU by default as well.
>
> Suggested-by: Igor Mammedov
> Signed-off-by: Zhao Liu
> ---
> Changes since RFC:
> * Rename the property to "x-force-cpuid-0x1f". (Igor)
> ---
> t
On 6/26/2025 4:31 PM, Zhao Liu wrote:
> Host SierraForest CPU has 0x1f leaf by default, so that enable it for
> Guest CPU by default as well.
>
> Suggested-by: Igor Mammedov
> Signed-off-by: Zhao Liu
> ---
> Changes since RFC:
> * Rename the property to "x-force-cpuid-0x1f". (Igor)
> ---
> ta
On 6/26/2025 4:31 PM, Zhao Liu wrote:
> From: Manish Mishra
>
> Add a "x-force-cpuid-0x1f" property so that CPU models can enable it and
> have 0x1f CPUID leaf natually as the Host CPU.
>
> The advantage is that when the CPU model's cache model is already
> consistent with the Host CPU, for exam
On 6/26/2025 4:31 PM, Zhao Liu wrote:
> Add the cache model to SapphireRapids (v4) to better emulate its
> environment.
>
> The cache model is based on SapphireRapids-SP (Scalable Performance):
>
> --- cache 0 ---
> cache type = data cache (1)
> cache lev
On 6/26/2025 4:30 PM, Zhao Liu wrote:
> Add the cache model to GraniteRapids (v3) to better emulate its
> environment.
>
> The cache model is based on GraniteRapids-SP (Scalable Performance):
>
> --- cache 0 ---
> cache type = data cache (1)
> cache level
On 6/26/2025 4:30 PM, Zhao Liu wrote:
> Add the cache model to SierraForest (v3) to better emulate its
> environment.
>
> The cache model is based on SierraForest-SP (Scalable Performance):
>
> --- cache 0 ---
> cache type = data cache (1)
> cache level
On 6/20/2025 5:27 PM, Zhao Liu wrote:
> At present, all cases using the cache model (CPUID 0x2, 0x4, 0x8005,
> 0x8006 and 0x801D leaves) have been verified to be able to
> select either cache_info_intel or cache_info_amd based on the vendor.
>
> Therefore, further merge cache_info_int
On 6/20/2025 5:27 PM, Zhao Liu wrote:
> As preparation for merging cache_info_cpuid4 and cache_info_amd in
> X86CPUState, set legacy cache model based on vendor in the CPUID
> 0x8005 leaf. For AMD CPU, select legacy AMD cache model (in
> cache_info_amd) as the default cache model like before,
On 6/20/2025 5:27 PM, Zhao Liu wrote:
> As preparation for merging cache_info_cpuid4 and cache_info_amd in
> X86CPUState, set legacy cache model based on vendor in the CPUID 0x4
> leaf. For AMD CPU, select legacy AMD cache model (in cache_info_amd) as
> the default cache model, otherwise, select
On 6/20/2025 5:27 PM, Zhao Liu wrote:
> As preparation for merging cache_info_cpuid4 and cache_info_amd in
> X86CPUState, set legacy cache model based on vendor in the CPUID 0x2
> leaf. For AMD CPU, select legacy AMD cache model (in cache_info_amd) as
> the default cache model, otherwise, select
On 6/20/2025 5:27 PM, Zhao Liu wrote:
> Based on legacy_l1d_cachei_amd, legacy_l1i_cache_amd, legacy_l2_cache_amd
> and legacy_l3_cache, build a complete legacy AMD cache model, which can
> clarify the purpose of these trivial legacy cache models, simplify the
> initialization of cache info in X8
On 6/20/2025 5:27 PM, Zhao Liu wrote:
> Based on legacy_l1d_cache, legacy_l1i_cache, legacy_l2_cache and
> legacy_l3_cache, build a complete legacy intel cache model, which can
> clarify the purpose of these trivial legacy cache models, simplify the
> initialization of cache info in X86CPUState,
On 6/20/2025 5:27 PM, Zhao Liu wrote:
> Per SDM, Intel supports CPUID[0x8006]. But only L2 information is
> encoded in ECX (note that L2 associativity field encodings rules
> consistent with AMD are used), all other fields are reserved.
>
> Therefore, make the following changes to CPUID[0x800
On 6/20/2025 5:27 PM, Zhao Liu wrote:
> Per SDM, 0x8005 leaf is reserved for Intel CPU, and its current
> "assert" check blocks adding new cache model for non-AMD CPUs.
>
> And please note, although Zhaoxin mostly follows Intel behavior,
> this leaf is an exception [1].
>
> So, add a compat p
On 6/20/2025 5:27 PM, Zhao Liu wrote:
> With the pre-defined cache model legacy_intel_cpuid2_cache_info,
> for X86CPUState there's no need to cache special cache information
> for CPUID 0x2 leaf.
>
> Drop the cache_info_cpuid2 field of X86CPUState and use the
> legacy_intel_cpuid2_cache_info dire
On 6/20/2025 5:27 PM, Zhao Liu wrote:
> Modern Intel CPUs use CPUID 0x4 leaf to describe cache information
> and leave space in 0x2 for prefetch and TLBs (even TLB has its own leaf
> CPUID 0x18).
>
> And 0x2 leaf provides a descriptor 0xFF to instruct software to check
> cache information in 0x4
On 7/3/2025 12:14 PM, Mi, Dapeng wrote:
> On 6/20/2025 5:27 PM, Zhao Liu wrote:
>> For a long time, the default cache models used in CPUID 0x2 and
>> 0x4 were inconsistent and had a FIXME note from Eduardo at commit
>> 5e891bf8fd50 ("target-i386: Use #defines in
On 6/20/2025 5:27 PM, Zhao Liu wrote:
> For a long time, the default cache models used in CPUID 0x2 and
> 0x4 were inconsistent and had a FIXME note from Eduardo at commit
> 5e891bf8fd50 ("target-i386: Use #defines instead of magic numbers for
> CPUID cache info"):
>
> "/*FIXME: CPUID leaf 2 desc
On 6/20/2025 5:27 PM, Zhao Liu wrote:
> Old Intel CPUs with CPUID level < 4, use CPUID 0x2 leaf (if available)
> to encode cache information.
>
> Introduce a cache model "legacy_intel_cpuid2_cache_info" for the CPUs
> with CPUID level < 4, based on legacy_l1d_cache, legacy_l1i_cache,
> legacy_l2_
On 6/20/2025 5:27 PM, Zhao Liu wrote:
> The legacy_l2_cache (2nd-level cache: 4 MByte, 16-way set associative,
> 64 byte line size) corresponds to descriptor 0x49, but at present
> cpuid2_cache_descriptors doesn't support descriptor 0x49 because it has
> multiple meanings.
>
> The 0x49 is necessa
On 6/20/2025 5:27 PM, Zhao Liu wrote:
> Refer to SDM vol.3 table 1-21, add the notes about the missing
> descriptor, and fix the typo and comment format.
>
> Signed-off-by: Zhao Liu
> ---
> target/i386/cpu.c | 31 ++-
> 1 file changed, 22 insertions(+), 9 deletions(-
On 6/24/2025 3:43 PM, Dongli Zhang wrote:
> PMU MSRs are set by QEMU only at levels >= KVM_PUT_RESET_STATE,
> excluding runtime. Therefore, updating these MSRs without stopping events
> should be acceptable.
>
> In addition, KVM creates kernel perf events with host mode excluded
> (exclude_host =
On 6/24/2025 3:43 PM, Dongli Zhang wrote:
> + uint32_t sel_base = MSR_K7_EVNTSEL0;
> + uint32_t ctr_base = MSR_K7_PERFCTR0;
> + /*
> + * The address of the next selector or counter register is
> + * obtained by incrementing the address of the current selector
> + * or counter register by one.
> +
On 6/24/2025 3:43 PM, Dongli Zhang wrote:
> When PMU is enabled in QEMU, there is a chance that PMU virtualization is
> completely disabled by the KVM module parameter kvm.enable_pmu=N.
>
> The kvm.enable_pmu parameter is introduced since Linux v5.17.
> Its permission is 0444. It does not change
On 6/24/2025 3:43 PM, Dongli Zhang wrote:
> The initialization of 'has_architectural_pmu_version',
> 'num_architectural_pmu_gp_counters', and
> 'num_architectural_pmu_fixed_counters' is unrelated to the process of
> building the CPUID.
>
> Extract them out of kvm_x86_build_cpuid().
>
> In additio
On 6/24/2025 3:43 PM, Dongli Zhang wrote:
> Although AMD PERFCORE and PerfMonV2 are removed when "-pmu" is configured,
> there is no way to fully disable KVM AMD PMU virtualization. Neither
> "-cpu host,-pmu" nor "-cpu EPYC" achieves this.
>
> As a result, the following message still appears in t
On 4/27/2025 4:54 PM, Zhao Liu wrote:
>> @@ -4212,7 +4213,8 @@ static const X86CPUDefinition builtin_x86_defs[] = {
>> VMX_VM_EXIT_LOAD_IA32_PERF_GLOBAL_CTRL |
>> VMX_VM_EXIT_ACK_INTR_ON_EXIT | VMX_VM_EXIT_SAVE_IA32_PAT |
>> VMX_VM_EXIT_LOAD_IA32_PAT | VMX_V
On 4/9/2025 4:26 PM, Zhao Liu wrote:
> KVM_SET_PMU_EVENT_FILTER of x86 KVM allows user to configure x86 fixed
> function counters by a bitmap.
>
> Add the support of x86-fixed-counter in kvm-pmu-filter object and handle
> this in i386 kvm codes.
>
> Signed-off-by: Zhao Liu
> Tested-by: Yi Lai
>
On 4/7/2025 5:33 PM, Ewan Hai wrote:
>
> On 4/7/25 4:51 PM, Zhao Liu wrote:
>
>> On Tue, Apr 01, 2025 at 11:35:49AM +0800, Ewan Hai wrote:
>>> Date: Tue, 1 Apr 2025 11:35:49 +0800
>>> From: Ewan Hai
>>> Subject: Re: [PATCH v2 08/10] target/i386/kvm: reset AMD PMU registers
>>> during VM reset
On 3/27/2025 10:15 AM, Mingwei Zhang wrote:
> On Wed, Mar 26, 2025 at 5:44 PM Mi, Dapeng wrote:
>>
>> On 3/26/2025 2:46 PM, Dongli Zhang wrote:
>>> Hi Dapeng,
>>>
>>> PATCH 1-4 from the below patchset are already reviewed. (PATCH 5-10 are for
&
On 3/26/2025 2:46 PM, Dongli Zhang wrote:
> Hi Dapeng,
>
> PATCH 1-4 from the below patchset are already reviewed. (PATCH 5-10 are for
> PMU
> registers reset).
>
> https://lore.kernel.org/all/20250302220112.17653-1-dongli.zh...@oracle.com/
>
> They require only trivial modification. i.e.:
>
> h
On 3/6/2025 3:00 AM, dongli.zh...@oracle.com wrote:
> Hi Dapeng,
>
> On 3/4/25 11:35 PM, Mi, Dapeng wrote:
>> On 3/3/2025 6:00 AM, Dongli Zhang wrote:
>>> The kvm_put_msrs() sets the MSRs using KVM_SET_MSRS. The x86 KVM processes
>>> these MSRs one by one in a
On 3/3/2025 6:00 AM, Dongli Zhang wrote:
> The initialization of 'has_architectural_pmu_version',
> 'num_architectural_pmu_gp_counters', and
> 'num_architectural_pmu_fixed_counters' is unrelated to the process of
> building the CPUID.
>
> Extract them out of kvm_x86_build_cpuid().
>
> No function
On 3/3/2025 6:00 AM, Dongli Zhang wrote:
> The kvm_put_msrs() sets the MSRs using KVM_SET_MSRS. The x86 KVM processes
> these MSRs one by one in a loop, only saving the config and triggering the
> KVM_REQ_PMU request. This approach does not immediately stop the event
> before updating PMC.
>
> In
On 3/3/2025 6:00 AM, Dongli Zhang wrote:
> QEMU uses the kvm_get_msrs() function to save Intel PMU registers from KVM
> and kvm_put_msrs() to restore them to KVM. However, there is no support for
> AMD PMU registers. Currently, has_pmu_version and num_pmu_gp_counters are
> initialized based on cp
On 3/3/2025 6:00 AM, Dongli Zhang wrote:
> AMD does not have what is commonly referred to as an architectural PMU.
> Therefore, we need to rename the following variables to be applicable for
> both Intel and AMD:
>
> - has_architectural_pmu_version
> - num_architectural_pmu_gp_counters
> - num_ar
On 2/10/2025 4:12 AM, dongli.zh...@oracle.com wrote:
> Hi Dapeng,
>
> On 2/7/25 1:52 AM, Mi, Dapeng wrote:
>> On 11/21/2024 6:06 PM, Mi, Dapeng wrote:
>>> On 11/8/2024 7:44 AM, dongli.zh...@oracle.com wrote:
>>>> Hi Zhao,
>>>>
>>>>
>
On 11/21/2024 6:06 PM, Mi, Dapeng wrote:
> On 11/8/2024 7:44 AM, dongli.zh...@oracle.com wrote:
>> Hi Zhao,
>>
>>
>> On 11/6/24 11:52 PM, Zhao Liu wrote:
>>> (+Dapang & Zide)
>>>
>>> Hi Dongli,
>>>
>>> On Mon, Nov 04,
On 11/8/2024 7:44 AM, dongli.zh...@oracle.com wrote:
> Hi Zhao,
>
>
> On 11/6/24 11:52 PM, Zhao Liu wrote:
>> (+Dapang & Zide)
>>
>> Hi Dongli,
>>
>> On Mon, Nov 04, 2024 at 01:40:17AM -0800, Dongli Zhang wrote:
>>> Date: Mon, 4 Nov 2024 01:40:17 -0800
>>> From: Dongli Zhang
>>> Subject: [PATCH
On 7/19/2024 4:40 PM, Zhao Liu wrote:
> Hi Dapeng,
>
> On Thu, Jul 18, 2024 at 01:28:25PM +0800, Mi, Dapeng wrote:
>
> [snip]
>
>>> +case KVM_PMU_EVENT_FMT_X86_DEFAULT: {
>>> +uint64_t select, umask;
>>> +
>>> +
On 7/10/2024 12:51 PM, Zhao Liu wrote:
> The select&umask is the common way for x86 to identify the PMU event,
> so support this way as the "x86-default" format in kvm-pmu-filter
> object.
>
> Signed-off-by: Zhao Liu
> ---
> accel/kvm/kvm-pmu.c | 62
On 7/10/2024 12:51 PM, Zhao Liu wrote:
> Hi QEMU maintainers, arm and PMU folks,
>
> I picked up Shaoqing's previous work [1] on the KVM PMU filter for arm,
> and now is trying to support this feature for x86 with a JSON-compatible
> API.
>
> While arm and x86 use different KVM ioctls to configur
On 2/27/2024 6:32 PM, Zhao Liu wrote:
From: Zhao Liu
Add "modules" parameter parsing support in -smp.
Suggested-by: Xiaoyao Li
Tested-by: Yongwei Ma
Signed-off-by: Zhao Liu
---
Changes since v8:
* Add module description in qemu_smp_opts.
Changes since v7:
* New commit to introduce mo
45 matches
Mail list logo
