* Re: [Qemu-devel] [PATCH RFC 1/1] arm64: add an option to turn on/off vpmu support
2016-07-29 6:54 ` Andrew Jones
@ 2016-07-29 15:07 ` Wei Huang
2016-07-29 15:29 ` Peter Maydell
2016-08-01 12:04 ` Andrea Bolognani
2 siblings, 0 replies; 16+ messages in thread
From: Wei Huang @ 2016-07-29 15:07 UTC (permalink / raw)
To: Andrew Jones; +Cc: peter.maydell, qemu-arm, qemu-devel, abologna, shannon.zhao
On 07/29/2016 01:54 AM, Andrew Jones wrote:
> On Thu, Jul 28, 2016 at 11:38:16AM -0500, Wei Huang wrote:
>> This patch adds a pmu=[on/off] option to enable/disable vpmu support
>> in guest vm. There are several reasons to justify this option. First
>> vpmu can be problematic for cross-migration between different SoC as
>> perf counters is architecture-dependent. It is more flexible to
>> have an option to turn it on/off. Secondly it matches the -cpu pmu
>> option in libivrt. This patch has been tested on both DT/ACPI modes.
>>
>> Signed-off-by: Wei Huang <wei@redhat.com>
>> ---
>> hw/arm/virt-acpi-build.c | 2 +-
>> hw/arm/virt.c | 2 +-
>> target-arm/cpu.c | 1 +
>> target-arm/cpu.h | 5 +++--
>> target-arm/kvm64.c | 10 +++++-----
>> 5 files changed, 11 insertions(+), 9 deletions(-)
>>
>> diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
>> index 28fc59c..dc5f66d 100644
>> --- a/hw/arm/virt-acpi-build.c
>> +++ b/hw/arm/virt-acpi-build.c
>> @@ -540,7 +540,7 @@ build_madt(GArray *table_data, BIOSLinker *linker, VirtGuestInfo *guest_info)
>> gicc->uid = i;
>> gicc->flags = cpu_to_le32(ACPI_GICC_ENABLED);
>>
>> - if (armcpu->has_pmu) {
>> + if (armcpu->enable_pmu) {
>> gicc->performance_interrupt = cpu_to_le32(PPI(VIRTUAL_PMU_IRQ));
>> }
>> }
>> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
>> index a193b5a..6aea901 100644
>> --- a/hw/arm/virt.c
>> +++ b/hw/arm/virt.c
>> @@ -477,7 +477,7 @@ static void fdt_add_pmu_nodes(const VirtBoardInfo *vbi, int gictype)
>>
>> CPU_FOREACH(cpu) {
>> armcpu = ARM_CPU(cpu);
>> - if (!armcpu->has_pmu ||
>> + if (!armcpu->enable_pmu ||
>> !kvm_arm_pmu_create(cpu, PPI(VIRTUAL_PMU_IRQ))) {
>> return;
>> }
>> diff --git a/target-arm/cpu.c b/target-arm/cpu.c
>> index ce8b8f4..f7daf81 100644
>> --- a/target-arm/cpu.c
>> +++ b/target-arm/cpu.c
>> @@ -1412,6 +1412,7 @@ static const ARMCPUInfo arm_cpus[] = {
>> };
>>
>> static Property arm_cpu_properties[] = {
>> + DEFINE_PROP_BOOL("pmu", ARMCPU, enable_pmu, true),
>
> x86's pmu property defaults to off. I'm not sure if it's necessary to
> have a consistent default between x86 and arm in order for libvirt to
> be able to use it in the same way. We should confirm with libvirt
> people. Anyway, I think I'd prefer we default off here, and then we
> can default on in machine code for configurations that we want it by
> default (only AArch64 KVM). Or, maybe we don't want it by default at
> all? Possibly we should only set it on by default for virt-2.6, and
> then, from 2.7 on, require users to opt-in to the feature. It makes
> sense to require opting-in to features that can cause problems with
> migration.
This option is default=off on x86. I agree that it is a compatibility
related issue which can break migration. So it is reasonable to turn it
off on ARM as well. Let us wait for libvirt people to voice out.
>
>> DEFINE_PROP_BOOL("start-powered-off", ARMCPU, start_powered_off, false),
>> DEFINE_PROP_UINT32("psci-conduit", ARMCPU, psci_conduit, 0),
>> DEFINE_PROP_UINT32("midr", ARMCPU, midr, 0),
>> diff --git a/target-arm/cpu.h b/target-arm/cpu.h
>> index 76d824d..f2341c0 100644
>> --- a/target-arm/cpu.h
>> +++ b/target-arm/cpu.h
>> @@ -579,8 +579,9 @@ struct ARMCPU {
>> bool powered_off;
>> /* CPU has security extension */
>> bool has_el3;
>> - /* CPU has PMU (Performance Monitor Unit) */
>> - bool has_pmu;
>> +
>> + /* CPU has vPMU (Performance Monitor Unit) support */
>> + bool enable_pmu;
>>
>> /* CPU has memory protection unit */
>> bool has_mpu;
>> diff --git a/target-arm/kvm64.c b/target-arm/kvm64.c
>> index 5faa76c..ca21670 100644
>> --- a/target-arm/kvm64.c
>> +++ b/target-arm/kvm64.c
>> @@ -501,11 +501,11 @@ int kvm_arch_init_vcpu(CPUState *cs)
>> if (!arm_feature(&cpu->env, ARM_FEATURE_AARCH64)) {
>> cpu->kvm_init_features[0] |= 1 << KVM_ARM_VCPU_EL1_32BIT;
>> }
>> - if (kvm_irqchip_in_kernel() &&
>> - kvm_check_extension(cs->kvm_state, KVM_CAP_ARM_PMU_V3)) {
>> - cpu->has_pmu = true;
>> - cpu->kvm_init_features[0] |= 1 << KVM_ARM_VCPU_PMU_V3;
>> - }
>> +
>> + /* enable vPMU based on KVM mode and hardware capability */
>> + cpu->enable_pmu &= (kvm_irqchip_in_kernel() &&
>> + kvm_check_extension(cs->kvm_state, KVM_CAP_ARM_PMU_V3));
>
> nit: the () aren't necessary
>
Will fix
>> + cpu->kvm_init_features[0] |= cpu->enable_pmu << KVM_ARM_VCPU_PMU_V3;
>>
>> /* Do KVM_ARM_VCPU_INIT ioctl */
>> ret = kvm_arm_vcpu_init(cs);
>> --
>> 2.4.11
>>
>>
>
> OK, so this property will be exposed to all ARM cpu types, and if a user
> turns it on, then it will stay on for all types, except when using KVM
> with an aarch64 cpu type, and KVM doesn't support it. This could mislead
> users to believe they'll get a pmu, by simply adding pmu=on, even when
> they can't. I think we'd ideally keep has_pmu, and the current code that
> sets it, and then add code like
>
> if (enable_pmu && !has_pmu) {
> error_report("Warning: ...")
> }
>
> somewhere. Unfortunately I don't think there's any one place we could
> add that. We'd need to add it to every ARM machine type that cares about
> not misleading users. Too bad cpu properties aren't whitelisted by
> machines to avoid this issue.
>
> Anyway, all that said, I see this is just how cpu properties currently
> work, so we probably don't need to worry about it for every machine. I
> do still suggest we add the above warning to mach-virt though.
Will try to keep both has_pmu & enable_pmu in the next re-spin...
>
> Thanks,
> drew
>
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Qemu-devel] [PATCH RFC 1/1] arm64: add an option to turn on/off vpmu support
2016-07-29 6:54 ` Andrew Jones
2016-07-29 15:07 ` Wei Huang
@ 2016-07-29 15:29 ` Peter Maydell
2016-08-01 12:04 ` Andrea Bolognani
2 siblings, 0 replies; 16+ messages in thread
From: Peter Maydell @ 2016-07-29 15:29 UTC (permalink / raw)
To: Andrew Jones
Cc: Wei Huang, qemu-arm, QEMU Developers, Shannon Zhao, Andrea Bolognani
On 29 July 2016 at 07:54, Andrew Jones <drjones@redhat.com> wrote:
> OK, so this property will be exposed to all ARM cpu types, and if a user
> turns it on, then it will stay on for all types, except when using KVM
> with an aarch64 cpu type, and KVM doesn't support it. This could mislead
> users to believe they'll get a pmu, by simply adding pmu=on, even when
> they can't. I think we'd ideally keep has_pmu, and the current code that
> sets it, and then add code like
>
> if (enable_pmu && !has_pmu) {
> error_report("Warning: ...")
> }
>
> somewhere.
I think we should probably follow the existing model used by
has_el3, where the property only exists if it's valid to set it.
thanks
-- PMM
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Qemu-devel] [PATCH RFC 1/1] arm64: add an option to turn on/off vpmu support
2016-07-29 6:54 ` Andrew Jones
2016-07-29 15:07 ` Wei Huang
2016-07-29 15:29 ` Peter Maydell
@ 2016-08-01 12:04 ` Andrea Bolognani
2016-08-01 13:08 ` Andrew Jones
2 siblings, 1 reply; 16+ messages in thread
From: Andrea Bolognani @ 2016-08-01 12:04 UTC (permalink / raw)
To: Andrew Jones, Wei Huang; +Cc: qemu-arm, qemu-devel, peter.maydell, shannon.zhao
On Fri, 2016-07-29 at 08:54 +0200, Andrew Jones wrote:
> On Thu, Jul 28, 2016 at 11:38:16AM -0500, Wei Huang wrote:
> >
> > This patch adds a pmu=[on/off] option to enable/disable vpmu support
> > in guest vm. There are several reasons to justify this option. First
> > vpmu can be problematic for cross-migration between different SoC as
> > perf counters is architecture-dependent. It is more flexible to
> > have an option to turn it on/off. Secondly it matches the -cpu pmu
> > option in libivrt. This patch has been tested on both DT/ACPI modes.
> >
> > Signed-off-by: Wei Huang <wei@redhat.com>
> > ---
> > hw/arm/virt-acpi-build.c | 2 +-
> > hw/arm/virt.c | 2 +-
> > target-arm/cpu.c | 1 +
> > target-arm/cpu.h | 5 +++--
> > target-arm/kvm64.c | 10 +++++-----
> > 5 files changed, 11 insertions(+), 9 deletions(-)
> >
> > diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
> > index 28fc59c..dc5f66d 100644
> > --- a/hw/arm/virt-acpi-build.c
> > +++ b/hw/arm/virt-acpi-build.c
> > @@ -540,7 +540,7 @@ build_madt(GArray *table_data, BIOSLinker *linker, VirtGuestInfo *guest_info)
> > gicc->uid = i;
> > gicc->flags = cpu_to_le32(ACPI_GICC_ENABLED);
> >
> > - if (armcpu->has_pmu) {
> > + if (armcpu->enable_pmu) {
> > gicc->performance_interrupt = cpu_to_le32(PPI(VIRTUAL_PMU_IRQ));
> > }
> > }
> > diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> > index a193b5a..6aea901 100644
> > --- a/hw/arm/virt.c
> > +++ b/hw/arm/virt.c
> > @@ -477,7 +477,7 @@ static void fdt_add_pmu_nodes(const VirtBoardInfo *vbi, int gictype)
> >
> > CPU_FOREACH(cpu) {
> > armcpu = ARM_CPU(cpu);
> > - if (!armcpu->has_pmu ||
> > + if (!armcpu->enable_pmu ||
> > !kvm_arm_pmu_create(cpu, PPI(VIRTUAL_PMU_IRQ))) {
> > return;
> > }
> > diff --git a/target-arm/cpu.c b/target-arm/cpu.c
> > index ce8b8f4..f7daf81 100644
> > --- a/target-arm/cpu.c
> > +++ b/target-arm/cpu.c
> > @@ -1412,6 +1412,7 @@ static const ARMCPUInfo arm_cpus[] = {
> > };
> >
> > static Property arm_cpu_properties[] = {
> > + DEFINE_PROP_BOOL("pmu", ARMCPU, enable_pmu, true),
>
> x86's pmu property defaults to off. I'm not sure if it's necessary to
> have a consistent default between x86 and arm in order for libvirt to
> be able to use it in the same way. We should confirm with libvirt
> people. Anyway, I think I'd prefer we default off here, and then we
> can default on in machine code for configurations that we want it by
> default (only AArch64 KVM). Or, maybe we don't want it by default at
> all? Possibly we should only set it on by default for virt-2.6, and
> then, from 2.7 on, require users to opt-in to the feature. It makes
> sense to require opting-in to features that can cause problems with
> migration.
After thinking about this a bit, I don't think it matters that
much (from libvirt's point of view) whether the default is on
or off - there are a bunch of other situations where the user
is required to specify explicitly whether he wants the feature
or not, and if he doesn't choose either side he will get
whatever QEMU uses as a default.
What's important is that the user can pick one or the other
when it matters to him, and having a pmu property like the one
x86 already has fits the bill.
That said, defaulting to off looks like it would be the least
confusing behaviour.
> > + cpu->kvm_init_features[0] |= cpu->enable_pmu << KVM_ARM_VCPU_PMU_V3;
> >
> > /* Do KVM_ARM_VCPU_INIT ioctl */
> > ret = kvm_arm_vcpu_init(cs);
>
> OK, so this property will be exposed to all ARM cpu types, and if a user
> turns it on, then it will stay on for all types, except when using KVM
> with an aarch64 cpu type, and KVM doesn't support it. This could mislead
> users to believe they'll get a pmu, by simply adding pmu=on, even when
> they can't. I think we'd ideally keep has_pmu, and the current code that
> sets it, and then add code like
>
> if (enable_pmu && !has_pmu) {
> error_report("Warning: ...")
> }
>
> somewhere. Unfortunately I don't think there's any one place we could
> add that. We'd need to add it to every ARM machine type that cares about
> not misleading users. Too bad cpu properties aren't whitelisted by
> machines to avoid this issue.
>
> Anyway, all that said, I see this is just how cpu properties currently
> work, so we probably don't need to worry about it for every machine. I
> do still suggest we add the above warning to mach-virt though.
I'm not sure a warning is enough: if I start a guest and
explicitly ask for a PMU, I expect it to be there, or for
the guest not to start at all. How does x86 behave in this
regard?
--
Andrea Bolognani / Red Hat / Virtualization
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Qemu-devel] [PATCH RFC 1/1] arm64: add an option to turn on/off vpmu support
2016-08-01 12:04 ` Andrea Bolognani
@ 2016-08-01 13:08 ` Andrew Jones
2016-08-01 13:16 ` Peter Maydell
2016-08-01 13:26 ` Andrea Bolognani
0 siblings, 2 replies; 16+ messages in thread
From: Andrew Jones @ 2016-08-01 13:08 UTC (permalink / raw)
To: Andrea Bolognani
Cc: Wei Huang, qemu-arm, qemu-devel, peter.maydell, shannon.zhao
On Mon, Aug 01, 2016 at 02:04:59PM +0200, Andrea Bolognani wrote:
> On Fri, 2016-07-29 at 08:54 +0200, Andrew Jones wrote:
> > On Thu, Jul 28, 2016 at 11:38:16AM -0500, Wei Huang wrote:
> > >
> > > This patch adds a pmu=[on/off] option to enable/disable vpmu support
> > > in guest vm. There are several reasons to justify this option. First
> > > vpmu can be problematic for cross-migration between different SoC as
> > > perf counters is architecture-dependent. It is more flexible to
> > > have an option to turn it on/off. Secondly it matches the -cpu pmu
> > > option in libivrt. This patch has been tested on both DT/ACPI modes.
> > >
> > > Signed-off-by: Wei Huang <wei@redhat.com>
> > > ---
> > > hw/arm/virt-acpi-build.c | 2 +-
> > > hw/arm/virt.c | 2 +-
> > > target-arm/cpu.c | 1 +
> > > target-arm/cpu.h | 5 +++--
> > > target-arm/kvm64.c | 10 +++++-----
> > > 5 files changed, 11 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
> > > index 28fc59c..dc5f66d 100644
> > > --- a/hw/arm/virt-acpi-build.c
> > > +++ b/hw/arm/virt-acpi-build.c
> > > @@ -540,7 +540,7 @@ build_madt(GArray *table_data, BIOSLinker *linker, VirtGuestInfo *guest_info)
> > > gicc->uid = i;
> > > gicc->flags = cpu_to_le32(ACPI_GICC_ENABLED);
> > >
> > > - if (armcpu->has_pmu) {
> > > + if (armcpu->enable_pmu) {
> > > gicc->performance_interrupt = cpu_to_le32(PPI(VIRTUAL_PMU_IRQ));
> > > }
> > > }
> > > diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> > > index a193b5a..6aea901 100644
> > > --- a/hw/arm/virt.c
> > > +++ b/hw/arm/virt.c
> > > @@ -477,7 +477,7 @@ static void fdt_add_pmu_nodes(const VirtBoardInfo *vbi, int gictype)
> > >
> > > CPU_FOREACH(cpu) {
> > > armcpu = ARM_CPU(cpu);
> > > - if (!armcpu->has_pmu ||
> > > + if (!armcpu->enable_pmu ||
> > > !kvm_arm_pmu_create(cpu, PPI(VIRTUAL_PMU_IRQ))) {
> > > return;
> > > }
> > > diff --git a/target-arm/cpu.c b/target-arm/cpu.c
> > > index ce8b8f4..f7daf81 100644
> > > --- a/target-arm/cpu.c
> > > +++ b/target-arm/cpu.c
> > > @@ -1412,6 +1412,7 @@ static const ARMCPUInfo arm_cpus[] = {
> > > };
> > >
> > > static Property arm_cpu_properties[] = {
> > > + DEFINE_PROP_BOOL("pmu", ARMCPU, enable_pmu, true),
> >
> > x86's pmu property defaults to off. I'm not sure if it's necessary to
> > have a consistent default between x86 and arm in order for libvirt to
> > be able to use it in the same way. We should confirm with libvirt
> > people. Anyway, I think I'd prefer we default off here, and then we
> > can default on in machine code for configurations that we want it by
> > default (only AArch64 KVM). Or, maybe we don't want it by default at
> > all? Possibly we should only set it on by default for virt-2.6, and
> > then, from 2.7 on, require users to opt-in to the feature. It makes
> > sense to require opting-in to features that can cause problems with
> > migration.
>
> After thinking about this a bit, I don't think it matters that
> much (from libvirt's point of view) whether the default is on
> or off - there are a bunch of other situations where the user
> is required to specify explicitly whether he wants the feature
> or not, and if he doesn't choose either side he will get
> whatever QEMU uses as a default.
>
> What's important is that the user can pick one or the other
> when it matters to him, and having a pmu property like the one
> x86 already has fits the bill.
>
> That said, defaulting to off looks like it would be the least
> confusing behaviour.
OK, so the default is still up for debate.
Pros of ON Cons of ON
---------- ----------
We already do it The default instance is less migratable
Less typing on cmdline
(libvirt covers typing for us anyway...)
Pros of OFF Cons of OFF
----------- -----------
See 'Cons of ON' See 'Pros on ON' (virt-2.6 needs compat code)
>
> > > + cpu->kvm_init_features[0] |= cpu->enable_pmu << KVM_ARM_VCPU_PMU_V3;
> > >
> > > /* Do KVM_ARM_VCPU_INIT ioctl */
> > > ret = kvm_arm_vcpu_init(cs);
> >
> > OK, so this property will be exposed to all ARM cpu types, and if a user
> > turns it on, then it will stay on for all types, except when using KVM
> > with an aarch64 cpu type, and KVM doesn't support it. This could mislead
> > users to believe they'll get a pmu, by simply adding pmu=on, even when
> > they can't. I think we'd ideally keep has_pmu, and the current code that
> > sets it, and then add code like
> >
> > if (enable_pmu && !has_pmu) {
> > error_report("Warning: ...")
> > }
> >
> > somewhere. Unfortunately I don't think there's any one place we could
> > add that. We'd need to add it to every ARM machine type that cares about
> > not misleading users. Too bad cpu properties aren't whitelisted by
> > machines to avoid this issue.
> >
> > Anyway, all that said, I see this is just how cpu properties currently
> > work, so we probably don't need to worry about it for every machine. I
> > do still suggest we add the above warning to mach-virt though.
>
> I'm not sure a warning is enough: if I start a guest and
> explicitly ask for a PMU, I expect it to be there, or for
> the guest not to start at all. How does x86 behave in this
> regard?
Peter had a good suggestion for this. We need to wrap the property
addition in an arm_feature check like the has_el3 property. That will
remove it from all cpu types that don't support it. Then there's no
need for the enable_pmu && !has_pmu check as the has_pmu part is covered
very early with the feature flag in arm_cpu_post_init(). Peter also
suggested we keep the 'has_pmu' name, rather than change it to
'enable_pmu'. On that one I would disagree. 'has_pmu' indicates that the
feature is available at all, which it is to all cpu types that have the
arm feature, but not all users will want it enabled. 'enable_pmu', which
matches x86's naming, seems more appropriate for that.
Thanks,
drew
>
> --
> Andrea Bolognani / Red Hat / Virtualization
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Qemu-devel] [PATCH RFC 1/1] arm64: add an option to turn on/off vpmu support
2016-08-01 13:08 ` Andrew Jones
@ 2016-08-01 13:16 ` Peter Maydell
2016-08-01 13:26 ` Andrea Bolognani
1 sibling, 0 replies; 16+ messages in thread
From: Peter Maydell @ 2016-08-01 13:16 UTC (permalink / raw)
To: Andrew Jones
Cc: Andrea Bolognani, Wei Huang, qemu-arm, QEMU Developers, Shannon Zhao
On 1 August 2016 at 14:08, Andrew Jones <drjones@redhat.com> wrote:
> Peter had a good suggestion for this. We need to wrap the property
> addition in an arm_feature check like the has_el3 property. That will
> remove it from all cpu types that don't support it. Then there's no
> need for the enable_pmu && !has_pmu check as the has_pmu part is covered
> very early with the feature flag in arm_cpu_post_init(). Peter also
> suggested we keep the 'has_pmu' name, rather than change it to
> 'enable_pmu'. On that one I would disagree. 'has_pmu' indicates that the
> feature is available at all, which it is to all cpu types that have the
> arm feature, but not all users will want it enabled. 'enable_pmu', which
> matches x86's naming, seems more appropriate for that.
If you create the CPU with pmu=off then it does not have a PMU,
and so has_pmu is false. I don't see any reason for the naming
convention for the PMU to diverge from what we have for EL3
and for the MPU, where the property names and the struct fields
both use 'has'.
thanks
-- PMM
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Qemu-devel] [PATCH RFC 1/1] arm64: add an option to turn on/off vpmu support
2016-08-01 13:08 ` Andrew Jones
2016-08-01 13:16 ` Peter Maydell
@ 2016-08-01 13:26 ` Andrea Bolognani
2016-08-01 13:32 ` Peter Maydell
1 sibling, 1 reply; 16+ messages in thread
From: Andrea Bolognani @ 2016-08-01 13:26 UTC (permalink / raw)
To: Andrew Jones; +Cc: Wei Huang, qemu-arm, qemu-devel, peter.maydell, shannon.zhao
On Mon, 2016-08-01 at 15:08 +0200, Andrew Jones wrote:
> > I'm not sure a warning is enough: if I start a guest and
> > explicitly ask for a PMU, I expect it to be there, or for
> > the guest not to start at all. How does x86 behave in this
> > regard?
>
> Peter had a good suggestion for this. We need to wrap the property
> addition in an arm_feature check like the has_el3 property. That will
> remove it from all cpu types that don't support it.
Wouldn't that mean that you'd be unable to use
-cpu foo,pmu=off
if CPU model 'foo' doesn't support a PMU? I'd expect that
to work.
I've played around with this a bit on x86 and it doesn't
look like it necessarily behaves the way I'd expect it to,
either, so maybe this is just a case of my expectations
being unreasonable? :)
--
Andrea Bolognani / Red Hat / Virtualization
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Qemu-devel] [PATCH RFC 1/1] arm64: add an option to turn on/off vpmu support
2016-08-01 13:26 ` Andrea Bolognani
@ 2016-08-01 13:32 ` Peter Maydell
2016-08-01 14:55 ` Andrea Bolognani
2016-08-13 6:06 ` Wei Huang
0 siblings, 2 replies; 16+ messages in thread
From: Peter Maydell @ 2016-08-01 13:32 UTC (permalink / raw)
To: Andrea Bolognani
Cc: Andrew Jones, Wei Huang, qemu-arm, QEMU Developers, Shannon Zhao
On 1 August 2016 at 14:26, Andrea Bolognani <abologna@redhat.com> wrote:
> On Mon, 2016-08-01 at 15:08 +0200, Andrew Jones wrote:
>> > I'm not sure a warning is enough: if I start a guest and
>> > explicitly ask for a PMU, I expect it to be there, or for
>> > the guest not to start at all. How does x86 behave in this
>> > regard?
>>
>> Peter had a good suggestion for this. We need to wrap the property
>> addition in an arm_feature check like the has_el3 property. That will
>> remove it from all cpu types that don't support it.
>
> Wouldn't that mean that you'd be unable to use
>
> -cpu foo,pmu=off
>
> if CPU model 'foo' doesn't support a PMU? I'd expect that
> to work.
The current precedent (has_el3) doesn't work like that: if
foo isn't a CPU which can support EL3 then the property doesn't
exist, and it's an error to try to set it.
thanks
-- PMM
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Qemu-devel] [PATCH RFC 1/1] arm64: add an option to turn on/off vpmu support
2016-08-01 13:32 ` Peter Maydell
@ 2016-08-01 14:55 ` Andrea Bolognani
2016-08-13 6:06 ` Wei Huang
1 sibling, 0 replies; 16+ messages in thread
From: Andrea Bolognani @ 2016-08-01 14:55 UTC (permalink / raw)
To: Peter Maydell
Cc: Andrew Jones, Wei Huang, qemu-arm, QEMU Developers, Shannon Zhao
On Mon, 2016-08-01 at 14:32 +0100, Peter Maydell wrote:
> > Wouldn't that mean that you'd be unable to use
> >
> > -cpu foo,pmu=off
> >
> > if CPU model 'foo' doesn't support a PMU? I'd expect that
> > to work.
>
> The current precedent (has_el3) doesn't work like that: if
> foo isn't a CPU which can support EL3 then the property doesn't
> exist, and it's an error to try to set it.
Doesn't look like the pmu option works like that on x86,
though, unless I'm missing something.
I have a guest running with
-cpu pentium,pmu=on
and I can't see hardware perf events from inside the guest,
eg. dmesg reports
Performance Events: no PMU driver, software events only.
and perf tells me
<not supported> instructions
<not supported> branches
...
I'm not sure whether that's because the PMU is being
emulated but the kernel doesn't have a driver for it, or
whether it's not being emulated at all. Any way to find
out?
--
Andrea Bolognani / Red Hat / Virtualization
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Qemu-devel] [PATCH RFC 1/1] arm64: add an option to turn on/off vpmu support
2016-08-01 13:32 ` Peter Maydell
2016-08-01 14:55 ` Andrea Bolognani
@ 2016-08-13 6:06 ` Wei Huang
2016-08-15 9:24 ` Andrea Bolognani
1 sibling, 1 reply; 16+ messages in thread
From: Wei Huang @ 2016-08-13 6:06 UTC (permalink / raw)
To: Peter Maydell, Andrea Bolognani
Cc: Andrew Jones, qemu-arm, QEMU Developers, Shannon Zhao
On 08/01/2016 08:32 AM, Peter Maydell wrote:
> On 1 August 2016 at 14:26, Andrea Bolognani <abologna@redhat.com> wrote:
>> On Mon, 2016-08-01 at 15:08 +0200, Andrew Jones wrote:
>>>> I'm not sure a warning is enough: if I start a guest and
>>>> explicitly ask for a PMU, I expect it to be there, or for
>>>> the guest not to start at all. How does x86 behave in this
>>>> regard?
>>>
>>> Peter had a good suggestion for this. We need to wrap the property
>>> addition in an arm_feature check like the has_el3 property. That will
>>> remove it from all cpu types that don't support it.
>>
>> Wouldn't that mean that you'd be unable to use
>>
>> -cpu foo,pmu=off
>>
>> if CPU model 'foo' doesn't support a PMU? I'd expect that
>> to work.
>
> The current precedent (has_el3) doesn't work like that: if
> foo isn't a CPU which can support EL3 then the property doesn't
> exist, and it's an error to try to set it.
V1 sent. I tried to follow everyone's advice. See the following:
* set default pmu=off
* like el3, add a new feature ARM_FEATURE_HOST_PMU
* "pmu" property becomes CPU dependent. Only cortex-a53/cortex-a57/host
under certain mode support this option
* change struct ARMCPU field name "has_pmu" ==> "has_host_pmu" because
IMO "has_pmu" is misleading
BTW answering Andrea's question above: "-cpu foo,pmu=off" won't be
allowed in this patch if CPU "foo" doesn't support host-backed PMU. QEMU
will fail to run in this case. Maybe this is what we want?
Thanks,
-Wei
>
> thanks
> -- PMM
>
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Qemu-devel] [PATCH RFC 1/1] arm64: add an option to turn on/off vpmu support
2016-08-13 6:06 ` Wei Huang
@ 2016-08-15 9:24 ` Andrea Bolognani
0 siblings, 0 replies; 16+ messages in thread
From: Andrea Bolognani @ 2016-08-15 9:24 UTC (permalink / raw)
To: Wei Huang, Peter Maydell
Cc: Andrew Jones, qemu-arm, QEMU Developers, Shannon Zhao
On Sat, 2016-08-13 at 01:06 -0500, Wei Huang wrote:
> > > Wouldn't that mean that you'd be unable to use
> > >
> > > -cpu foo,pmu=off
> > >
> > > if CPU model 'foo' doesn't support a PMU? I'd expect that
> > > to work.
> >
> > The current precedent (has_el3) doesn't work like that: if
> > foo isn't a CPU which can support EL3 then the property doesn't
> > exist, and it's an error to try to set it.
>
> V1 sent. I tried to follow everyone's advice. See the following:
>
> * set default pmu=off
> * like el3, add a new feature ARM_FEATURE_HOST_PMU
> * "pmu" property becomes CPU dependent. Only cortex-a53/cortex-a57/host
> under certain mode support this option
> * change struct ARMCPU field name "has_pmu" ==> "has_host_pmu" because
> IMO "has_pmu" is misleading
>
> BTW answering Andrea's question above: "-cpu foo,pmu=off" won't be
> allowed in this patch if CPU "foo" doesn't support host-backed PMU. QEMU
> will fail to run in this case. Maybe this is what we want?
After discussing this a bit offline, I came to the conclusion
that there isn't a Single Right Way™ to handle this - both my
proposal and what you implemented are reasonable behaviors
one could expect.
On the other hand, what you implemented:
* matches x86
* is more strict than what I proposed, so there's room to
change it later without breaking any existing guest
so I'm happy with it :)
--
Andrea Bolognani / Red Hat / Virtualization
^ permalink raw reply [flat|nested] 16+ messages in thread