Re: [PATCH v22 02/14] x86/VPMU: Add public xenpmu.h

[Boris Ostrovsky <boris.ostrovsky@oracle.com>]

On 05/26/2015 12:13 PM, Jan Beulich wrote:
>>>> On 21.05.15 at 19:57, <boris.ostrovsky@oracle.com> wrote:
>>
>> + * guest when PMU_CACHED bit in pmu_flags is set (which is done by the
>> + * hypervisor during PMU interrupt). Hypervisor will read updated data in
>> + * XENPMU_flush hypercall and clear PMU_CACHED bit.
>> + */
>> +struct xen_pmu_arch {
>> +    union {
>> +        /*
>> +         * Processor's registers at the time of interrupt.
>> +         * WO for hypervisor, RO for guests.
>> +         */
>> +        struct xen_pmu_regs regs;
>> +        /* Padding for adding new registers to xen_pmu_regs in the future */
>> +#define XENPMU_REGS_PAD_SZ  64
>> +        uint8_t pad[XENPMU_REGS_PAD_SZ];
>> +    } r;
>> +
>> +    /* WO for hypervisor, RO for guest */
>> +    uint64_t pmu_flags;
>> +
>> +    /*
>> +     * APIC LVTPC register.
>> +     * RW for both hypervisor and guest.
>> +     * Only APIC_LVT_MASKED bit is loaded by the hypervisor into hardware
>> +     * during XENPMU_flush or XENPMU_lvtpc_set.
>> +     */
>> +    union {
>> +        uint32_t lapic_lvtpc;
> Considering this isn't being used in this patch, could I ask you to
> move it where it is being used (keeping only the pad member and
> perhaps a placeholder comment here), so verifying that the
> read-once requirement for the hypervisor side is met becomes
> more obvious?

I can certainly delay defining this field until later patch but how is 
this filed different from xen_pmu_arch (not seen here) which is also 
read-once? Wouldn't you then want to have that definition deferred as well?

-boris

>
> With these adjusted, Acked-by: Jan Beulich <jbeulich@suse.com>.
>