[PATCH for-4.10 0/9] SUPPORT.md backports to support matrix generation

[PATCH for-4.10 0/9] SUPPORT.md backports to support matrix generation

[Ian Jackson]

This is a backport of my two recent series to fix bugs in SUPPORT.md,
format it as part of the published docs, and use relative position of
the `Status' stanza compared to descriptive text to indicate whether
the text is a caveat that deserves a footnote.

Most of this is uncontroversial and I have run the build and checked
that the resulting index.html is good.

It would be good if someone could review particularly the way I
resolved the conflicts in the big patch to SUPPORT.md, ie in
  [PATCH 8/9] SUPPORT.md: Move descriptions up before Status info

The result for 4.10's
SUPPORT.md is here:
  https://xenbits.xen.org/people/iwj/2018/support-matrix-example-C/SUPPORT.html

I have also checked that (with the patch I am about to send for
staging's parse-support-md) that this generates a sensible-looking
support matrix.  The resulting support matrix can be found here:
  https://xenbits.xen.org/people/iwj/2018/support-matrix-example-C/t.html
(The hyperlink references for staging are to the live xenbits version;
the references for 4.10 are to the example output file mentioned above.)

I have squashed the fix to not depend on HTML::TreeBuilder::XPath into
the patch that introduces the dependency.

For my reference, this was made as follows:
  docs/support-matrix-generate -D HEAD https://xenbits.xen.org/docs/unstable-staging/SUPPORT.html refs/heads/wip.support-stmt-NN-2 SUPPORT.html 2>&1 >docs/html/t.html |less
  rsync -LvP docs/html/{t,SUPPORT}.html xenbits:public_html/2018/support-matrix-example-C

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH 1/9] SUPPORT.md: Syntax: Fix some bullet lists

[Ian Jackson]

Continuations of bullet list items must be indented by exactly 4
spaces (according to pandoc_markdown(5) on Debian jessie).

This is most easily achieved by making the bullet list items have two
spaces before the `*'.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Release-acked-by: Juergen Gross <jgross@suse.com>
Acked-by: George Dunlap <george.dunlap@citrix.com>
Acked-by: Lars Kurth <lars.kurth@citrix.com>
(cherry picked from commit 01143b6273bc35a35afde154b2bb2415941bea89)
---
 SUPPORT.md | 36 ++++++++++++++++++------------------
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/SUPPORT.md b/SUPPORT.md
index cb862b5..4f69ed6 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -770,40 +770,40 @@ What is the risk of it exhibiting bugs?
 
 General answers to the above:
 
- * **Here be dragons**
+  * **Here be dragons**
 
-   Pretty likely to still crash / fail to work.
-   Not recommended unless you like life on the bleeding edge.
+    Pretty likely to still crash / fail to work.
+    Not recommended unless you like life on the bleeding edge.
 
- * **Quirky**
+  * **Quirky**
 
-   Mostly works but may have odd behavior here and there.
-   Recommended for playing around or for non-production use cases.
+    Mostly works but may have odd behavior here and there.
+    Recommended for playing around or for non-production use cases.
 
- * **Normal**
+  * **Normal**
 
-   Ready for production use
+    Ready for production use
 
 ### Interface stability
 
 If I build a system based on the current interfaces,
 will they still work when I upgrade to the next version?
 
- * **Not stable**
+  * **Not stable**
 
-   Interface is still in the early stages and
-   still fairly likely to be broken in future updates.
+    Interface is still in the early stages and
+    still fairly likely to be broken in future updates.
 
- * **Provisionally stable**
+  * **Provisionally stable**
 
-   We're not yet promising backwards compatibility,
-   but we think this is probably the final form of the interface.
-   It may still require some tweaks.
+    We're not yet promising backwards compatibility,
+    but we think this is probably the final form of the interface.
+    It may still require some tweaks.
 
- * **Stable**
+  * **Stable**
 
-   We will try very hard to avoid breaking backwards  compatibility,
-   and to fix any regressions that are reported.
+    We will try very hard to avoid breaking backwards  compatibility,
+    and to fix any regressions that are reported.
 
 ### Security supported
 
-- 
2.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH 2/9] SUPPORT.md: Syntax: Fix a typo "States"

[Ian Jackson]

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Release-acked-by: Juergen Gross <jgross@suse.com>
Acked-by: George Dunlap <george.dunlap@citrix.com>
Acked-by: Lars Kurth <lars.kurth@citrix.com>
(cherry picked from commit ebbd0299089a698c39d4ced966df5831944b4305)
---
 SUPPORT.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/SUPPORT.md b/SUPPORT.md
index 4f69ed6..92c6a2c 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -357,7 +357,7 @@ Guest-side driver capable of speaking the Xen PV block protocol
     Status, FreeBSD: Supported, Security support external
     Status, NetBSD: Supported, Security support external
     Status, OpenBSD: Supported, Security support external
-    States, Windows: Supported
+    Status, Windows: Supported
 
 Guest-side driver capable of speaking the Xen PV networking protocol
 
-- 
2.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH 3/9] SUPPORT.md: Syntax: Provide a title rather than a spurious empty section

[Ian Jackson]

This commits (more or less) this file to be processed with pandoc,
rather than other markdown processors.  There is, unfortunately, no
widely-accepted way to declare a title for the document.

I tested feeding the document to markdown(1) on Debian jessie and it
reproduced the % line as if it were simple text.  I guess many other
markdown processors will do something similarly tolerable.  My
internet searches did not discover a markdown processor that used
lines starting with % for something else.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Release-acked-by: Juergen Gross <jgross@suse.com>
Acked-by: George Dunlap <george.dunlap@citrix.com>
Acked-by: Lars Kurth <lars.kurth@citrix.com>
(cherry picked from commit a569c6f815fb6a18c64b8f122f5e2bbecd444432)
---
 SUPPORT.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/SUPPORT.md b/SUPPORT.md
index 92c6a2c..201e5a3 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -1,4 +1,4 @@
-# Support statement for this release
+% Support statement for this release
 
 This document describes the support status
 and in particular the security support status of the Xen branch
-- 
2.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH 4/9] docs/gen-html-index: Extract titles from HTML documents

[Ian Jackson]

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Release-acked-by: Juergen Gross <jgross@suse.com>
Acked-by: Lars Kurth <lars.kurth@citrix.com>
(cherry picked from commit 7782db9260d4c6499458de4e8d9866bc0427e143)

[ Combined with: ]

docs/gen-html-index: Make HTML::TreeBuilder::XPath optional again

7782db9260d4 "docs/gen-html-index: Extract titles from HTML documents"
requires HTML::TreeBuilder::XPath.

This is sadly not as widely available as I had hoped.  Work around
this problem by making the use of this module optional: instead of
`use'ing at the toplevel, we `require' it in the eval.  If it's not
present, then the title is simply not extracted and the filename is
used as before, which is tolerable.

Also add some debugging.

Reported-by: Doug Goldstein <cardoe@cardoe.com>
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
Tested-by: Doug Goldstein <cardoe@cardoe.com>
(cherry picked from commit 16fb4b5a9a79f95df17f10ba62e9f44d21cf89b5)
---
 docs/gen-html-index | 18 +++++++++++++++++-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/docs/gen-html-index b/docs/gen-html-index
index e9792bf..410674e 100644
--- a/docs/gen-html-index
+++ b/docs/gen-html-index
@@ -20,8 +20,10 @@ our @dirs;
 our %index;
 
 our $outdir;
+our $debug;
 
-GetOptions("i=s" => sub { read_index(@_);} )
+GetOptions("i=s" => sub { read_index(@_);},
+           "D" => \$debug)
     or die;
 
 ($outdir,@docs) = @ARGV;
@@ -64,6 +66,20 @@ sub make_linktext ($) {
     return "$1($2)" if $l =~ m,^man/(.*)\.([0-9].*)\.html,;
     $l =~ s/.(?:html|txt)$//g;
     return $index{$l} if exists $index{$l};
+
+    my $from_html;
+    eval {
+        require HTML::TreeBuilder::XPath;
+        my $tree = new HTML::TreeBuilder::XPath;
+        my $f = "$outdir/$l.html";
+        open F, '<', $f or die "$l $f $!";
+        $tree->parse_file(\*F) or die;
+        close F;
+        $from_html = $tree->findvalue("/html/head/title");
+    };
+    print "$l: get title: $@" if $@ && $debug;
+    return $from_html if $from_html;
+
     return basename($l);
 }
 
-- 
2.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH 5/9] docs/gen-html-index: Support documents at the toplevel

[Ian Jackson]

There are none yet.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Release-acked-by: Juergen Gross <jgross@suse.com>
Acked-by: Lars Kurth <lars.kurth@citrix.com>
(cherry picked from commit 1e4a834a8f5d970e68cff6d9c16710194bc46537)
---
 docs/gen-html-index | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/docs/gen-html-index b/docs/gen-html-index
index 410674e..4fad6db 100644
--- a/docs/gen-html-index
+++ b/docs/gen-html-index
@@ -140,6 +140,10 @@ sub dirs($)
     return @dirs;
 }
 
+foreach my $of (grep { !m{/} } @docs) {
+    $top .= make_link($of,'');
+}
+
 foreach my $od (sort { $a cmp $b } uniq map { dirs($_) } @docs) {
     my @d = (grep /^\Q$od\E/, @docs);
     if ( @d == 1 and $d[0] eq "$od/index.html" )
-- 
2.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH 6/9] docs/Makefile: Introduce GENERATE_PANDOC_RULE_RAW

[Ian Jackson]

We are going to want to format SUPPORT.md which does not match the
filename patterns in docs/.  So provide a way to make an ad-hoc rule
using pandoc with the standard options.

No functional change in this patch.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Release-acked-by: Juergen Gross <jgross@suse.com>
Acked-by: Lars Kurth <lars.kurth@citrix.com>
(cherry picked from commit 539f93945cad06fd90784716be1dc8d2624b6f66)
---
 docs/Makefile | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/docs/Makefile b/docs/Makefile
index 6743fa3..d82463f 100644
--- a/docs/Makefile
+++ b/docs/Makefile
@@ -237,17 +237,18 @@ txt/%.txt: %.markdown
 	$(INSTALL_DATA) $< $@
 
 # Metarule for generating pandoc rules.
-define GENERATE_PANDOC_RULE
-# $(1) is the target documentation format. $(2) is the source format.
-
-$(1)/%.$(1): %.$(2)
+define GENERATE_PANDOC_RULE_RAW
+$(1): $(2)
 ifneq ($(PANDOC),)
 	@$(INSTALL_DIR) $$(@D)
 	$(PANDOC) --number-sections --toc --standalone $$< --output $$@
 else
 	@echo "pandoc not installed; skipping $$@"
 endif
-
+endef
+define GENERATE_PANDOC_RULE
+# $(1) is the target documentation format. $(2) is the source format.
+$(call GENERATE_PANDOC_RULE_RAW,$(1)/%.$(1),%.$(2))
 endef
 $(eval $(call GENERATE_PANDOC_RULE,pdf,pandoc))   # pdf/%.pdf: %.pandoc
 $(eval $(call GENERATE_PANDOC_RULE,txt,pandoc))   # txt/%.txt: %.pandoc
-- 
2.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH 7/9] docs/Makefile: Format SUPPORT.md into the toplevel

[Ian Jackson]

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Release-acked-by: Juergen Gross <jgross@suse.com>
Acked-by: Lars Kurth <lars.kurth@citrix.com>
(cherry picked from commit f246d42665a6023c248c5b3e374da5691df63f6f)
---
 docs/Makefile | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/docs/Makefile b/docs/Makefile
index d82463f..b300bb6 100644
--- a/docs/Makefile
+++ b/docs/Makefile
@@ -28,7 +28,8 @@ DOC_MAN7 := $(patsubst man/%.pod.7,man7/%.7,$(MAN7SRC-y)) \
 	        $(patsubst man/%.markdown.7,man7/%.7,$(MAN7SRC-y))
 DOC_MAN8 := $(patsubst man/%.pod.8,man8/%.8,$(MAN8SRC-y)) \
 	        $(patsubst man/%.markdown.8,man8/%.8,$(MAN8SRC-y))
-DOC_HTML := $(patsubst %.markdown,html/%.html,$(MARKDOWNSRC-y)) \
+DOC_HTML := html/SUPPORT.html \
+            $(patsubst %.markdown,html/%.html,$(MARKDOWNSRC-y)) \
             $(patsubst %.pandoc,html/%.html,$(PANDOCSRC-y)) \
             $(patsubst man/%.markdown.1,html/man/%.1.html,$(MAN1SRC-y)) \
             $(patsubst man/%.markdown.5,html/man/%.5.html,$(MAN5SRC-y)) \
@@ -255,6 +256,8 @@ $(eval $(call GENERATE_PANDOC_RULE,txt,pandoc))   # txt/%.txt: %.pandoc
 $(eval $(call GENERATE_PANDOC_RULE,html,pandoc))  # html/%.html: %.pandoc
 $(eval $(call GENERATE_PANDOC_RULE,pdf,markdown)) # pdf/%.pdf: %.markdown
 
+$(eval $(call GENERATE_PANDOC_RULE_RAW,html/SUPPORT.html,$(XEN_ROOT)/SUPPORT.md)) # pdf/%.pdf: %.markdown
+
 ifeq (,$(findstring clean,$(MAKECMDGOALS)))
 $(XEN_ROOT)/config/Docs.mk:
 	$(error You have to run ./configure before building docs)
-- 
2.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH 8/9] SUPPORT.md: Move descriptions up before Status info

[Ian Jackson]

This turns all the things which were treated as caveats, but which
don't need to be footnoted in the matrix, into descriptions.

For the benefit of the support matrix generator, this patch (or a
version of it) should be backported to 4.10.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Release-acked-by: Juergen Gross <jgross@suse.com>
(cherry picked from commit 67b46e14cb943e27134e9c6d7b41b27bdd8c6ae9)

Merge conflicts resolved:
  - x86/HVM: 4.11 talks about "Status, domU"
  - x86/PVH: 4.11 mentions domO so heading is different too
  - ARM: Heading in 4.11 says just "ARM", in 4.10 "ARM guest"

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 SUPPORT.md | 211 ++++++++++++++++++++++++++++++++-----------------------------
 1 file changed, 110 insertions(+), 101 deletions(-)

diff --git a/SUPPORT.md b/SUPPORT.md
index 201e5a3..3429afb 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -58,44 +58,44 @@ for the definitions of the support status levels etc.
 
 ### ARM/GICv3 ITS
 
-    Status: Experimental
-
 Extension to the GICv3 interrupt controller to support MSI.
 
+    Status: Experimental
+
 ## Guest Type
 
 ### x86/PV
 
-    Status: Supported
-
 Traditional Xen PV guest
 
 No hardware requirements
 
-### x86/HVM
-
     Status: Supported
 
+### x86/HVM
+
 Fully virtualised guest using hardware virtualisation extensions
 
 Requires hardware virtualisation support (Intel VMX / AMD SVM)
 
-### x86/PVH guest
-
     Status: Supported
 
+### x86/PVH guest
+
 PVH is a next-generation paravirtualized mode
 designed to take advantage of hardware virtualization support when possible.
 During development this was sometimes called HVMLite or PVHv2.
 
 Requires hardware virtualisation support (Intel VMX / AMD SVM)
 
-### ARM guest
-
     Status: Supported
 
+### ARM guest
+
 ARM only has one guest type at the moment
 
+    Status: Supported
+
 ## Toolstack
 
 ### xl
@@ -104,12 +104,12 @@ ARM only has one guest type at the moment
 
 ### Direct-boot kernel image format
 
+Format which the toolstack accepts for direct-boot kernels
+
     Supported, x86: bzImage, ELF
     Supported, ARM32: zImage
     Supported, ARM64: Image
 
-Format which the toolstack accepts for direct-boot kernels
-
 ### Dom0 init support for xl
 
     Status, SysV: Supported
@@ -118,10 +118,10 @@ Format which the toolstack accepts for direct-boot kernels
 
 ### JSON output support for xl
 
-    Status: Experimental
-
 Output of information in machine-parseable JSON format
 
+    Status: Experimental
+
 ### Open vSwitch integration for xl
 
     Status, Linux: Supported
@@ -154,17 +154,18 @@ Output of information in machine-parseable JSON format
 
 ### Hypervisor 'debug keys'
 
-    Status: Supported, not security supported
-
 These are functions triggered either from the host serial console,
 or via the xl 'debug-keys' command,
 which cause Xen to dump various hypervisor state to the console.
 
+    Status: Supported, not security supported
+
 ### Hypervisor synchronous console output (sync_console)
 
+Xen command-line flag to force synchronous console output.
+
     Status: Supported, not security supported
 
-Xen command-line flag to force synchronous console output.
 Useful for debugging, but not suitable for production environments
 due to incurred overhead.
 
@@ -176,56 +177,54 @@ Debugger to debug ELF guests
 
 ### Soft-reset for PV guests
 
-    Status: Supported
-
 Soft-reset allows a new kernel to start 'from scratch' with a fresh VM state,
 but with all the memory from the previous state of the VM intact.
 This is primarily designed to allow "crash kernels",
 which can do core dumps of memory to help with debugging in the event of a crash.
 
-### xentrace
+    Status: Supported
 
-    Status, x86: Supported
+### xentrace
 
 Tool to capture Xen trace buffer data
 
-### gcov
+    Status, x86: Supported
 
-    Status: Supported, Not security supported
+### gcov
 
 Export hypervisor coverage data suitable for analysis by gcov or lcov.
 
+    Status: Supported, Not security supported
+
 ## Memory Management
 
 ### Dynamic memory control
 
-    Status: Supported
-
 Allows a guest to add or remove memory after boot-time.
 This is typically done by a guest kernel agent known as a "balloon driver".
 
-### Populate-on-demand memory
+    Status: Supported
 
-    Status, x86 HVM: Supported
+### Populate-on-demand memory
 
 This is a mechanism that allows normal operating systems with only a balloon driver
 to boot with memory < maxmem.
 
-### Memory Sharing
+    Status, x86 HVM: Supported
 
-    Status, x86 HVM: Expermental
+### Memory Sharing
 
 Allow sharing of identical pages between guests
 
-### Memory Paging
+    Status, x86 HVM: Expermental
 
-    Status, x86 HVM: Experimenal
+### Memory Paging
 
 Allow pages belonging to guests to be paged to disk
 
-### Transcendent Memory
+    Status, x86 HVM: Experimenal
 
-    Status: Experimental
+### Transcendent Memory
 
 Transcendent Memory (tmem) allows the creation of hypervisor memory pools
 which guests can use to store memory
@@ -233,96 +232,100 @@ rather than caching in its own memory or swapping to disk.
 Having these in the hypervisor
 can allow more efficient aggregate use of memory across VMs.
 
-### Alternative p2m
+    Status: Experimental
 
-    Status, x86 HVM: Tech Preview
-    Status, ARM: Tech Preview
+### Alternative p2m
 
 Allows external monitoring of hypervisor memory
 by maintaining multiple physical to machine (p2m) memory mappings.
 
+    Status, x86 HVM: Tech Preview
+    Status, ARM: Tech Preview
+
 ## Resource Management
 
 ### CPU Pools
 
-    Status: Supported
-
 Groups physical cpus into distinct groups called "cpupools",
 with each pool having the capability
 of using different schedulers and scheduling properties.
 
-### Credit Scheduler
-
     Status: Supported
 
+### Credit Scheduler
+
 A weighted proportional fair share virtual CPU scheduler.
 This is the default scheduler.
 
-### Credit2 Scheduler
-
     Status: Supported
 
+### Credit2 Scheduler
+
 A general purpose scheduler for Xen,
 designed with particular focus on fairness, responsiveness, and scalability
 
-### RTDS based Scheduler
+    Status: Supported
 
-    Status: Experimental
+### RTDS based Scheduler
 
 A soft real-time CPU scheduler
 built to provide guaranteed CPU capacity to guest VMs on SMP hosts
 
+    Status: Experimental
+
 ### ARINC653 Scheduler
 
+A periodically repeating fixed timeslice scheduler.
+
     Status: Supported
 
-A periodically repeating fixed timeslice scheduler.
 Currently only single-vcpu domains are supported.
 
 ### Null Scheduler
 
-    Status: Experimental
-
 A very simple, very static scheduling policy
 that always schedules the same vCPU(s) on the same pCPU(s).
 It is designed for maximum determinism and minimum overhead
 on embedded platforms.
 
-### NUMA scheduler affinity
+    Status: Experimental
 
-    Status, x86: Supported
+### NUMA scheduler affinity
 
 Enables NUMA aware scheduling in Xen
 
+    Status, x86: Supported
+
 ## Scalability
 
 ### Super page support
 
-    Status, x86 HVM/PVH, HAP: Supported
-    Status, x86 HVM/PVH, Shadow, 2MiB: Supported
-    Status, ARM: Supported
-
 NB that this refers to the ability of guests
 to have higher-level page table entries point directly to memory,
 improving TLB performance.
 On ARM, and on x86 in HAP mode,
 the guest has whatever support is enabled by the hardware.
+
+This feature is independent
+of the ARM "page granularity" feature (see below).
+
+    Status, x86 HVM/PVH, HAP: Supported
+    Status, x86 HVM/PVH, Shadow, 2MiB: Supported
+    Status, ARM: Supported
+
 On x86 in shadow mode, only 2MiB (L2) superpages are available;
 furthermore, they do not have the performance characteristics
 of hardware superpages.
 
-Also note is feature independent
-of the ARM "page granularity" feature (see below).
-
 ### x86/PVHVM
 
-    Status: Supported
-
 This is a useful label for a set of hypervisor features
 which add paravirtualized functionality to HVM guests
 for improved performance and scalability.
 This includes exposing event channels to HVM guests.
 
+    Status: Supported
+
 ## High Availability and Fault Tolerance
 
 ### Remus Fault Tolerance
@@ -335,54 +338,54 @@ This includes exposing event channels to HVM guests.
 
 ### x86/vMCE
 
-    Status: Supported
-
 Forward Machine Check Exceptions to appropriate guests
 
+    Status: Supported
+
 ## Virtual driver support, guest side
 
 ### Blkfront
 
+Guest-side driver capable of speaking the Xen PV block protocol
+
     Status, Linux: Supported
     Status, FreeBSD: Supported, Security support external
     Status, NetBSD: Supported, Security support external
     Status, OpenBSD: Supported, Security support external
     Status, Windows: Supported
 
-Guest-side driver capable of speaking the Xen PV block protocol
-
 ### Netfront
 
+Guest-side driver capable of speaking the Xen PV networking protocol
+
     Status, Linux: Supported
     Status, FreeBSD: Supported, Security support external
     Status, NetBSD: Supported, Security support external
     Status, OpenBSD: Supported, Security support external
     Status, Windows: Supported
 
-Guest-side driver capable of speaking the Xen PV networking protocol
-
 ### PV Framebuffer (frontend)
 
-    Status, Linux (xen-fbfront): Supported
-
 Guest-side driver capable of speaking the Xen PV Framebuffer protocol
 
+    Status, Linux (xen-fbfront): Supported
+
 ### PV Console (frontend)
 
+Guest-side driver capable of speaking the Xen PV console protocol
+
     Status, Linux (hvc_xen): Supported
     Status, FreeBSD: Supported, Security support external
     Status, NetBSD: Supported, Security support external
     Status, Windows: Supported
 
-Guest-side driver capable of speaking the Xen PV console protocol
-
 ### PV keyboard (frontend)
 
-    Status, Linux (xen-kbdfront): Supported
-
 Guest-side driver capable of speaking the Xen PV keyboard protocol.
 Note that the "keyboard protocol" includes mouse / pointer support as well.
 
+    Status, Linux (xen-kbdfront): Supported
+
 ### PV USB (frontend)
 
     Status, Linux: Supported
@@ -396,22 +399,22 @@ there is currently no xl support.
 
 ### PV TPM (frontend)
 
-    Status, Linux (xen-tpmfront): Tech Preview
-
 Guest-side driver capable of speaking the Xen PV TPM protocol
 
-### PV 9pfs frontend
+    Status, Linux (xen-tpmfront): Tech Preview
 
-    Status, Linux: Tech Preview
+### PV 9pfs frontend
 
 Guest-side driver capable of speaking the Xen 9pfs protocol
 
-### PVCalls (frontend)
-
     Status, Linux: Tech Preview
 
+### PVCalls (frontend)
+
 Guest-side driver capable of making pv system calls
 
+    Status, Linux: Tech Preview
+
 ## Virtual device support, host side
 
 For host-side virtual device support,
@@ -420,6 +423,8 @@ unless otherwise noted.
 
 ### Blkback
 
+Host-side implementations of the Xen PV block protocol.
+
     Status, Linux (xen-blkback): Supported
     Status, QEMU (xen_disk), raw format: Supported
     Status, QEMU (xen_disk), qcow format: Supported
@@ -430,42 +435,41 @@ unless otherwise noted.
     Status, Blktap2, raw format: Deprecated
     Status, Blktap2, vhd format: Deprecated
 
-Host-side implementations of the Xen PV block protocol.
 Backends only support raw format unless otherwise specified.
 
 ### Netback
 
+Host-side implementations of Xen PV network protocol
+
     Status, Linux (xen-netback): Supported
     Status, FreeBSD (netback): Supported, Security support external
     Status, NetBSD (xennetback): Supported, Security support external
 
-Host-side implementations of Xen PV network protocol
-
 ### PV Framebuffer (backend)
 
-    Status, QEMU: Supported
-
 Host-side implementation of the Xen PV framebuffer protocol
 
-### PV Console (xenconsoled)
+    Status, QEMU: Supported
 
-    Status: Supported
+### PV Console (xenconsoled)
 
 Host-side implementation of the Xen PV console protocol
 
-### PV keyboard (backend)
+    Status: Supported
 
-    Status, QEMU: Supported
+### PV keyboard (backend)
 
 Host-side implementation of the Xen PV keyboard protocol.
 Note that the "keyboard protocol" includes mouse / pointer support as well.
 
-### PV USB (backend)
-
     Status, QEMU: Supported
 
+### PV USB (backend)
+
 Host-side implementation of the Xen PV USB protocol
 
+    Status, QEMU: Supported
+
 ### PV SCSI protocol (backend)
 
     Status, Linux: Experimental
@@ -496,11 +500,11 @@ but has no xl support.
 
 ### Driver Domains
 
-    Status: Supported, with caveats
-
 "Driver domains" means allowing non-Domain 0 domains
 with access to physical devices to act as back-ends.
 
+    Status: Supported, with caveats
+
 See the appropriate "Device Passthrough" section
 for more information about security support.
 
@@ -550,13 +554,13 @@ with dom0, driver domains, stub domains, domUs, and so on.
 
 ### x86/Nested PV
 
-    Status, x86 Xen HVM: Tech Preview
-
 This means running a Xen hypervisor inside an HVM domain on a Xen system,
 with support for PV L2 guests only
 (i.e., hardware virtualization extensions not provided
 to the guest).
 
+    Status, x86 Xen HVM: Tech Preview
+
 This works, but has performance limitations
 because the L1 dom0 can only access emulated L1 devices.
 
@@ -565,19 +569,19 @@ but nobody has reported on performance.
 
 ### x86/Nested HVM
 
