Re: [PATCH v20 02/13] x86/VPMU: Add public xenpmu.h

["Jan Beulich" <JBeulich@suse.com>]

>>> On 21.04.15 at 15:38, <boris.ostrovsky@oracle.com> wrote:

> On 04/21/2015 03:53 AM, Jan Beulich wrote:
>>>>> On 20.04.15 at 18:38, <boris.ostrovsky@oracle.com> wrote:
>>> On 04/20/2015 04:50 AM, Jan Beulich wrote:
>>>>>>> On 09.04.15 at 17:44, <boris.ostrovsky@oracle.com> 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.
> 
> So I just realized that some of Intel PMU registers need to be audited 
> by the hypervisor before being loaded.
> 
> But to your statement that most of the fields are only written by 
> hypervisor -- all PMU-related registers that are part of this structure 
> are writeable by the guest. They are essentially deferred MSR writes by 
> the guest.

That's for the "pmu" sub-structure, but that's only one of the fields
of the main structure, which my comment referred to. In any event,
all fields of this structure (including all sub-structures) need to have
clear description of behavior: Who writes, who reads, and for any
field read by the hypervisor it needs to be made sure that the field
is read only once for any given operation and that (as you say
above) the data read (or at least the parts of it that actually will
get used - of the LVTPC value for example only the mask bit appears
to get used) is valid to be forwarded to hardware.

Jan