From mboxrd@z Thu Jan  1 00:00:00 1970
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [PATCH v1 06/13] x86/PMU: Add public xenpmu.h
Date: Wed, 11 Sep 2013 10:03:00 -0400
Message-ID: <52307814.9000109@oracle.com>
References: <1378826470-4085-1-git-send-email-boris.ostrovsky@oracle.com>
	<1378826470-4085-7-git-send-email-boris.ostrovsky@oracle.com>
	<5230424502000078000F24BC@nat28.tlf.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>
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1VJkz2-0001oY-JA
	for xen-devel@lists.xenproject.org; Wed, 11 Sep 2013 14:01:28 +0000
In-Reply-To: <5230424502000078000F24BC@nat28.tlf.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: suravee.suthikulpanit@amd.com, George.Dunlap@eu.citrix.com, jacob.shin@amd.com, eddie.dong@intel.com, dietmar.hahn@ts.fujitsu.com, jun.nakajima@intel.com, xen-devel <xen-devel@lists.xenproject.org>, Ian Campbell <Ian.Campbell@citrix.com>
List-Id: xen-devel@lists.xenproject.org

On 09/11/2013 04:13 AM, Jan Beulich wrote:
>> --- /dev/null
>> +++ b/xen/include/public/xenpmu.h
> This new file is completely unacceptable as a public header.

Is this the same comment as IanC made? Mark up public interfaces for
doc generation?

Or something else?

>
>> @@ -0,0 +1,101 @@
>> +#ifndef __XEN_PUBLIC_XENPMU_H__
>> +#define __XEN_PUBLIC_XENPMU_H__
>> +
>> +#include <asm/msr.h>
> This is a no-go.
>
>> +
>> +#include "xen.h"
>> +
>> +#define XENPMU_VER_MAJ    0
>> +#define XENPMU_VER_MIN    0
>> +
>> +/* VPMU modes */
>> +#define VPMU_MODE_MASK     0xff
> All of these defines would need XEN_ prefixes (and types would
> similarly need xen_). And there ought to be some association in the
> comment to the field(s) that these constants would actually go into:
>  From a cursory look I can't see this.
>
>> +#define VPMU_OFF           0
>> +/* guests can profile themselves, (dom0 profiles itself and Xen) */
> Comment style.
>
>> +#define VPMU_ON            (1<<0)
>> +/*
>> + * Only dom0 has access to VPMU and it profiles everyone: itself,
>> + * the hypervisor and the guests.
>> + */
>> +#define VPMU_PRIV          (1<<1)
>> +
>> +/* VPMU flags */
>> +#define VPMU_FLAGS_MASK    ((uint32_t)(~VPMU_MODE_MASK))
>> +#define VPMU_INTEL_BTS     (1<<8) /* Ignored on AMD */
>> +
>> +
>> +/* AMD PMU registers and structures */
>> +#define F10H_NUM_COUNTERS   4
>> +#define F15H_NUM_COUNTERS   6
>> +/* To accommodate more counters in the future (e.g. NB counters) */
>> +#define MAX_NUM_COUNTERS    16
> Perhaps better to have the number of counters in the structure?
>
>> +struct amd_vpmu_context {
>> +    uint64_t counters[MAX_NUM_COUNTERS];
>> +    uint64_t ctrls[MAX_NUM_COUNTERS];
>> +    uint8_t msr_bitmap_set;
>> +};
>> +
>> +
>> +/* Intel PMU registers and structures */
>> +static const uint32_t core2_fix_counters_msr[] = {
> You're kidding, aren't you?

This was moved from vpmu.h. I will change it to enum (or remove altogether).

-boris