Re: [Xen-devel] [PATCH v22 02/14] x86/VPMU: Add public xenpmu.h
On 05/27/2015 08:28 AM, Jan Beulich wrote:
On 26.05.15 at 19:50, boris.ostrov...@oracle.com wrote:
On 05/26/2015 12:13 PM, Jan Beulich wrote:
On 21.05.15 at 19:57, boris.ostrov...@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?
I'm confused - the only xen_pmu_arch I see in this patch is
struct xen_pmu_arch (and its uses), which the field above is
actually part of, and which is also visible in the context above. So
I doubt that's what you're referring to. But yes, fields with read-
once requirements would better be defined in the patch(es) using
them, so reviewers don't need to hunt them down.
Sorry, I meant amd/intel members of the union below (I forgot we were
already in the arch header file):
+/*
+ * Vendor-specific PMU registers.
+ * RW for both hypervisor and guest.
+ * Guest's updates to this field are verified and then loaded by the
+ * hypervisor into hardware during XENPMU_flush
+ */
+union {
+struct xen_pmu_amd_ctxt amd;
+struct xen_pmu_intel_ctxt intel;
+
+/*
+ * Padding for contexts (fixed parts only, does not include MSR
banks
+ * that are specified by offsets)
+ */
+#define XENPMU_CTXT_PAD_SZ 128
+uint8_t pad[XENPMU_CTXT_PAD_SZ];
+} c;
+};
I think they are first used in patch 11 so I assume you also want me to
just keep the pad here (with a comment explaining why it is here) until
that patch.
-boris
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v22 02/14] x86/VPMU: Add public xenpmu.h
On 26.05.15 at 19:50, boris.ostrov...@oracle.com wrote:
On 05/26/2015 12:13 PM, Jan Beulich wrote:
On 21.05.15 at 19:57, boris.ostrov...@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?
I'm confused - the only xen_pmu_arch I see in this patch is
struct xen_pmu_arch (and its uses), which the field above is
actually part of, and which is also visible in the context above. So
I doubt that's what you're referring to. But yes, fields with read-
once requirements would better be defined in the patch(es) using
them, so reviewers don't need to hunt them down.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v22 02/14] x86/VPMU: Add public xenpmu.h
On 27.05.15 at 17:18, boris.ostrov...@oracle.com wrote:
On 05/27/2015 10:26 AM, Jan Beulich wrote:
On 27.05.15 at 15:44, boris.ostrov...@oracle.com wrote:
Sorry, I meant amd/intel members of the union below (I forgot we were
already in the arch header file):
+/*
+ * Vendor-specific PMU registers.
+ * RW for both hypervisor and guest.
+ * Guest's updates to this field are verified and then loaded by the
+ * hypervisor into hardware during XENPMU_flush
+ */
+union {
+struct xen_pmu_amd_ctxt amd;
+struct xen_pmu_intel_ctxt intel;
+
+/*
+ * Padding for contexts (fixed parts only, does not include MSR
banks
+ * that are specified by offsets)
+ */
+#define XENPMU_CTXT_PAD_SZ 128
+uint8_t pad[XENPMU_CTXT_PAD_SZ];
+} c;
+};
I think they are first used in patch 11 so I assume you also want me to
just keep the pad here (with a comment explaining why it is here) until
that patch.
Ah, those ones I simply recalled having checked in the previous
version already.
But should they they also not be defined until later patch, to be
consistent with how lapic_lvtpc's definition is deferred?
I think that would be better.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v22 02/14] x86/VPMU: Add public xenpmu.h
On 27.05.15 at 15:44, boris.ostrov...@oracle.com wrote:
Sorry, I meant amd/intel members of the union below (I forgot we were
already in the arch header file):
+/*
+ * Vendor-specific PMU registers.
+ * RW for both hypervisor and guest.
+ * Guest's updates to this field are verified and then loaded by the
+ * hypervisor into hardware during XENPMU_flush
+ */
+union {
+struct xen_pmu_amd_ctxt amd;
+struct xen_pmu_intel_ctxt intel;
+
+/*
+ * Padding for contexts (fixed parts only, does not include MSR banks
+ * that are specified by offsets)
+ */
+#define XENPMU_CTXT_PAD_SZ 128
+uint8_t pad[XENPMU_CTXT_PAD_SZ];
+} c;
+};
I think they are first used in patch 11 so I assume you also want me to
just keep the pad here (with a comment explaining why it is here) until
that patch.
Ah, those ones I simply recalled having checked in the previous
version already.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v22 02/14] x86/VPMU: Add public xenpmu.h
On 05/26/2015 12:13 PM, Jan Beulich wrote:
On 21.05.15 at 19:57, boris.ostrov...@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 jbeul...@suse.com.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v22 02/14] x86/VPMU: Add public xenpmu.h
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