-    Status, x86 HVM: Experimental
-
 This means providing hardware virtulization support to guest VMs
 allowing, for instance, a nested Xen to support both PV and HVM guests.
 It also implies support for other hypervisors,
 such as KVM, Hyper-V, Bromium, and so on as guests.
 
-### vPMU
+    Status, x86 HVM: Experimental
 
-    Status, x86: Supported, Not security supported
+### vPMU
 
 Virtual Performance Management Unit for HVM guests
 
+    Status, x86: Supported, Not security supported
+
 Disabled by default (enable with hypervisor command line option).
 This feature is not security supported: see http://xenbits.xen.org/xsa/advisory-163.html
 
@@ -622,7 +626,11 @@ No support for QEMU backends in a 16K or 64K domain.
 
 ## Virtual Hardware, QEMU
 
-These are devices available in HVM mode using a qemu devicemodel (the default).
+This section describes supported devices available in HVM mode using a
+qemu devicemodel (the default).
+
+    Status: Support scope restricted 
+
 Note that other devices are available but not security supported.
 
 ### x86/Emulated platform devices (QEMU):
@@ -672,9 +680,10 @@ See the section **Blkback** for image formats supported by QEMU.
 
 ### x86/HVM iPXE
 
+Booting a guest via PXE.
+
     Status: Supported, with caveats
 
-Booting a guest via PXE.
 PXE inherently places full trust of the guest in the network,
 and so should only be used
 when the guest network is under the same administrative control
@@ -682,17 +691,17 @@ as the guest itself.
 
 ### x86/HVM BIOS
 
+Booting a guest via guest BIOS firmware
+
     Status, SeaBIOS (qemu-xen): Supported
     Status, ROMBIOS (qemu-xen-traditional): Supported
 
-Booting a guest via guest BIOS firmware
-
 ### x86/HVM OVMF
 
-    Status, qemu-xen: Supported
-
 OVMF firmware implements the UEFI boot protocol.
 
+    Status, qemu-xen: Supported
+
 # Format and definitions
 
 This file contains prose, and machine-readable fragments.
-- 
2.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH 9/9] SUPPORT.md: Document the new text ordering rule

[Ian Jackson]

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Release-acked-by: Juergen Gross <jgross@suse.com>
(cherry picked from commit 2e9aeb6f40eaf13c20231ec91301be74a19152ad)
---
 SUPPORT.md | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/SUPPORT.md b/SUPPORT.md
index 3429afb..0d2db1f 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -712,6 +712,11 @@ The file is in markdown format.
 The machine-readable fragments are markdown literals
 containing RFC-822-like (deb822-like) data.
 
+In each case, descriptions which expand on the name of a feature as
+provided in the section heading, precede the Status indications.
+Any paragraphs which follow the Status indication are caveats or
+qualifications of the information provided in Status fields.
+
 ## Keys found in the Feature Support subsections
 
 ### Status
-- 
2.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH for-4.11 0/2] SUPPORT.md matrix fixes (series "C")

[Ian Jackson]

I was just testing the results of my backports of the SUPPORT.md
series to 4.10 - just sent, under the Subject line:
    [PATCH for-4.10 0/9] SUPPORT.md backports to support matrix generation

I found a bug in the support matrix generator.  Sadly the bug was not
evident without the backported changes to SUPPORT.md.  These two
patches fix this bug.

Example output can be found here:
  https://xenbits.xen.org/people/iwj/2018/support-matrix-example-C/t.html
(The hyperlink references for staging are to the live xenbits version;
the references for 4.10 are to the example SUPPORT.html output file
from the 4.10 backport series, as discussed above.)

For my reference, this was made as follows:
  docs/support-matrix-generate -D HEAD https://xenbits.xen.org/docs/unstable-staging/SUPPORT.html refs/heads/wip.support-stmt-NN-2 SUPPORT.html 2>&1 >docs/html/t.html |less
  rsync -LvP docs/html/{t,SUPPORT}.html xenbits:public_html/2018/support-matrix-example-C

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH 1/2] docs/parse-support-md: Break out find_current_sectnode

[Ian Jackson]

We are going to want to add a call site for this.

No functional change.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 docs/parse-support-md | 48 +++++++++++++++++++++++++++---------------------
 1 file changed, 27 insertions(+), 21 deletions(-)

diff --git a/docs/parse-support-md b/docs/parse-support-md
index 218e12b..f0b4c25 100755
--- a/docs/parse-support-md
+++ b/docs/parse-support-md
@@ -67,6 +67,32 @@ our $had_feature;
 
 #---------- parsing ----------
 
+sub find_current_sectnode () {
+    die unless @insections;
+
+    my $sectnode;
+    my $realsect;
+    foreach my $s (@insections) {
+        my $sectlist = $sectnode
+            ? $sectnode->{Children} : $toplevel_sectlist;
+        my $key = $s->{Key};
+        $realsect = $s if $s->{Anchor};
+        tie %$sectlist, 'Tie::IxHash' unless tied %$sectlist;
+#print STDERR "FIND_CURRENT_SECTNODE ", Dumper($s);
+        $sectlist->{$key} //=
+            {
+             Children => new_sectlist(),
+             Headline => $s->{Headline},
+             Key => $key,
+             RealSect => $realsect,
+             HasCaveat => [],
+            };
+        $sectnode = $sectlist->{$key};
+    }
+    die unless $sectnode;
+    return $sectnode;
+}
+
 sub ri_Header {
     my ($c) = @_;
     my ($level, $infos, $hl) = @$c;
@@ -100,29 +126,9 @@ sub ri_Para {
 
 sub parse_feature_entry ($) {
     my ($value) = @_;
-    die unless @insections;
 
     $had_feature = 1;
-
-    my $sectnode;
-    my $realsect;
-    foreach my $s (@insections) {
-        my $sectlist = $sectnode
-            ? $sectnode->{Children} : $toplevel_sectlist;
-        my $key = $s->{Key};
-        $realsect = $s if $s->{Anchor};
-        tie %$sectlist, 'Tie::IxHash' unless tied %$sectlist;
-#print STDERR "PARSE_FEATURE_ENTRY ", Dumper($s);
-        $sectlist->{$key} //=
-            {
-             Children => new_sectlist(),
-             Headline => $s->{Headline},
-             Key => $key,
-             RealSect => $realsect,
-            };
-        $sectnode = $sectlist->{$key};
-    }
-    die unless $sectnode;
+    my $sectnode = find_current_sectnode();
     $sectnode->{Status}[$version_index] = $value;
 }
 
-- 
2.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH 2/2] docs/parse-support-md: Do caveats properly (!)

[Ian Jackson]

Each document has its own objects in @insections.  Only the first
RealSect encountered ends up in the main $toplevel_sectlist tree.

This means that trying to unify the Caveats information for all
version in the RealSect (the $insection) does not work.  The caveats
for all versions that aren't the first one where this section was seen
end up in the @insections array during parsing of that version, but
not recorded in the main tree.

The result was that footnotes would only appear in the output for
versions which were the most recent version where that feature row or
category appeared.  The other footnotes would be lost.

Instead, store HasCaveat in the sectnode.  That means ri_Para needs to
find the sectnode.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 docs/parse-support-md | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/docs/parse-support-md b/docs/parse-support-md
index f0b4c25..1c82f56 100755
--- a/docs/parse-support-md
+++ b/docs/parse-support-md
@@ -33,8 +33,8 @@ our $toplevel_sectlist = new_sectlist();
 # $sectlist->{KEY}{Status}[VI] = absent or markdown content
 # $sectlist->{KEY}{Children} = a further $sectlist
 # $sectlist->{KEY}{Key} = KEY
+# $sectlist->{KEY}{HasCaveat}[VI] = trueish iff other in a Para
 # $sectlist->{KEY}{RealSect} = containing real section in @insections, so
-# $sectlist->{KEY}{RealSect}{HasCaveat}[VI] = trueish iff other in a Para
 # $sectlist->{KEY}{RealSect}{HasDescription} = VI for some Emph in Para
 # $sectlist->{KEY}{RealSect}{Anchor} = value for < id="" > in the pandoc html
 # A $sectnode represents a single section from the original markdown
@@ -58,7 +58,6 @@ our @insections;
 # $insections[]{Headline} = markdown content
 # these next are only defined for real sections, not Status elements
 # $insections[]{Anchor} = string
-# $insections[]{HasCaveat} = array, $sectlist->{HasCaveat} will refer to this
 # $insections[]{HasDescription} VI, likewise
 
 our $had_unknown;
@@ -106,7 +105,6 @@ sub ri_Header {
          Key => $id,
          Anchor => $id,
          Headline => $hl,
-         HasCaveat => [],
          HasDescription => undef,
         };
 #print STDERR Dumper(\@insections);
@@ -116,9 +114,12 @@ sub ri_Header {
 sub ri_Para {
     return unless @insections;
     my $insection = $insections[$#insections];
+#    print STDERR "ri_Para $version_index $had_feature ".
+#        $insection->{HasCaveat}." $insection->{Key}\n";
 
     if ($had_feature) {
-        $insection->{HasCaveat}[$version_index] = 1;
+        my $sectnode = find_current_sectnode();
+        $sectnode->{HasCaveat}[$version_index] = 1;
     } else {
         $insection->{HasDescription} //= $version_index;
     }
@@ -397,7 +398,7 @@ sub write_output_row ($) {
         my $nextcell = '';
         if (!defined $colspan) { # first row of this RealSect
             $colspan= ' colspan="2"';
-            if ($sectnode->{RealSect}{HasCaveat}[$i] && $st
+            if ($sectnode->{HasCaveat}[$i] && $st
                 && $sectnode->{RealSect}{Anchor}) {
                 my $rows = $sectnode->{RealSect}{OwnRows};
                 $nextcell = '<td';
-- 
2.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH for-4.11 0/2] SUPPORT.md matrix fixes (series "C")

[Juergen Gross]

On 25/04/18 15:04, Ian Jackson wrote:
> I was just testing the results of my backports of the SUPPORT.md
> series to 4.10 - just sent, under the Subject line:
>     [PATCH for-4.10 0/9] SUPPORT.md backports to support matrix generation
> 
> I found a bug in the support matrix generator.  Sadly the bug was not
> evident without the backported changes to SUPPORT.md.  These two
> patches fix this bug.
> 
> Example output can be found here:
>   https://xenbits.xen.org/people/iwj/2018/support-matrix-example-C/t.html
> (The hyperlink references for staging are to the live xenbits version;
> the references for 4.10 are to the example SUPPORT.html output file
> from the 4.10 backport series, as discussed above.)
> 
> For my reference, this was made as follows:
>   docs/support-matrix-generate -D HEAD https://xenbits.xen.org/docs/unstable-staging/SUPPORT.html refs/heads/wip.support-stmt-NN-2 SUPPORT.html 2>&1 >docs/html/t.html |less
>   rsync -LvP docs/html/{t,SUPPORT}.html xenbits:public_html/2018/support-matrix-example-C
> 
> Thanks,
> Ian.
> 

For the series:

Release-acked-by: Juergen Gross <jgross@suse.com>


Not related to these patches, but:

SUPPORT.md of 4.10 seems to have some entries different to 4.11. Do we
want to change those? This might result in a more readable table.

e.g.:

4.10: ### x86/PVH guest
          Status: Supported

4.11: ### x86/PVH
          Status, domU: Supported
          Status, dom0: Experimental

4.10: ### x86/Emulated graphics (QEMU):
          Status, stgvga: Supported         <- note the typo in "stgvga"

4.11: ### x86/Emulated graphics (QEMU):
          Status, stdvga: Supported


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH for-4.11 0/2] SUPPORT.md matrix fixes (series "C")

[Ian Jackson]

Juergen Gross writes ("Re: [PATCH for-4.11 0/2] SUPPORT.md matrix fixes (series "C")"):
> Not related to these patches, but:
> 
> SUPPORT.md of 4.10 seems to have some entries different to 4.11. Do we
> want to change those? This might result in a more readable table.
> 
> e.g.:
> 
> 4.10: ### x86/PVH guest
>           Status: Supported
> 
> 4.11: ### x86/PVH
>           Status, domU: Supported
>           Status, dom0: Experimental

Indeed.  I noticed this when I was backporting my reformatting.
I considered changing this but I think TBH that this slight deviation
in naming is going to occur occasionally.

There's a paragraph about it in the intro and everything.

> 4.10: ### x86/Emulated graphics (QEMU):
>           Status, stgvga: Supported         <- note the typo in "stgvga"
> 4.11: ### x86/Emulated graphics (QEMU):
>           Status, stdvga: Supported

This should be fixed.  I'll send a followup patch.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH for-4.10 0/9] SUPPORT.md backports to support matrix generation

[Jan Beulich]

>>> On 25.04.18 at 14:59, <ian.jackson@eu.citrix.com> wrote:
> This is a backport of my two recent series to fix bugs in SUPPORT.md,
> format it as part of the published docs, and use relative position of
> the `Status' stanza compared to descriptive text to indicate whether
> the text is a caveat that deserves a footnote.
> 
> Most of this is uncontroversial and I have run the build and checked
> that the resulting index.html is good.
> 
> It would be good if someone could review particularly the way I
> resolved the conflicts in the big patch to SUPPORT.md, ie in
>   [PATCH 8/9] SUPPORT.md: Move descriptions up before Status info
> 
> The result for 4.10's
> SUPPORT.md is here:
>   https://xenbits.xen.org/people/iwj/2018/support-matrix-example-C/SUPPORT.html 
> 
> I have also checked that (with the patch I am about to send for
> staging's parse-support-md) that this generates a sensible-looking
> support matrix.  The resulting support matrix can be found here:
>   https://xenbits.xen.org/people/iwj/2018/support-matrix-example-C/t.html 
> (The hyperlink references for staging are to the live xenbits version;
> the references for 4.10 are to the example output file mentioned above.)
> 
> I have squashed the fix to not depend on HTML::TreeBuilder::XPath into
> the patch that introduces the dependency.

Acked-by: Jan Beulich <jbeulich@suse.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH for-4.10 10/9] SUPPORT.md: Fix a typo

[Ian Jackson]

Reported-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 SUPPORT.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/SUPPORT.md b/SUPPORT.md
index 0d2db1f..f85dda8 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -653,7 +653,7 @@ See the section **Blkback** for image formats supported by QEMU.
 ### x86/Emulated graphics (QEMU):
 
     Status, cirrus-vga: Supported
-    Status, stgvga: Supported
+    Status, stdvga: Supported
 
 ### x86/Emulated audio (QEMU):
 
-- 
2.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH for-4.11 0/2] SUPPORT.md matrix fixes (series "C")

[Juergen Gross]

On 25/04/18 15:21, Ian Jackson wrote:
> Juergen Gross writes ("Re: [PATCH for-4.11 0/2] SUPPORT.md matrix fixes (series "C")"):
>> Not related to these patches, but:
>>
>> SUPPORT.md of 4.10 seems to have some entries different to 4.11. Do we
>> want to change those? This might result in a more readable table.
>>
>> e.g.:
>>
>> 4.10: ### x86/PVH guest
>>           Status: Supported
>>
>> 4.11: ### x86/PVH
>>           Status, domU: Supported
>>           Status, dom0: Experimental
> 
> Indeed.  I noticed this when I was backporting my reformatting.
> I considered changing this but I think TBH that this slight deviation
> in naming is going to occur occasionally.

The resulting table is rather hard to read, don't you think?

Especially the supported guest types are difficult to compare between
4.10 and 4.11.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH for-4.10 10/9] SUPPORT.md: Fix a typo

[Juergen Gross]

On 25/04/18 15:23, Ian Jackson wrote:
> Reported-by: Juergen Gross <jgross@suse.com>
> Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>

Reviewed-by: Juergen Gross <jgross@suse.com>


Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH for-4.11 0/2] SUPPORT.md matrix fixes (series "C")

[George Dunlap]

> On Apr 25, 2018, at 2:32 PM, Juergen Gross <jgross@suse.com> wrote:
> 
> On 25/04/18 15:21, Ian Jackson wrote:
>> Juergen Gross writes ("Re: [PATCH for-4.11 0/2] SUPPORT.md matrix fixes (series "C")"):
>>> Not related to these patches, but:
>>> 
>>> SUPPORT.md of 4.10 seems to have some entries different to 4.11. Do we
>>> want to change those? This might result in a more readable table.
>>> 
>>> e.g.:
>>> 
>>> 4.10: ### x86/PVH guest
>>>          Status: Supported
>>> 
>>> 4.11: ### x86/PVH
>>>          Status, domU: Supported
>>>          Status, dom0: Experimental
>> 
>> Indeed.  I noticed this when I was backporting my reformatting.
>> I considered changing this but I think TBH that this slight deviation
>> in naming is going to occur occasionally.
> 
> The resulting table is rather hard to read, don't you think?
> 
> Especially the supported guest types are difficult to compare between
> 4.10 and 4.11.

Right, so there are four options:

1. Never rename / reorganize SUPPORT.md categories
2. Backport all renames / reorganizations to all supported versions
3. Introduce some sort of “mapping” of options so that the table generator can correctly construct rows
4. Tolerate duplicate rows for renamed / reorganized features

I was initially opposed to #2, but I think the idea is growing on me.  It does mean SUPPORT.md may end up being reorganized or renamed in point releases, however.  It’s a bit hard for me to tell how disruptive that would be.

 -George
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH for-4.11 0/2] SUPPORT.md matrix fixes (series "C")

[Ian Jackson]

George Dunlap writes ("Re: [PATCH for-4.11 0/2] SUPPORT.md matrix fixes (series "C")"):
> Right, so there are four options:
> 
> 1. Never rename / reorganize SUPPORT.md categories

This is clearly unworkable.

> 3. Introduce some sort of “mapping” of options so that the table
> generator can correctly construct rows

I think this would be quite annoying.  It would have to be maintained
separately, probably in the branch for the next version.  It would
also make the table generator more complicated and it's quite bad
enough already.

> 2. Backport all renames / reorganizations to all supported versions
> 4. Tolerate duplicate rows for renamed / reorganized features

So it has to be one of these.  IMO either of these is fine.

> I was initially opposed to #2, but I think the idea is growing on
> me.  It does mean SUPPORT.md may end up being reorganized or renamed
> in point releases, however.  It’s a bit hard for me to tell how
> disruptive that would be.

We don't have to make this decision the same way for every feature.

If someone wants to send a patch (on top of my backport series,
please) that renames "PVH guest" to "PVH" in 4.10, and changes
"Status:" to "Status, domU:", to match 4.11 that would be fine by me.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH for-4.11 0/2] SUPPORT.md matrix fixes (series "C")

[Juergen Gross]

On 25/04/18 15:43, George Dunlap wrote:
> 
> 
>> On Apr 25, 2018, at 2:32 PM, Juergen Gross <jgross@suse.com> wrote:
>>
>> On 25/04/18 15:21, Ian Jackson wrote:
>>> Juergen Gross writes ("Re: [PATCH for-4.11 0/2] SUPPORT.md matrix fixes (series "C")"):
>>>> Not related to these patches, but:
>>>>
>>>> SUPPORT.md of 4.10 seems to have some entries different to 4.11. Do we
>>>> want to change those? This might result in a more readable table.
>>>>
>>>> e.g.:
>>>>
>>>> 4.10: ### x86/PVH guest
>>>>          Status: Supported
>>>>
>>>> 4.11: ### x86/PVH
>>>>          Status, domU: Supported
>>>>          Status, dom0: Experimental
>>>
>>> Indeed.  I noticed this when I was backporting my reformatting.
>>> I considered changing this but I think TBH that this slight deviation
>>> in naming is going to occur occasionally.
>>
>> The resulting table is rather hard to read, don't you think?
>>
>> Especially the supported guest types are difficult to compare between
>> 4.10 and 4.11.
> 
> Right, so there are four options:
> 
> 1. Never rename / reorganize SUPPORT.md categories

As we can see in the example above this won't work very well.

> 2. Backport all renames / reorganizations to all supported versions

+1

As this will only be more specific it is a win. Again above example:
How would you read the 4.10 PVH support? Is dom0 supported? Its a guest
after all...

> 3. Introduce some sort of “mapping” of options so that the table generator can correctly construct rows

Seems to be rather complex, e.g. in above example

> 4. Tolerate duplicate rows for renamed / reorganized features

This might grow rather ugly results after some more versions.


Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH for-4.11 0/2] SUPPORT.md matrix fixes (series "C")

[Ian Jackson]

Ian Jackson writes ("Re: [PATCH for-4.11 0/2] SUPPORT.md matrix fixes (series "C")"):
> George Dunlap writes ("Re: [PATCH for-4.11 0/2] SUPPORT.md matrix fixes (series "C")"):
> > 2. Backport all renames / reorganizations to all supported versions
...
> > I was initially opposed to #2, but I think the idea is growing on
> > me.  It does mean SUPPORT.md may end up being reorganized or renamed
> > in point releases, however.  It’s a bit hard for me to tell how
> > disruptive that would be.
...
> If someone wants to send a patch (on top of my backport series,
> please) that renames "PVH guest" to "PVH" in 4.10, and changes
> "Status:" to "Status, domU:", to match 4.11 that would be fine by me.

Oh, and, if we contemplate doing #2 occasionally then we should ask
people to not send mixed patches which do both
(i) renaming/reorganising features (ii) changing the support status.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH for-4.11 0/2] SUPPORT.md matrix fixes (series "C")

[Ian Jackson]

Juergen Gross writes ("Re: [PATCH for-4.11 0/2] SUPPORT.md matrix fixes (series "C")"):
> On 25/04/18 15:43, George Dunlap wrote:
> > 2. Backport all renames / reorganizations to all supported versions
> 
> +1
> 
> As this will only be more specific it is a win. Again above example:
> How would you read the 4.10 PVH support? Is dom0 supported? Its a guest
> after all...

I think "guest" excludes dom0.  dom0 is a domain but not a guest.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH for-4.11 0/2] SUPPORT.md matrix fixes (series "C")

[Juergen Gross]

On 25/04/18 15:54, Ian Jackson wrote:
> Juergen Gross writes ("Re: [PATCH for-4.11 0/2] SUPPORT.md matrix fixes (series "C")"):
>> On 25/04/18 15:43, George Dunlap wrote:
>>> 2. Backport all renames / reorganizations to all supported versions
>>
>> +1
>>
>> As this will only be more specific it is a win. Again above example:
>> How would you read the 4.10 PVH support? Is dom0 supported? Its a guest
>> after all...
> 
> I think "guest" excludes dom0.  dom0 is a domain but not a guest.

Aah, so on ARM we have no dom0 support?


Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH for-4.11 0/2] SUPPORT.md matrix fixes (series "C")

[Ian Jackson]

Juergen Gross writes ("Re: [PATCH for-4.11 0/2] SUPPORT.md matrix fixes (series "C")"):
> Aah, so on ARM we have no dom0 support?

No, that is a mistake.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 8/9] SUPPORT.md: Move descriptions up before Status info

[George Dunlap]

> On Apr 25, 2018, at 2:00 PM, Ian Jackson <ian.jackson@eu.citrix.com> wrote:
> 
> This turns all the things which were treated as caveats, but which
> don't need to be footnoted in the matrix, into descriptions.
> 
> For the benefit of the support matrix generator, this patch (or a
> version of it) should be backported to 4.10.
> 
> Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
> Release-acked-by: Juergen Gross <jgross@suse.com>
> (cherry picked from commit 67b46e14cb943e27134e9c6d7b41b27bdd8c6ae9)
> 
> Merge conflicts resolved:
>  - x86/HVM: 4.11 talks about "Status, domU"
>  - x86/PVH: 4.11 mentions domO so heading is different too
>  - ARM: Heading in 4.11 says just "ARM", in 4.10 "ARM guest”

Reviewed-by: George Dunlap <george.dunlap@citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH for-4.10 0/9] SUPPORT.md backports to support matrix generation [and 4 more messages]

[Ian Jackson]

Ian Jackson writes ("[PATCH for-4.10 0/9] SUPPORT.md backports to support matrix generation"):
> This is a backport of my two recent series to fix bugs in SUPPORT.md,
> format it as part of the published docs, and use relative position of
> the `Status' stanza compared to descriptive text to indicate whether
> the text is a caveat that deserves a footnote.

Thanks everyone.  I have pushed this to staging-4.10, including the
patch 10/9.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH for-4.10 0/9] SUPPORT.md backports to support matrix generation [and 4 more messages]

[Ian Jackson]

Ian Jackson writes ("Re: [PATCH for-4.10 0/9] SUPPORT.md backports to support matrix generation [and 4 more messages]"):
> Thanks everyone.  I have pushed this to staging-4.10, including the
> patch 10/9.

The first cut of the cron job is now running.  So far it is only
running off staging, and the output is here:

  http://xenbits.xen.org/docs/unstable-staging/support-matrix.html

It's labelled DRAFT because it's from staging, not because it's
hand-edited or anything.

When we get pushes of all the relevant branches to the corresponding
stable branches, I think the non-DRAFT version is ready to go.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH for-4.10 0/9] SUPPORT.md backports to support matrix generation [and 4 more messages]

[Juergen Gross]

On 25/04/18 17:58, Ian Jackson wrote:
> Ian Jackson writes ("Re: [PATCH for-4.10 0/9] SUPPORT.md backports to support matrix generation [and 4 more messages]"):
>> Thanks everyone.  I have pushed this to staging-4.10, including the
>> patch 10/9.
> 
> The first cut of the cron job is now running.  So far it is only
> running off staging, and the output is here:
> 
>   http://xenbits.xen.org/docs/unstable-staging/support-matrix.html
> 
> It's labelled DRAFT because it's from staging, not because it's
> hand-edited or anything.
> 
> When we get pushes of all the relevant branches to the corresponding
> stable branches, I think the non-DRAFT version is ready to go.
> 
> Ian.
> 

The links to the 4.10 SUPPORT.html aren't working:

https://xenbits.xen.org/docs/4.10-testing/SUPPORT.html


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH 4/9] docs/gen-html-index: Extract titles from HTML documents

[Ian Jackson]

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Release-acked-by: Juergen Gross <jgross@suse.com>
---
 docs/gen-html-index | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/docs/gen-html-index b/docs/gen-html-index
index e9792bf..5b43b42 100644
--- a/docs/gen-html-index
+++ b/docs/gen-html-index
@@ -10,6 +10,7 @@ use warnings;
 use Getopt::Long;
 use IO::File;
 use File::Basename;
+use HTML::TreeBuilder::XPath;
 
 Getopt::Long::Configure('bundling');
 
@@ -64,6 +65,18 @@ sub make_linktext ($) {
     return "$1($2)" if $l =~ m,^man/(.*)\.([0-9].*)\.html,;
     $l =~ s/.(?:html|txt)$//g;
     return $index{$l} if exists $index{$l};
+
+    my $from_html;
+    eval {
+        my $tree = new HTML::TreeBuilder::XPath;
+        my $f = "$outdir/$l.html";
+        open F, '<', $f or die "$l $f $!";
+        $tree->parse_file(\*F) or die;
+        close F;
+        $from_html = $tree->findvalue("/html/head/title");
+    };
+    return $from_html if $from_html;
+
     return basename($l);
 }
 
-- 
2.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel