Please commit these patches. I can also put these on a git tree
(if you could create on for me on xenbits.org that is it) for a git pull.
The trace patches have been Acked-by George.
The documentation ones had been Acked-by Ian Campbell - some of
them implicitly b/c of this email correspondence:
http://mid.gmane.org/1363599867.30193.5.camel@zakaz.uk.xensource.com
where Ian said:
> I think this is the last posting of these? I believe we are just
> waiting for Jan to Ack the:
>
> [PATCH 5/6] docs: Document start_info changes in Xen 4.2.
>
> and otherwise they are ready to go?
I think so too.
Did you CC Jan?
The "docs: Document start_info changes in Xen 4.2" did get an Ack from
Jan and now they are all ready to go.
tools/xentrace/formats | 15 +++++++++++++--
xen/include/public/elfnote.h | 8 ++++++++
xen/include/public/features.h | 14 ++++++++++++++
xen/include/public/io/xs_wire.h | 5 ++++-
xen/include/public/xen.h | 22 ++++++++++++++++++++--
5 files changed, 59 insertions(+), 5 deletions(-)
Konrad Rzeszutek Wilk (11):
trace: Use correct trace class for power management changes.
trace: Add trace events for IRQ activities.
trace: Add the other variant of do_block.
trace: Add reason for NMI exit TRAP
docs: Document the ELF notes
docs: Document the ELF_FEATURES entry
docs: Add some extra details to the ELF note.
docs: Document the shared structure.
docs: Document the dom0_vga_console_info structure.
docs: Document start_info changes in Xen 4.2.
docs: Document the XenBus structure.
Konrad Rzeszutek Wilk
2013-Mar-25 14:41 UTC
[PATCH 01/11] trace: Use correct trace class for power management changes.
Previous to this patch we would see in the trace file: CPU28 1753503175371 (+ 8496) unknown (0x0000000000801002) [ 0x00000004 0x4158a498 0x000003a1 0x000027e6 0x00000000 0x00000000 0x00000000 ] CPU28 1753505321239 (+ 2145868) unknown (0x0000000000801003) [ 0x00000004 0x4166dca7 0x000000fa 0x00000000 0x00000000 0x00000000 0x00000000 ] CPU28 1753505343756 (+ 22517) unknown (0x0000000000801002) [ 0x00000004 0x41670fe5 0x00001284 0x00003766 0x00000000 0x00000000 0x00000000 ] CPU28 1753521413711 (+16069955) unknown (0x0000000000801003) [ 0x00000004 0x41d1e02c 0x000000ab 0x00000000 0x00000000 0x00000000 0x00000000 ] instead of: CPU28 1753503175371 (+ 8496) cpu_idle_entry [ C0 -> C4, acpi_pm_tick = 1096328344, expected = 929us, predicted = 10214us ] CPU28 1753505321239 (+ 2145868) cpu_idle_exit [ C4 -> C0, acpi_pm_tick = 1097260199, irq = 250 0 0 0 ] CPU28 1753505343756 (+ 22517) cpu_idle_entry [ C0 -> C4, acpi_pm_tick = 1097273317, expected = 4740us, predicted = 14182us ] CPU28 1753521413711 (+16069955) cpu_idle_exit [ C4 -> C0, acpi_pm_tick = 1104273452, irq = 171 0 0 0 ] The patch that added the cpu_idle_[entry|exit] was using the TRC_HW_IRQ class (0x00802000) instead of TRC_HW_PM (0x00801000) as a base. Acked-by: George Dunlap <george.dunlap@eu.citrix.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- tools/xentrace/formats | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/xentrace/formats b/tools/xentrace/formats index 928e1d7..b4e3d05 100644 --- a/tools/xentrace/formats +++ b/tools/xentrace/formats @@ -139,5 +139,5 @@ 0x0040f10f CPU%(cpu)d %(tsc)d (+%(reltsc)8d) shadow_emulate_resync_only [ gfn = 0x%(2)08x%(1)08x ] 0x00801001 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) cpu_freq_change [ %(1)dMHz -> %(2)dMHz ] -0x00802001 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) cpu_idle_entry [ C0 -> C%(1)d, acpi_pm_tick = %(2)d, expected = %(3)dus, predicted = %(4)dus ] -0x00802002 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) cpu_idle_exit [ C%(1)d -> C0, acpi_pm_tick = %(2)d, irq = %(3)d %(4)d %(5)d %(6)d ] +0x00801002 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) cpu_idle_entry [ C0 -> C%(1)d, acpi_pm_tick = %(2)d, expected = %(3)dus, predicted = %(4)dus ] +0x00801003 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) cpu_idle_exit [ C%(1)d -> C0, acpi_pm_tick = %(2)d, irq = %(3)d %(4)d %(5)d %(6)d ] -- 1.8.0.2
Konrad Rzeszutek Wilk
2013-Mar-25 14:41 UTC
[PATCH 02/11] trace: Add trace events for IRQ activities.
This expands the format to include the class of TRC_HW_IRQ. This means that instead of: CPU28 1753521436727 (+ 3252) unknown (0x0000000000802008) [ 0x0000006c 0x4605709c 0x4605b682 0x00000000 0x00000000 0x00000000 0x00000000 ] we now see: CPU28 1753521436727 (+ 3252) do_irq [ irq = 108, began = 1174761628us, ended = 1174779522us ] Acked-by: George Dunlap <george.dunlap@eu.citrix.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- tools/xentrace/formats | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/tools/xentrace/formats b/tools/xentrace/formats index b4e3d05..00f0263 100644 --- a/tools/xentrace/formats +++ b/tools/xentrace/formats @@ -141,3 +141,12 @@ 0x00801001 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) cpu_freq_change [ %(1)dMHz -> %(2)dMHz ] 0x00801002 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) cpu_idle_entry [ C0 -> C%(1)d, acpi_pm_tick = %(2)d, expected = %(3)dus, predicted = %(4)dus ] 0x00801003 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) cpu_idle_exit [ C%(1)d -> C0, acpi_pm_tick = %(2)d, irq = %(3)d %(4)d %(5)d %(6)d ] + +0x00802001 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) cleanup_move_delayed [ irq = %(1)d, vector 0x%(2)x on CPU%(3)d ] +0x00802002 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) cleanup_move [ irq = %(1)d, vector 0x%(2)x on CPU%(3)d ] +0x00802003 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) bind_vector [ irq = %(1)d = vector 0x%(2)x, CPU mask: 0x%(3)08x ] +0x00802004 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) clear_vector [ irq = %(1)d = vector 0x%(2)x, CPU mask: 0x%(3)08x ] +0x00802005 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) move_vector [ irq = %(1)d had vector 0x%(2)x on CPU%(3)d ] +0x00802006 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) assign_vector [ irq = %(1)d = vector 0x%(2)x, CPU mask: 0x%(3)08x ] +0x00802007 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) bogus_vector [ 0x%(1)x ] +0x00802008 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) do_irq [ irq = %(1)d, began = %(2)dus, ended = %(3)dus ] -- 1.8.0.2
Konrad Rzeszutek Wilk
2013-Mar-25 14:41 UTC
[PATCH 03/11] trace: Add the other variant of do_block.
Acked-by: George Dunlap <george.dunlap@eu.citrix.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- tools/xentrace/formats | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/xentrace/formats b/tools/xentrace/formats index 00f0263..5c26e21 100644 --- a/tools/xentrace/formats +++ b/tools/xentrace/formats @@ -25,6 +25,7 @@ 0x00028004 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) domain_wake [ domid = 0x%(1)08x, edomid = 0x%(2)08x ] 0x00028005 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) do_yield [ domid = 0x%(1)08x, edomid = 0x%(2)08x ] 0x00028006 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) do_block [ domid = 0x%(1)08x, edomid = 0x%(2)08x ] +0x00022006 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) do_block [ dom:vcpu = 0x%(1)08x, domid = 0x%(2)08x ] 0x00028007 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) domain_shutdown [ domid = 0x%(1)08x, edomid = 0x%(2)08x, reason = 0x%(3)08x ] 0x00028008 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) sched_ctl 0x00028009 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) sched_adjdom [ domid = 0x%(1)08x ] -- 1.8.0.2
Konrad Rzeszutek Wilk
2013-Mar-25 14:41 UTC
[PATCH 04/11] trace: Add reason for NMI exit TRAP
Acked-by: George Dunlap <george.dunlap@eu.citrix.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- tools/xentrace/formats | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/xentrace/formats b/tools/xentrace/formats index 5c26e21..67fd42d 100644 --- a/tools/xentrace/formats +++ b/tools/xentrace/formats @@ -78,6 +78,7 @@ 0x0008201a CPU%(cpu)d %(tsc)d (+%(reltsc)8d) RDTSC [ value = 0x%(2)08x%(1)08x ] 0x00082020 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) INTR_WINDOW [ value = 0x%(1)08x ] 0x00082021 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) NPF [ gpa = 0x%(2)08x%(1)08x mfn = 0x%(4)08x%(3)08x qual = 0x%(5)04x p2mt = 0x%(6)04x ] +0x00082023 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) TRAP [ vector = 0x%(1)02x ] 0x0010f001 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) page_grant_map [ domid = %(1)d ] 0x0010f002 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) page_grant_unmap [ domid = %(1)d ] -- 1.8.0.2
Mark-up for inclusion of generated docs. Acked-by: Ian Campbell <ian.campbel@citrix.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- xen/include/public/elfnote.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/xen/include/public/elfnote.h b/xen/include/public/elfnote.h index 6bc0c50..b7e4574 100644 --- a/xen/include/public/elfnote.h +++ b/xen/include/public/elfnote.h @@ -28,6 +28,8 @@ #define __XEN_PUBLIC_ELFNOTE_H__ /* + * `incontents 200 elfnotes ELF notes + * * The notes should live in a PT_NOTE segment and have "Xen" in the * name field. * -- 1.8.0.2
Konrad Rzeszutek Wilk
2013-Mar-25 14:41 UTC
[PATCH 06/11] docs: Document the ELF_FEATURES entry
Mark-up for inclusion of generated docs. Acked-by: Ian Campbell <ian.campbell@citrix.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- xen/include/public/features.h | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/xen/include/public/features.h b/xen/include/public/features.h index 5b70418..a149aa6 100644 --- a/xen/include/public/features.h +++ b/xen/include/public/features.h @@ -28,6 +28,20 @@ #define __XEN_PUBLIC_FEATURES_H__ /* + * `incontents 200 elfnotes_features XEN_ELFNOTE_FEATURES + * + * The list of all the features the guest supports. They are set by + * parsing the XEN_ELFNOTE_FEATURES and XEN_ELFNOTE_SUPPORTED_FEATURES + * string. The format is the feature names (as given here without the + * "XENFEAT_" prefix) separated by ''|'' characters. + * If a feature is required for the kernel to function then the feature name + * must be preceded by a ''!'' character. + * + * Note that if XEN_ELFNOTE_SUPPORTED_FEATURES is used, then in the + * XENFEAT_dom0 MUST be set if the guest is to be booted as dom0, + */ + +/* * If set, the guest does not need to write-protect its pagetables, and can * update them via direct writes. */ -- 1.8.0.2
Konrad Rzeszutek Wilk
2013-Mar-25 14:41 UTC
[PATCH 07/11] docs: Add some extra details to the ELF note.
Such as how the string values MUST be NULL terminated ASCII. Acked-by: Ian Campbell <ian.campbel@citrix.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- xen/include/public/elfnote.h | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/xen/include/public/elfnote.h b/xen/include/public/elfnote.h index b7e4574..8566a7e 100644 --- a/xen/include/public/elfnote.h +++ b/xen/include/public/elfnote.h @@ -38,6 +38,9 @@ * * LEGACY indicated the fields in the legacy __xen_guest string which * this a note type replaces. + * + * String values (for non-legacy) are NULL terminated ASCII, also known + * as ASCIZ type. */ /* @@ -160,6 +163,9 @@ /* * Whether or not the guest supports cooperative suspend cancellation. + * This is a numeric value. + * + * Default is 0 */ #define XEN_ELFNOTE_SUSPEND_CANCEL 14 -- 1.8.0.2
Konrad Rzeszutek Wilk
2013-Mar-25 14:41 UTC
[PATCH 08/11] docs: Document the shared structure.
Mark-up for inclusion of generated docs. Acked-by: Ian Campbell <ian.campbell@citrix.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- xen/include/public/xen.h | 1 + 1 file changed, 1 insertion(+) diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h index e9431e2..1091229 100644 --- a/xen/include/public/xen.h +++ b/xen/include/public/xen.h @@ -622,6 +622,7 @@ typedef struct vcpu_info vcpu_info_t; #endif /* + * `incontents 200 startofday_shared Start-of-day shared data structure * Xen/kernel shared data -- pointer provided in start_info. * * This structure is defined to be both smaller than a page, and the -- 1.8.0.2
Konrad Rzeszutek Wilk
2013-Mar-25 14:41 UTC
[PATCH 09/11] docs: Document the dom0_vga_console_info structure.
Mark-up for inclusion of generated docs.
Acked-by: Ian Campbell <ian.campbel@citrix.com>
[v2: s/dom9/dom0/]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
xen/include/public/xen.h | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 1091229..73fd7e7 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -779,7 +779,14 @@ struct xen_multiboot_mod_list
/* Unused, must be zero */
uint32_t pad;
};
-
+/*
+ * `incontents 200 startofday_dom0_console Dom0_console
+ *
+ * The console structure in start_info.console.dom0
+ *
+ * This structure includes a variety of information required to
+ * have a working VGA/VESA console.
+ */
typedef struct dom0_vga_console_info {
uint8_t video_type; /* DOM0_VGA_CONSOLE_??? */
#define XEN_VGATYPE_TEXT_MODE_3 0x03
--
1.8.0.2
Konrad Rzeszutek Wilk
2013-Mar-25 14:41 UTC
[PATCH 10/11] docs: Document start_info changes in Xen 4.2.
The 25833:bb85bbccb1c9. "x86/32-on-64: adjust Dom0 initial page table
layout"
fixes a bug in the reported value of pt_base versus where the page tables
actually start. This documents this in the start of the world header note.
This clarifies the implied understanding that the page table space is
pointed by pt_base. As in it is ".. implied that the range of page-tables
is the range [pt_base, pt_base + nr_pt_frames), whereas that that range
here indeed is [pt_base - 2, pt_base -2 + nr_pt_frames)" (Jan Beulich).
Also make it crystal clear that pt_base == %cr3.
Acked-by: Jan Beulich <JBeulich@suse.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
xen/include/public/xen.h | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 73fd7e7..4dd9615 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -693,7 +693,7 @@ typedef struct shared_info shared_info_t;
* c. list of allocated page frames [mfn_list, nr_pages]
* (unless relocated due to XEN_ELFNOTE_INIT_P2M)
* d. start_info_t structure [register ESI (x86)]
- * e. bootstrap page tables [pt_base, CR3 (x86)]
+ * e. bootstrap page tables [pt_base and CR3 (x86)]
* f. bootstrap stack [register ESP (x86)]
* 4. Bootstrap elements are packed together, but each is 4kB-aligned.
* 5. The initial ram disk may be omitted.
@@ -705,6 +705,16 @@ typedef struct shared_info shared_info_t;
* 8. There is guaranteed to be at least 512kB padding after the final
* bootstrap element. If necessary, the bootstrap virtual region is
* extended by an extra 4MB to ensure this.
+ *
+ * Note: Prior to 25833:bb85bbccb1c9. ("x86/32-on-64 adjust Dom0 initial
page
+ * table layout") a bug caused the pt_base (3.e above) and cr3 to not
point
+ * to the start of the guest page tables (it was offset by two pages).
+ * This only manifested itself on 32-on-64 dom0 kernels and not 32-on-64 domU
+ * or 64-bit kernels of any colour. The page tables for a 32-on-64 dom0 got
+ * allocated in the order: ''first L1'',''first
L2'', ''first L3'', so the offset
+ * to the page table base is by two pages back. The initial domain if it is
+ * 32-bit and runs under a 64-bit hypervisor should _NOT_ use two of the
+ * pages preceding pt_base and mark them as reserved/unused.
*/
#define MAX_GUEST_CMDLINE 1024
--
1.8.0.2
Konrad Rzeszutek Wilk
2013-Mar-25 14:41 UTC
[PATCH 11/11] docs: Document the XenBus structure.
Mark-up for inclusion of generated docs.
Acked-by: Ian Campbell <ian.campbel@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
xen/include/public/io/xs_wire.h | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/xen/include/public/io/xs_wire.h b/xen/include/public/io/xs_wire.h
index 36ff33c..99d24e3 100644
--- a/xen/include/public/io/xs_wire.h
+++ b/xen/include/public/io/xs_wire.h
@@ -103,7 +103,10 @@ enum xs_watch_type
XS_WATCH_TOKEN
};
-/* Inter-domain shared memory communications. */
+/*
+ * `incontents 150 xenstore_struct XenStore wire protocol.
+ *
+ * Inter-domain shared memory communications. */
#define XENSTORE_RING_SIZE 1024
typedef uint32_t XENSTORE_RING_IDX;
#define MASK_XENSTORE_IDX(idx) ((idx) & (XENSTORE_RING_SIZE-1))
--
1.8.0.2
>>> On 25.03.13 at 15:41, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: > Please commit these patches. I can also put these on a git tree > (if you could create on for me on xenbits.org that is it) for a git pull. > > > The trace patches have been Acked-by George.You know what - I didn''t apply them precisely because the ack came through only for patches 3 and 4. I just checked the xen-devel archives again, and that''s the state of affairs right now too. Possibly the ack was sent to you without Cc-ing xen-devel, but that doesn''t allow me to apply them. Jan
On 25/03/13 15:13, Jan Beulich wrote:>>>> On 25.03.13 at 15:41, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: >> Please commit these patches. I can also put these on a git tree >> (if you could create on for me on xenbits.org that is it) for a git pull. >> >> >> The trace patches have been Acked-by George. > You know what - I didn''t apply them precisely because the ack > came through only for patches 3 and 4. I just checked the > xen-devel archives again, and that''s the state of affairs right > now too. Possibly the ack was sent to you without Cc-ing > xen-devel, but that doesn''t allow me to apply them.Is that because I had already Ack-ed an earlier version of the same patches, as noted right above Konrad''s S-o-B line? I''m not 100% sure the normal protocol, but Konrad has been around the block a few times; I would think that if Konrad put my Ack-by on something, then that should have the presumption of validity -- particularly if he cc''d me (which he did) and I didn''t nack it. -George
>>> On 25.03.13 at 16:37, George Dunlap <george.dunlap@eu.citrix.com> wrote: > On 25/03/13 15:13, Jan Beulich wrote: >>>>> On 25.03.13 at 15:41, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: >>> Please commit these patches. I can also put these on a git tree >>> (if you could create on for me on xenbits.org that is it) for a git pull. >>> >>> >>> The trace patches have been Acked-by George. >> You know what - I didn''t apply them precisely because the ack >> came through only for patches 3 and 4. I just checked the >> xen-devel archives again, and that''s the state of affairs right >> now too. Possibly the ack was sent to you without Cc-ing >> xen-devel, but that doesn''t allow me to apply them. > > Is that because I had already Ack-ed an earlier version of the same > patches, as noted right above Konrad''s S-o-B line?I must have overlooked that, partly because I expect Acked-by to be below Signed-off-by (only Reported-by goes ahead of it in my opinion, to reflect work/event flow).> I''m not 100% sure the normal protocol, but Konrad has been around the > block a few times; I would think that if Konrad put my Ack-by on > something, then that should have the presumption of validity -- > particularly if he cc''d me (which he did) and I didn''t nack it.I see now that he Cc-ed you on the post from the 18th, but I specifically noted that he didn''t Cc you on the resubmission today. Which together with me not having noticed the earlier ack made things look inconsistent/incomplete. Anyway - going to apply those now. Jan
On Mon, Mar 25, 2013 at 3:48 PM, Jan Beulich <JBeulich@suse.com> wrote:>>>> On 25.03.13 at 16:37, George Dunlap <george.dunlap@eu.citrix.com> wrote: >> On 25/03/13 15:13, Jan Beulich wrote: >>>>>> On 25.03.13 at 15:41, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: >>>> Please commit these patches. I can also put these on a git tree >>>> (if you could create on for me on xenbits.org that is it) for a git pull. >>>> >>>> >>>> The trace patches have been Acked-by George. >>> You know what - I didn''t apply them precisely because the ack >>> came through only for patches 3 and 4. I just checked the >>> xen-devel archives again, and that''s the state of affairs right >>> now too. Possibly the ack was sent to you without Cc-ing >>> xen-devel, but that doesn''t allow me to apply them. >> >> Is that because I had already Ack-ed an earlier version of the same >> patches, as noted right above Konrad''s S-o-B line? > > I must have overlooked that, partly because I expect Acked-by > to be below Signed-off-by (only Reported-by goes ahead of it in > my opinion, to reflect work/event flow). > >> I''m not 100% sure the normal protocol, but Konrad has been around the >> block a few times; I would think that if Konrad put my Ack-by on >> something, then that should have the presumption of validity -- >> particularly if he cc''d me (which he did) and I didn''t nack it. > > I see now that he Cc-ed you on the post from the 18th, but I > specifically noted that he didn''t Cc you on the resubmission > today. Which together with me not having noticed the earlier > ack made things look inconsistent/incomplete.Ah, right -- which is also why I didn''t notice that he had re-sent the patch series. :-) Konrad, are you not using "git send-email"? I thought it normally added cc''s for Acked-by''s... -George
On Mon, Mar 25, 2013 at 03:48:33PM +0000, Jan Beulich wrote:> >>> On 25.03.13 at 16:37, George Dunlap <george.dunlap@eu.citrix.com> wrote: > > On 25/03/13 15:13, Jan Beulich wrote: > >>>>> On 25.03.13 at 15:41, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: > >>> Please commit these patches. I can also put these on a git tree > >>> (if you could create on for me on xenbits.org that is it) for a git pull. > >>> > >>> > >>> The trace patches have been Acked-by George. > >> You know what - I didn''t apply them precisely because the ack > >> came through only for patches 3 and 4. I just checked the > >> xen-devel archives again, and that''s the state of affairs right > >> now too. Possibly the ack was sent to you without Cc-ing > >> xen-devel, but that doesn''t allow me to apply them. > > > > Is that because I had already Ack-ed an earlier version of the same > > patches, as noted right above Konrad''s S-o-B line? > > I must have overlooked that, partly because I expect Acked-by > to be below Signed-off-by (only Reported-by goes ahead of it in > my opinion, to reflect work/event flow).Oh, that would be a different workflow than with Linux, where Acked-by has to be above the SOB. The SOB of the last person posting it has to be at the bottom - as that identifies who was the last person touching / sending from a git tree.> > > I''m not 100% sure the normal protocol, but Konrad has been around the > > block a few times; I would think that if Konrad put my Ack-by on > > something, then that should have the presumption of validity -- > > particularly if he cc''d me (which he did) and I didn''t nack it.Right - it was done in two waves. The first two you Acked. Then a couple of days later I sent the other two - you Acked them too. And bundled up nicely I sent them out today.> > I see now that he Cc-ed you on the post from the 18th, but I > specifically noted that he didn''t Cc you on the resubmission > today. Which together with me not having noticed the earlier > ack made things look inconsistent/incomplete.Ah> > Anyway - going to apply those now.Thank you!> > Jan >
>>> On 25.03.13 at 17:46, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: > On Mon, Mar 25, 2013 at 03:48:33PM +0000, Jan Beulich wrote: >> >>> On 25.03.13 at 16:37, George Dunlap <george.dunlap@eu.citrix.com> wrote: >> > On 25/03/13 15:13, Jan Beulich wrote: >> >>>>> On 25.03.13 at 15:41, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: >> >>> Please commit these patches. I can also put these on a git tree >> >>> (if you could create on for me on xenbits.org that is it) for a git pull. >> >>> >> >>> >> >>> The trace patches have been Acked-by George. >> >> You know what - I didn''t apply them precisely because the ack >> >> came through only for patches 3 and 4. I just checked the >> >> xen-devel archives again, and that''s the state of affairs right >> >> now too. Possibly the ack was sent to you without Cc-ing >> >> xen-devel, but that doesn''t allow me to apply them. >> > >> > Is that because I had already Ack-ed an earlier version of the same >> > patches, as noted right above Konrad''s S-o-B line? >> >> I must have overlooked that, partly because I expect Acked-by >> to be below Signed-off-by (only Reported-by goes ahead of it in >> my opinion, to reflect work/event flow). > > Oh, that would be a different workflow than with Linux, where > Acked-by has to be above the SOB.I just checked current SubmittingPatches and didn''t spot any such rule.> The SOB of the last person posting it has to be at the bottom - as that > identifies who was the last person touching / sending from a git > tree.Yes - workflow based. Looking at the 3.8.1 change log (arbitrarily picked) I see no strict ordering either, and to me it just makes sense to apply the workflow principle here too (Reported -> Signed-off [-> {Acked|Reviewed|Tested|Signed-off}, ...]. Jan
On Mon, Mar 25, 2013 at 04:43:24PM +0000, George Dunlap wrote:> On Mon, Mar 25, 2013 at 3:48 PM, Jan Beulich <JBeulich@suse.com> wrote: > >>>> On 25.03.13 at 16:37, George Dunlap <george.dunlap@eu.citrix.com> wrote: > >> On 25/03/13 15:13, Jan Beulich wrote: > >>>>>> On 25.03.13 at 15:41, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: > >>>> Please commit these patches. I can also put these on a git tree > >>>> (if you could create on for me on xenbits.org that is it) for a git pull. > >>>> > >>>> > >>>> The trace patches have been Acked-by George. > >>> You know what - I didn''t apply them precisely because the ack > >>> came through only for patches 3 and 4. I just checked the > >>> xen-devel archives again, and that''s the state of affairs right > >>> now too. Possibly the ack was sent to you without Cc-ing > >>> xen-devel, but that doesn''t allow me to apply them. > >> > >> Is that because I had already Ack-ed an earlier version of the same > >> patches, as noted right above Konrad''s S-o-B line? > > > > I must have overlooked that, partly because I expect Acked-by > > to be below Signed-off-by (only Reported-by goes ahead of it in > > my opinion, to reflect work/event flow). > > > >> I''m not 100% sure the normal protocol, but Konrad has been around the > >> block a few times; I would think that if Konrad put my Ack-by on > >> something, then that should have the presumption of validity -- > >> particularly if he cc''d me (which he did) and I didn''t nack it. > > > > I see now that he Cc-ed you on the post from the 18th, but I > > specifically noted that he didn''t Cc you on the resubmission > > today. Which together with me not having noticed the earlier > > ack made things look inconsistent/incomplete. > > Ah, right -- which is also why I didn''t notice that he had re-sent the > patch series. :-) > > Konrad, are you not using "git send-email"? I thought it normallyI am.> added cc''s for Acked-by''s...It usually does. Wonder if I accidently hit the ''n'' key when it asks me whether to add those emails to it.> > -George
On Mon, Mar 25, 2013 at 05:20:45PM +0000, Jan Beulich wrote:> >>> On 25.03.13 at 17:46, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: > > On Mon, Mar 25, 2013 at 03:48:33PM +0000, Jan Beulich wrote: > >> >>> On 25.03.13 at 16:37, George Dunlap <george.dunlap@eu.citrix.com> wrote: > >> > On 25/03/13 15:13, Jan Beulich wrote: > >> >>>>> On 25.03.13 at 15:41, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: > >> >>> Please commit these patches. I can also put these on a git tree > >> >>> (if you could create on for me on xenbits.org that is it) for a git pull. > >> >>> > >> >>> > >> >>> The trace patches have been Acked-by George. > >> >> You know what - I didn''t apply them precisely because the ack > >> >> came through only for patches 3 and 4. I just checked the > >> >> xen-devel archives again, and that''s the state of affairs right > >> >> now too. Possibly the ack was sent to you without Cc-ing > >> >> xen-devel, but that doesn''t allow me to apply them. > >> > > >> > Is that because I had already Ack-ed an earlier version of the same > >> > patches, as noted right above Konrad''s S-o-B line? > >> > >> I must have overlooked that, partly because I expect Acked-by > >> to be below Signed-off-by (only Reported-by goes ahead of it in > >> my opinion, to reflect work/event flow). > > > > Oh, that would be a different workflow than with Linux, where > > Acked-by has to be above the SOB. > > I just checked current SubmittingPatches and didn''t spot any > such rule.Ha! You expect this to be documented ! :-)> > > The SOB of the last person posting it has to be at the bottom - as that > > identifies who was the last person touching / sending from a git > > tree. > > Yes - workflow based. Looking at the 3.8.1 change log (arbitrarily > picked) I see no strict ordering either, and to me it just makes > sense to apply the workflow principle here too (Reported -> > Signed-off [-> {Acked|Reviewed|Tested|Signed-off}, ...].So digging through my mail archive I found this from Ingo: (Re: [GIT PULL] x86/mce fix (ready for 3.6 merge window) We tend to use such an ordering of tags: Signed-off-by: Tony Luck <tony.luck@intel.com> Acked-by: Borislav Petkov <borislav.petkov@amd.com> Cc: stable@kernel.org # 3.4+ I.e. Tested-by and Reported-by tags first (if any), then author SOB, then SOB chain (if any), then Reviewed-by and Acked-by, then stable tags, then Cc:s. (I fix this up silently for email space patches, for Git pulls I cannot do that.) which would imply that the author''s SOB is at the top - which is what you pointed out. Perhaps I was thinking about this one and get the order wrong. But I am pretty sure I saw somebody mention this the other way around. Maybe it was Randy or Linus said it somewhere. Anyhow, at this point I am just going to go with what you deem the right way.
Konrad Rzeszutek Wilk writes ("[PATCH] docs/traces Acked patches.
"):> Please commit these patches. I can also put these on a git tree
> (if you could create on for me on xenbits.org that is it) for a git pull.
Please do put them in a git tree. You can make one yourself using
your shell account on xenbits.
You''ll need to put your git trees in ~/ext (as bare repos). And also
you''ll need to make your home directory at least a+x. I have just set
up the symlink that will publish your ~/ext via the git daemon and
gitweb.
Thanks,
Ian.
On Tue, Mar 26, 2013 at 04:28:39PM +0000, Ian Jackson wrote:> Konrad Rzeszutek Wilk writes ("[PATCH] docs/traces Acked patches. "): > > Please commit these patches. I can also put these on a git tree > > (if you could create on for me on xenbits.org that is it) for a git pull. > > Please do put them in a git tree. You can make one yourself using > your shell account on xenbits.Done. Please git pull the following branch: git://xenbits.xen.org/people/konradwilk/xen.git docs.v3 which has these patches since git commit babea0a412ee24a94ed0bd03543060b2c6bc0bbd (trace: Add reason for NMI exit TRAP): xen/include/public/elfnote.h | 8 ++++++++ xen/include/public/features.h | 14 ++++++++++++++ xen/include/public/io/xs_wire.h | 5 ++++- xen/include/public/xen.h | 22 ++++++++++++++++++++-- 4 files changed, 46 insertions(+), 3 deletions(-) Konrad Rzeszutek Wilk (7): docs: Document the ELF notes docs: Document the ELF_FEATURES entry docs: Add some extra details to the ELF note. docs: Document the shared structure. docs: Document the dom0_vga_console_info structure. docs: Document start_info changes in Xen 4.2. docs: Document the XenBus structure. Thank you.
Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] [PATCH] docs/traces Acked
patches."):> Done.
>
> Please git pull the following branch:
>
> git://xenbits.xen.org/people/konradwilk/xen.git docs.v3
>
> which has these patches since git commit
babea0a412ee24a94ed0bd03543060b2c6bc0bbd
> (trace: Add reason for NMI exit TRAP):
Great, thanks. I did this with a pull (and thus, a merge) rather than
a rebase.
I mention this to see if the other committers object to the nonlinear
history.
Ian.
On Thu, Mar 28, 2013 at 04:00:30PM +0000, Ian Jackson wrote:> Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] [PATCH] docs/traces Acked patches."): > > Done. > > > > Please git pull the following branch: > > > > git://xenbits.xen.org/people/konradwilk/xen.git docs.v3 > > > > which has these patches since git commit babea0a412ee24a94ed0bd03543060b2c6bc0bbd > > (trace: Add reason for NMI exit TRAP): > > Great, thanks. I did this with a pull (and thus, a merge) rather than > a rebase.Woohoo! First ever git pull in the Xen tree :-)> > I mention this to see if the other committers object to the nonlinear > history. > > Ian.
On Mon, 2013-03-25 at 16:46 +0000, Konrad Rzeszutek Wilk wrote:> On Mon, Mar 25, 2013 at 03:48:33PM +0000, Jan Beulich wrote: > > >>> On 25.03.13 at 16:37, George Dunlap <george.dunlap@eu.citrix.com> wrote: > > > On 25/03/13 15:13, Jan Beulich wrote: > > >>>>> On 25.03.13 at 15:41, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: > > >>> Please commit these patches. I can also put these on a git tree > > >>> (if you could create on for me on xenbits.org that is it) for a git pull. > > >>> > > >>> > > >>> The trace patches have been Acked-by George. > > >> You know what - I didn''t apply them precisely because the ack > > >> came through only for patches 3 and 4. I just checked the > > >> xen-devel archives again, and that''s the state of affairs right > > >> now too. Possibly the ack was sent to you without Cc-ing > > >> xen-devel, but that doesn''t allow me to apply them. > > > > > > Is that because I had already Ack-ed an earlier version of the same > > > patches, as noted right above Konrad''s S-o-B line? > > > > I must have overlooked that, partly because I expect Acked-by > > to be below Signed-off-by (only Reported-by goes ahead of it in > > my opinion, to reflect work/event flow). > > Oh, that would be a different workflow than with Linux, where > Acked-by has to be above the SOB.Really? My impression of the Linux norm is that the various *-by are in roughly chronological order (reading downwards, i.e. the list is sort of append only), a quick glance through git log on linux.git confirms this. e.g. it general looks like: Reported-by: A. Tester <a.tester@example.com> Signed-off-by: T. He. Author <author@example.com> Acked-by: Driver Maintainer <ssm@example.com> Tested-by: A. Tester <a.tester@example.com> Signed-off-by: Subsys Maintainer... Where A. Tester reported an issue, T. He. Author fixed it, the driver maintainer acked it, the reporter tested it and the subsystem maintainer picked it up to forward it on. So since you authored this patch and the George acked it your S-o-b should be followed by George''s ack. If a subsystem maintainer were to pick up the patch and forward it on then their S-o-b would go after Georges ack. Ian.