|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v25 04/15] x86/VPMU: Interface for setting PMU mode and flags
>>> On 19.06.15 at 20:44, <boris.ostrovsky@xxxxxxxxxx> wrote:
> Add runtime interface for setting PMU mode and flags. Three main modes are
> provided:
> * XENPMU_MODE_OFF: PMU is not virtualized
> * XENPMU_MODE_SELF: Guests can access PMU MSRs and receive PMU interrupts.
> * XENPMU_MODE_HV: Same as XENPMU_MODE_SELF for non-proviledged guests, dom0
> can profile itself and the hypervisor.
>
> Note that PMU modes are different from what can be provided at Xen's boot
> line
> with 'vpmu' argument. An 'off' (or '0') value is equivalent to
> XENPMU_MODE_OFF.
> Any other value, on the other hand, will cause VPMU mode to be set to
> XENPMU_MODE_SELF during boot.
>
> For feature flags only Intel's BTS is currently supported.
>
> Mode and flags are set via HYPERVISOR_xenpmu_op hypercall.
>
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
> Acked-by: Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>
Acked-by: Jan Beulich <jbeulich@xxxxxxxx>
with one minor comment
> + switch ( op )
> + {
> + case XENPMU_mode_set:
> + {
> + if ( (pmu_params.val & ~(XENPMU_MODE_SELF | XENPMU_MODE_HV)) ||
> + (hweight64(pmu_params.val) > 1) )
> + return -EINVAL;
> +
> + /* 32-bit dom0 can only sample itself. */
> + if ( is_pv_32bit_vcpu(current) && (pmu_params.val & XENPMU_MODE_HV) )
> + return -EINVAL;
> +
> + spin_lock(&vpmu_lock);
> +
> + /*
> + * We can always safely switch between XENPMU_MODE_SELF and
> + * XENPMU_MODE_HV while other VPMUs are active.
> + */
> + if ( (vpmu_count == 0) || (vpmu_mode == pmu_params.val) ||
> + ((vpmu_mode ^ pmu_params.val) ==
> + (XENPMU_MODE_SELF | XENPMU_MODE_HV)) )
> + vpmu_mode = pmu_params.val;
> + else
> + {
I think this would better be
if ( (vpmu_count == 0) ||
((vpmu_mode ^ pmu_params.val) ==
(XENPMU_MODE_SELF | XENPMU_MODE_HV)) )
vpmu_mode = pmu_params.val;
else if ( vpmu_mode != pmu_params.val )
{
But there's no need to re-submit just because of this (it could be
changed upon commit if you agree).
Or wait - I just checked again, and while I thought this was long
addressed I still don't seen struct xen_pmu_params "pad" field
being checked to be zero as input, and being stored as zero when
only an output. Did this get lost? Did I forget about a reason why
this isn't being done? Unless the latter is the case, the ack above
is dependent upon this getting fixed.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |