From mboxrd@z Thu Jan  1 00:00:00 1970
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [PATCH v8 10/19] x86/VPMU: Interface for setting
 PMU mode and flags
Date: Mon, 28 Jul 2014 12:29:27 -0400
Message-ID: <53D67A67.5000002@oracle.com>
References: <1404225480-2664-1-git-send-email-boris.ostrovsky@oracle.com>
	<1404225480-2664-11-git-send-email-boris.ostrovsky@oracle.com>
	<53D686D60200007800026B96@mail.emea.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <53D686D60200007800026B96@mail.emea.novell.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Jan Beulich <JBeulich@suse.com>
Cc: kevin.tian@intel.com, keir@xen.org, suravee.suthikulpanit@amd.com, andrew.cooper3@citrix.com, tim@xen.org, dietmar.hahn@ts.fujitsu.com, xen-devel@lists.xen.org, jun.nakajima@intel.com
List-Id: xen-devel@lists.xenproject.org

On 07/28/2014 11:22 AM, Jan Beulich wrote:
>>>> On 01.07.14 at 16:37, <boris.ostrovsky@oracle.com> wrote:


>> +    start = NOW();
>> +    /*
>> +     * Note that we may fail here if a CPU is hot-unplugged while we are
>> +     * waiting. We will then time out.
>> +     */
>> +    while ( atomic_read(&vpmu_sched_counter) != allbutself_num )
>> +    {
>> +        /* Give up after 5 seconds */
>> +        if ( NOW() > start + SECONDS(5) )
>> +        {
>> +            printk("vpmu_unload_all: failed to sync\n");
>> +            ret = -EBUSY;
>> +            break;
>> +        }
>> +        cpu_relax();
>> +        if ( hypercall_preempt_check() )
>> +            return hypercall_create_continuation(
>> +                __HYPERVISOR_xenpmu_op, "ih", XENPMU_mode_set, arg);
>> +    }
> I wonder whether this is race free (wrt another CPU doing something
> similar) and how you expect the 5s timeout above to ever be reached
> (you're virtually guaranteed to get asked to preempt earlier).

Race-wise there is xenpmu_mode_lock in the caller (quoted below).

As for 5s --- yes, this is rather useless. I should keep track of 
accumulated time in the loop across continuations and error out when it 
reaches some value (say, 5s).

>> +
>> +    for ( i = 0; i < allbutself_num; i++ )
>> +        tasklet_kill(&sync_task[i]);
>> +    xfree(sync_task);
>> +    sync_task = NULL;
>> +
>> +    return ret;
>> +}
>> +
>> +long do_xenpmu_op(int op, XEN_GUEST_HANDLE_PARAM(xen_pmu_params_t) arg)
>> +{
>> +    int ret = -EINVAL;
>> +    xen_pmu_params_t pmu_params;
>> +
>> +    switch ( op )
>> +    {
>> +    case XENPMU_mode_set:
>> +    {
>> +        static DEFINE_SPINLOCK(xenpmu_mode_lock);
>> +        uint32_t current_mode;
>> +
>> +        if ( !is_control_domain(current->domain) )
>> +            return -EPERM;
>> +
>> +        if ( copy_from_guest(&pmu_params, arg, 1) )
>> +            return -EFAULT;
>> +
>> +        if ( pmu_params.val & ~XENPMU_MODE_ON )
>> +            return -EINVAL;
>> +
>> +        if ( !spin_trylock(&xenpmu_mode_lock) )
>> +            return -EAGAIN;
> Wouldn't it be better for this to also set a continuation, rather than
> having the caller do the retry?

I actually want the caller (who is most likely the administrator doing 
'echo off > /sys/hypervisor/pmu/pmu_mode') see the error since this 
indicates two people trying to change system-wise settings at the same time.

-boris