From mboxrd@z Thu Jan  1 00:00:00 1970
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [PATCH v24 04/15] x86/VPMU: Interface for setting
 PMU mode and flags
Date: Fri, 12 Jun 2015 09:58:23 -0400
Message-ID: <557AE57F.8090703@oracle.com>
References: <1433948671-29504-1-git-send-email-boris.ostrovsky@oracle.com>
	<1433948671-29504-5-git-send-email-boris.ostrovsky@oracle.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D126289B97@SHSMSX101.ccr.corp.intel.com>
	<5579A125.1060106@oracle.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D12628B6E9@SHSMSX101.ccr.corp.intel.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: <AADFC41AFE54684AB9EE6CBC0274A5D12628B6E9@SHSMSX101.ccr.corp.intel.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: "Tian, Kevin" <kevin.tian@intel.com>, "JBeulich@suse.com" <JBeulich@suse.com>, "suravee.suthikulpanit@amd.com" <suravee.suthikulpanit@amd.com>, "Aravind.Gopalakrishnan@amd.com" <Aravind.Gopalakrishnan@amd.com>, "dietmar.hahn@ts.fujitsu.com" <dietmar.hahn@ts.fujitsu.com>, "dgdegra@tycho.nsa.gov" <dgdegra@tycho.nsa.gov>, "andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>
Cc: "tim@xen.org" <tim@xen.org>, "Nakajima, Jun" <jun.nakajima@intel.com>, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
List-Id: xen-devel@lists.xenproject.org

On 06/11/2015 11:23 PM, Tian, Kevin wrote:
>> From: Boris Ostrovsky [mailto:boris.ostrovsky@oracle.com]

>
>>
>>
>>>> +
>>>> +    case XENPMU_feature_set:
>>>> +        if ( pmu_params.val & ~XENPMU_FEATURE_INTEL_BTS )
>>>> +            return -EINVAL;
>>>> +
>>>> +        spin_lock(&vpmu_lock);
>>>> +
>>>> +        if ( vpmu_count == 0 )
>>>> +            vpmu_features = pmu_params.val;
>>>> +        else
>>>> +        {
>>>> +            printk(XENLOG_WARNING "VPMU: Cannot change features while"
>>>> +                                  " active VPMUs exist\n");
>>>> +            ret = -EBUSY;
>>>> +        }
>>>
>>> what about setting same features as existing in vpmu_features?
>>> we should do same check as done in mode setting.
>>
>>
>> Not sure I follow you. There is only one feature currently that we
>> support --- BTS. And trying to set any other feature will result in
>> -EINVAL. What is wrong with trying to set the same bit twice? (except
>> for being pointless)
>>
>
> My point is whether you want to allow setting same bit twice
> when active PMUs exist. From above code it's disallowed
> w/ check on vpmu_count. However in earlier code handling
> vpmu_mode setting, you actually allow setting same mode
> twice:
>
> +        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;
>
> So I thought you may keep the same policy to allow setting
> vpmu_features with same bit twice too.

Oh, I see. You are suggesting changing XENPMU_feature_set to

     if ( (vpmu_count == 0) || (vpmu_features == pmu_params.val) )
        vpmu_features = pmu_params.val;

or dropping '|| (vpmu_mode == pmu_params.val)' from XENPMU_mode_set for 
consistency's sake?

I suppose I can do that, yes.

-boris