| Message ID | 20191220143025.33853-16-andrew.murray@arm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | arm64: KVM: add SPE profiling support | expand |
On Fri, Dec 20, 2019 at 02:30:22PM +0000, Andrew Murray wrote: > A side effect of supporting the SPE in guests is that we prevent the > host from collecting data whilst inside a guest thus creating a black-out > window. This occurs because instead of emulating the SPE, we share it > with our guests. We used to permit this; do we know if anyone is using it? Thanks, Mark. > Let's accurately describe our capabilities by using the perf exclude > flags to prevent !exclude_guest and exclude_host flags from being used. > > Signed-off-by: Andrew Murray <andrew.murray@arm.com> > --- > drivers/perf/arm_spe_pmu.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/perf/arm_spe_pmu.c b/drivers/perf/arm_spe_pmu.c > index 2d24af4cfcab..3703dbf459de 100644 > --- a/drivers/perf/arm_spe_pmu.c > +++ b/drivers/perf/arm_spe_pmu.c > @@ -679,6 +679,9 @@ static int arm_spe_pmu_event_init(struct perf_event *event) > if (attr->exclude_idle) > return -EOPNOTSUPP; > > + if (!attr->exclude_guest || attr->exclude_host) > + return -EOPNOTSUPP; > + > /* > * Feedback-directed frequency throttling doesn't work when we > * have a buffer of samples. We'd need to manually count the > -- > 2.21.0 >
On Fri, 20 Dec 2019 14:30:22 +0000, Andrew Murray <andrew.murray@arm.com> wrote: > > A side effect of supporting the SPE in guests is that we prevent the > host from collecting data whilst inside a guest thus creating a black-out > window. This occurs because instead of emulating the SPE, we share it > with our guests. > > Let's accurately describe our capabilities by using the perf exclude > flags to prevent !exclude_guest and exclude_host flags from being used. > > Signed-off-by: Andrew Murray <andrew.murray@arm.com> > --- > drivers/perf/arm_spe_pmu.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/perf/arm_spe_pmu.c b/drivers/perf/arm_spe_pmu.c > index 2d24af4cfcab..3703dbf459de 100644 > --- a/drivers/perf/arm_spe_pmu.c > +++ b/drivers/perf/arm_spe_pmu.c > @@ -679,6 +679,9 @@ static int arm_spe_pmu_event_init(struct perf_event *event) > if (attr->exclude_idle) > return -EOPNOTSUPP; > > + if (!attr->exclude_guest || attr->exclude_host) > + return -EOPNOTSUPP; > + I have the opposite approach. If the host decides to profile the guest, why should that be denied? If there is a black hole, it should take place in the guest. Today, the host does expect this to work, and there is no way that we unconditionally allow it to regress. M.
On Sun, Dec 22, 2019 at 12:10:52PM +0000, Marc Zyngier wrote: > On Fri, 20 Dec 2019 14:30:22 +0000, > Andrew Murray <andrew.murray@arm.com> wrote: > > > > A side effect of supporting the SPE in guests is that we prevent the > > host from collecting data whilst inside a guest thus creating a black-out > > window. This occurs because instead of emulating the SPE, we share it > > with our guests. > > > > Let's accurately describe our capabilities by using the perf exclude > > flags to prevent !exclude_guest and exclude_host flags from being used. > > > > Signed-off-by: Andrew Murray <andrew.murray@arm.com> > > --- > > drivers/perf/arm_spe_pmu.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/drivers/perf/arm_spe_pmu.c b/drivers/perf/arm_spe_pmu.c > > index 2d24af4cfcab..3703dbf459de 100644 > > --- a/drivers/perf/arm_spe_pmu.c > > +++ b/drivers/perf/arm_spe_pmu.c > > @@ -679,6 +679,9 @@ static int arm_spe_pmu_event_init(struct perf_event *event) > > if (attr->exclude_idle) > > return -EOPNOTSUPP; > > > > + if (!attr->exclude_guest || attr->exclude_host) > > + return -EOPNOTSUPP; > > + > > I have the opposite approach. If the host decides to profile the > guest, why should that be denied? If there is a black hole, it should > take place in the guest. Today, the host does expect this to work, and > there is no way that we unconditionally allow it to regress. That seems reasonable. Upon entering the guest we'd have to detect if the host is using SPE, and if so choose not to restore the guest registers. Instead we'd have to trap them and let the guest read/write emulated values until the host has finished with SPE - at which time we could restore the guest SPE registers to hardware. Does that approach make sense? Thanks, Andrew Murray > > M. > > -- > Jazz is not dead, it just smells funny.
On 2019-12-23 12:10, Andrew Murray wrote: > On Sun, Dec 22, 2019 at 12:10:52PM +0000, Marc Zyngier wrote: >> On Fri, 20 Dec 2019 14:30:22 +0000, >> Andrew Murray <andrew.murray@arm.com> wrote: >> > >> > A side effect of supporting the SPE in guests is that we prevent >> the >> > host from collecting data whilst inside a guest thus creating a >> black-out >> > window. This occurs because instead of emulating the SPE, we share >> it >> > with our guests. >> > >> > Let's accurately describe our capabilities by using the perf >> exclude >> > flags to prevent !exclude_guest and exclude_host flags from being >> used. >> > >> > Signed-off-by: Andrew Murray <andrew.murray@arm.com> >> > --- >> > drivers/perf/arm_spe_pmu.c | 3 +++ >> > 1 file changed, 3 insertions(+) >> > >> > diff --git a/drivers/perf/arm_spe_pmu.c >> b/drivers/perf/arm_spe_pmu.c >> > index 2d24af4cfcab..3703dbf459de 100644 >> > --- a/drivers/perf/arm_spe_pmu.c >> > +++ b/drivers/perf/arm_spe_pmu.c >> > @@ -679,6 +679,9 @@ static int arm_spe_pmu_event_init(struct >> perf_event *event) >> > if (attr->exclude_idle) >> > return -EOPNOTSUPP; >> > >> > + if (!attr->exclude_guest || attr->exclude_host) >> > + return -EOPNOTSUPP; >> > + >> >> I have the opposite approach. If the host decides to profile the >> guest, why should that be denied? If there is a black hole, it >> should >> take place in the guest. Today, the host does expect this to work, >> and >> there is no way that we unconditionally allow it to regress. > > That seems reasonable. > > Upon entering the guest we'd have to detect if the host is using SPE, > and if > so choose not to restore the guest registers. Instead we'd have to > trap them > and let the guest read/write emulated values until the host has > finished with > SPE - at which time we could restore the guest SPE registers to > hardware. > > Does that approach make sense? Yes, this would be much better. All of this can be found out at vcpu_load() time, and once you've moved most of the SPE sysreg handling there, it will just follow the normal scheduling flow. M.
diff --git a/drivers/perf/arm_spe_pmu.c b/drivers/perf/arm_spe_pmu.c index 2d24af4cfcab..3703dbf459de 100644 --- a/drivers/perf/arm_spe_pmu.c +++ b/drivers/perf/arm_spe_pmu.c @@ -679,6 +679,9 @@ static int arm_spe_pmu_event_init(struct perf_event *event) if (attr->exclude_idle) return -EOPNOTSUPP; + if (!attr->exclude_guest || attr->exclude_host) + return -EOPNOTSUPP; + /* * Feedback-directed frequency throttling doesn't work when we * have a buffer of samples. We'd need to manually count the
A side effect of supporting the SPE in guests is that we prevent the host from collecting data whilst inside a guest thus creating a black-out window. This occurs because instead of emulating the SPE, we share it with our guests. Let's accurately describe our capabilities by using the perf exclude flags to prevent !exclude_guest and exclude_host flags from being used. Signed-off-by: Andrew Murray <andrew.murray@arm.com> --- drivers/perf/arm_spe_pmu.c | 3 +++ 1 file changed, 3 insertions(+)