On Thu, Oct 13, 2016 at 05:19:37PM +0100, Peter Maydell wrote: > On 4 October 2016 at 22:38, Wei Huang <w...@redhat.com> wrote: > > This patchset adds a pmu=[on/off] option to enable/disable vPMU support > > for guest VM. There are several reasons to justify this option. First, > > vPMU can be problematic for cross-migration between different SoC as perf > > counters are architecture-dependent. It is more flexible to have an option > > to turn it on/off. Secondly this option matches the "pmu" option as > > supported in libvirt. To make sure backward compatible, a PMU-related > > property is added to mach-virt machine types. > > > > The following are testing results with this patchset. Other combinations > > should have similar results: > > CONFIG (qemu-system-aarch64) vPMU WARNING > > -M virt-2.8/virt,accel=kvm -cpu host NO NO > > What's the rationale for defaulting to no-pmu? Other cpu features > we have tend to default to present unless you ask not to have them.
The feature needs to be managed in order for users to be able to trade-off features exposed vs. migratability. If the lack of an explicit pmu=on means either you get a PMU, when it's available, or you don't, when it's not, then managing the feature becomes more difficult. Also, libvirt already manages this cpu property for x86, and there it defaults off. Maybe we should revisit the other features that default on, but may be turned off, to make sure they make sense. Can you point them out? I took a quick look, but it appears the cpu property defaults are all pretty much determined by vms->secure, which defaults to false. > > > -M virt-2.8/virt,accel=kvm -cpu host,pmu=off NO NO > > -M virt-2.8/virt,accel=kvm -cpu host,pmu=on YES NO > > -M virt-2.7,accel=kvm -cpu host YES NO > > -M virt-2.7,accel=kvm -cpu host,pmu=off NO NO > > -M virt-2.7,accel=kvm -cpu host,pmu=on YES NO > > in virt-2.7 you always got a pmu regardless, so why does pmu=off here give > you no pmu? Hmm, I think you're right that the property should just be a nop, or even invalid (causing an error) for 2.7 and down. > > > -M virt-2.6,accel=kvm -cpu host NO NO > > -M virt-2.6,accel=kvm -cpu host,pmu=off NO NO > > -M virt-2.6,accel=kvm -cpu host,pmu=on YES NO > > > > -M virt-2.8/virt,accel=tcg -cpu cortex-a57 NO NO > > -M virt-2.8/virt,accel=tcg -cpu cortex-a57,pmu=off NO NO > > -M virt-2.8/virt,accel=tcg -cpu cortex-a57,pmu=on NO "No KVM" > > -M virt-2.7,accel=tcg -cpu cortex-a57 NO NO > > -M virt-2.7,accel=tcg -cpu cortex-a57,pmu=off NO NO > > -M virt-2.7,accel=tcg -cpu cortex-a57,pmu=on NO "No KVM" > > -M virt-2.6,accel=tcg -cpu cortex-a57 NO NO > > -M virt-2.6,accel=tcg -cpu cortex-a57,pmu=off NO NO > > -M virt-2.6,accel=tcg -cpu cortex-a57,pmu=on NO "No KVM" > > This patchset doesn't actually change whether the pmu is present > or not under TCG so this is all a little bit odd. The goal here is to allow the property on the command line, i.e. not error and fail, when using tcg. Otherwise more than just s/kvm/tcg/ would be required when switching, and accel=kvm:tcg wouldn't work either. > > > -M virt-2.8/virt,accel=tcg -cpu cortex-a15 NO NO > > -M virt-2.8/virt,accel=tcg -cpu cortex-a15,pmu=off NO "No PMU > > property" > > -M virt-2.8/virt,accel=tcg -cpu cortex-a15,pmu=on NO "No PMU > > property" > > -M virt-2.7,accel=tcg -cpu cortex-a15 NO NO > > -M virt-2.7,accel=tcg -cpu cortex-a15,pmu=off NO "No PMU > > property" > > -M virt-2.7,accel=tcg -cpu cortex-a15,pmu=on NO "No PMU > > property" > > -M virt-2.6,accel=tcg -cpu cortex-a15 NO NO > > -M virt-2.6,accel=tcg -cpu cortex-a15,pmu=off NO "No PMU > > property" > > -M virt-2.6,accel=tcg -cpu cortex-a15,pmu=on NO "No PMU > > property" > > > > * "NO KVM" msg > > warning: pmu can't be enabled without KVM acceleration > > * "No PMU property" msg > > can't apply global cortex-a15-arm-cpu.pmu=off: Property '.pmu' not found > > I'm really not a fan of the tristate has_pmu, so I'm hoping > there's a setup which lets us avoid it... Probably keeping PMU on no matter what for 2.7 and down will allow the removal of the tristate. Thanks, drew
