[PATCH] docs/traces Acked patches.

[PATCH] docs/traces Acked patches.

[Konrad Rzeszutek Wilk]

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.

[PATCH 01/11] trace: Use correct trace class for power management changes.

[Konrad Rzeszutek Wilk]

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

[PATCH 02/11] trace: Add trace events for IRQ activities.

[Konrad Rzeszutek Wilk]

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

[PATCH 03/11] trace: Add the other variant of do_block.

[Konrad Rzeszutek Wilk]

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

[PATCH 04/11] trace: Add reason for NMI exit TRAP

[Konrad Rzeszutek Wilk]

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

[PATCH 05/11] docs: Document the ELF notes

[Konrad Rzeszutek Wilk]

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

[PATCH 06/11] docs: Document the ELF_FEATURES entry

[Konrad Rzeszutek Wilk]

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

[PATCH 07/11] docs: Add some extra details to the ELF note.

[Konrad Rzeszutek Wilk]

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

[PATCH 08/11] docs: Document the shared structure.

[Konrad Rzeszutek Wilk]

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

[PATCH 09/11] docs: Document the dom0_vga_console_info structure.

[Konrad Rzeszutek Wilk]

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

[PATCH 10/11] docs: Document start_info changes in Xen 4.2.

[Konrad Rzeszutek Wilk]

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

[PATCH 11/11] docs: Document the XenBus structure.

[Konrad Rzeszutek Wilk]

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

Re: [PATCH] docs/traces Acked patches.

[Jan Beulich]

>>> 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

Re: [PATCH] docs/traces Acked patches.

[George Dunlap]

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

Re: [PATCH] docs/traces Acked patches.

[Jan Beulich]

>>> 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

Re: [PATCH] docs/traces Acked patches.

[George Dunlap]

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

Re: [PATCH] docs/traces Acked patches.

[Konrad Rzeszutek Wilk]

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
> 

Re: [PATCH] docs/traces Acked patches.

[Jan Beulich]

>>> 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

Re: [PATCH] docs/traces Acked patches.

[Konrad Rzeszutek Wilk]

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 normally

I 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

Re: [PATCH] docs/traces Acked patches.

[Konrad Rzeszutek Wilk]

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.

Re: [PATCH] docs/traces Acked patches.

[Ian Jackson]

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.

Re: [PATCH] docs/traces Acked patches.

[Konrad Rzeszutek Wilk]

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.

Re: [PATCH] docs/traces Acked patches.

[Ian Jackson]

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.

Re: [PATCH] docs/traces Acked patches.

[Konrad Rzeszutek Wilk]

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.

Re: [PATCH] docs/traces Acked patches.

[Ian Campbell]

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.