From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH v20 02/13] x86/VPMU: Add public xenpmu.h Date: Tue, 21 Apr 2015 08:53:42 +0100 Message-ID: <55361E26020000780007415A@mail.emea.novell.com> References: <1428594295-2024-1-git-send-email-boris.ostrovsky@oracle.com> <1428594295-2024-3-git-send-email-boris.ostrovsky@oracle.com> <5534D9E80200007800073962@mail.emea.novell.com> <55352B6C.3040300@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <55352B6C.3040300@oracle.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Boris Ostrovsky Cc: kevin.tian@intel.com, suravee.suthikulpanit@amd.com, andrew.cooper3@citrix.com, tim@xen.org, dietmar.hahn@ts.fujitsu.com, xen-devel@lists.xen.org, Aravind.Gopalakrishnan@amd.com, jun.nakajima@intel.com, dgdegra@tycho.nsa.gov List-Id: xen-devel@lists.xenproject.org >>> On 20.04.15 at 18:38, wrote: > On 04/20/2015 04:50 AM, Jan Beulich wrote: >>>>> On 09.04.15 at 17:44, wrote: >>> --- /dev/null >>> +++ b/xen/include/public/pmu.h >>> @@ -0,0 +1,38 @@ >>> +#ifndef __XEN_PUBLIC_PMU_H__ >>> +#define __XEN_PUBLIC_PMU_H__ >>> + >>> +#include "xen.h" >>> +#if defined(__i386__) || defined(__x86_64__) >>> +#include "arch-x86/pmu.h" >>> +#elif defined (__arm__) || defined (__aarch64__) >>> +#include "arch-arm.h" >>> +#else >>> +#error "Unsupported architecture" >>> +#endif >>> + >>> +#define XENPMU_VER_MAJ 0 >>> +#define XENPMU_VER_MIN 1 >>> + >>> + >>> +/* Shared between hypervisor and PV domain */ >>> +struct xen_pmu_data { >> Iirc this sharing is r/o - if so, please state so in the comment. If not, >> please extend the comment to briefly explain why writable sharing >> is safe/secure. > > This data structure is writeable by guest (specifically, PMU registers > and APIC_LVTPC). There is a flag (PMU_CACHED, which is part of this > structure) that the hypervisor sets to let the guest know that it can > write those fields without having to trap. When the guest is done, it > issues XENPMU_flush command and the hypervisor writes out those values > to HW. > > I'll update the comments to make this clear. I think you'll actually want to state for each of the fields who reads and who writes them. In particular for (I hope) obvious reasons some (most?) of the fields would apparently need to be documented write-only by the hypervisor. Jan