Re: [PATCH] xen/arm: Introduce pmu_access parameter

[Julien Grall <julien@xxxxxxx>]

On 01/09/2021 14:10, Bertrand Marquis wrote:
> Hi Julien,
Hi Bertrand,

> > On 1 Sep 2021, at 13:55, Julien Grall <julien@xxxxxxx> wrote:
> >
> > Hi,
> >
> > On 01/09/2021 13:43, Michal Orzel wrote:
> > > Introduce new Xen command line parameter called "pmu_access".
> > > The default value is "trap": Xen traps PMU accesses.
> > > In case of setting pmu_access to "native", Xen does not trap
> > > PMU accesses allowing all the guests to access PMU registers.
> > > However, guests cannot make use of PMU overflow interrupts as
> > > PMU uses PPI which Xen cannot route to guests.
> > > This option is only intended for development and testing purposes.
> > > Do not use this in production system.
> > I am afraid your option is not safe even in development system as a vCPU may 
> > move between pCPUs.
> >
> > However, even if we restricted the use to pinned vCPU *and* dedicated pCPU, I 
> > am not convinced that exposing an half backed PMU (the overflow interrupt would 
> > not work) to the guest is the right solution. This likely means the guest OS 
> > would need to be modified and therefore the usage of this option is fairly 
> > limited.
> >
> > So I think the first steps are:
> >   1) Make the PPI work. There was some attempt in the past for it on xen-devel. 
> > You could have a look.
> >   2) Provide PMU bindings
> >
> > With that in place, we can discuss how to expose the PMU even if it is unsafe 
> > in some conditions.
> With those limitations, using the PMU to monitor the system performances or on 
> some specific use cases is still really useful.
> We are using that to do some benchmarks of Xen or of some applications to 
> compare the behaviour to a native system or
> analyse the performances of Xen itself (hypercalls,context switch …etc)
I understand this is useful for some setup and I am not trying to say we 
should not have a way to expose the PMU (even unsafely) in upstream. 
However, I think the option as it stands is too wide (this should be a 
per domain knob) and we should properly expose the PMU (interrupts, 
bindings...).
> The steps you are mentioning do make sense but using the PMU without those 
> knowing the limitations is also very useful.
Right, this would require a lot more work than what I wrote before.

Cheers,

--
Julien Grall