xen/pvh: Fix segment selector ABI

The written ABI states that %es will be set up, but libxc doesn't do so.  In
practice, it breaks `rep movs` inside guests before they reload %es.

The written ABI doesn't mention %ss, but libxc does set it up.  Having %ds
different to %ss is obnoxous to work with, as different registers have
different implicit segments.

Modify the spec to state that %ss is set up as a flat read/write segment.
This a) matches the Multiboot 1 spec, b) matches what is set up in practice,
and c) is the more sane behaviour for guests to use.

Fixes: 68e1183411 ('libxc: introduce a xc_dom_arch for hvm-3.0-x86_32 guests')
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Wei Liu <wl@xen.org>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>

docs/misc/pvh.pandoc

@@ -23,7 +23,7 @@ following machine state:
  * `cs`: must be a 32-bit read/execute code segment with a base of ‘0’
    and a limit of ‘0xFFFFFFFF’. The selector value is unspecified.
 
- * `ds`, `es`: must be a 32-bit read/write data segment with a base of
+ * `ds`, `es`, `ss`: must be a 32-bit read/write data segment with a base of
    ‘0’ and a limit of ‘0xFFFFFFFF’. The selector values are all unspecified.
 
  * `tr`: must be a 32-bit TSS (active) with a base of '0' and a limit of '0x67'.

tools/libxc/xc_dom_x86.c

@@ -1053,14 +1053,17 @@ static int vcpu_hvm(struct xc_dom_image *dom)
     /* Set the cached part of the relevant segment registers. */
     bsp_ctx.cpu.cs_base = 0;
     bsp_ctx.cpu.ds_base = 0;
+    bsp_ctx.cpu.es_base = 0;
     bsp_ctx.cpu.ss_base = 0;
     bsp_ctx.cpu.tr_base = 0;
     bsp_ctx.cpu.cs_limit = ~0u;
     bsp_ctx.cpu.ds_limit = ~0u;
+    bsp_ctx.cpu.es_limit = ~0u;
     bsp_ctx.cpu.ss_limit = ~0u;
     bsp_ctx.cpu.tr_limit = 0x67;
     bsp_ctx.cpu.cs_arbytes = 0xc9b;
     bsp_ctx.cpu.ds_arbytes = 0xc93;
+    bsp_ctx.cpu.es_arbytes = 0xc93;
     bsp_ctx.cpu.ss_arbytes = 0xc93;
     bsp_ctx.cpu.tr_arbytes = 0x8b;