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: 68e1183411b ('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>
* `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'.
/* 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;