>>> On 21.05.15 at 19:57, <boris.ostrov...@oracle.com> wrote:
> --- a/xen/include/public/arch-arm.h
> +++ b/xen/include/public/arch-arm.h
> @@ -434,6 +434,11 @@ struct xen_arch_domainconfig {
>
> #endif
>
> +#ifndef __ASSEMBLY__
> +/* Stub definition of PMU structure */
> +typedef struct xen_pmu_arch {} xen_pmu_arch_t;
I'm afraid structures without members aren't standard C, so this
needs a dummy field as being in a public interface. I'm sorry for
not noticing this earlier.
> +/*
> + * Architecture-specific information describing state of the processor at
> + * the time of PMU interrupt.
> + * Fields of this structure marked as RW for guest can only be written by the
s/can/should/ ?
> + * 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?
With these adjusted, Acked-by: Jan Beulich <jbeul...@suse.com>.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
