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 <ewanhai-oc@xxxxxxxxxxx> >>> Subject: Re: [PATCH v2 08/10] target/i386/kvm: reset AMD PMU registers >>> during VM reset >>> >>>>> [2] As mentioned in [1], QEMU always sets the vCPU's vendor to match the host's >>>>> vendor >>>>> when acceleration (KVM or HVF) is enabled. Therefore, if users want to emulate a >>>>> Zhaoxin CPU on an Intel host, the vendor must be set manually.Furthermore, >>>>> should we display a warning to users who enable both vPMU and KVM acceleration >>>>> but do not manually set the guest vendor when it differs from the host vendor? >>>> Maybe not? Sometimes I emulate AMD on Intel host, while vendor is still the >>>> default :) >>> Okay, handling this situation can be rather complex, so let's keep it >>> simple. I have added a dedicated function to capture the intended behavior >>> for potential future reference. >>> >>> Anyway, Thanks for taking Zhaoxin's situation into account, regardless. >>> >> Thanks for your code example!! >> >> Zhaoxin implements perfmon v2, so I think checking the vendor might be >> overly complicated. If a check is needed, it seems more reasonable to >> check the perfmon version rather than the vendor, similar to how avx10 >> version is checked in x86_cpu_filter_features(). >> >> I understand Ewan's concern is that if an Intel guest requires a higher >> perfmon version that the Zhaoxin host doesn't support, there could be >> issues (although I think this situation doesn't currently exist in KVM-QEMU, >> one reason is QEMU uses the pmu_version in 0xa queried from KVM directly, >> which means QEMU currently doesn't support custom pmu_version). > Yeah, that's exactly what I was concerned about. > Thanks for clearing that up! > > perfmon_version is a great idea --- I might add it as a property to the QEMU > vCPU template in the future, so it can adjust based on user input and host support. > Can't promise a timeline yet, but it's definitely something I'll keep in mind. I'm wondering if there are real user cases that sets a lower PMU version than host PMU version (live migration on different HW platforms?). In theory, the higher PMU version should fully back compatible with lower PMU version, but it's not always true in reality. One example is that the Anythread bit introduced in v3 is dropped in PMU v5 on Intel processors. This causes some difficulties to support PMU version 3/4 on host with PMU version 5+. Different PMU versions between host and guest could cause similar issues on other platforms. Currently KVM supported highest PMU version is v2. We plan to support higher PMU version for Intel processors on top of mediated vPMU. If guest sets pmu version to 3/4 on host with PMU version 5+, the Anythread bit would be marked as reserved,
