[PATCH kindof] to http://wiki.xen.org/wiki/X86_Paravirtualised_Memory_Management

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

Was thinking to add this to the Wiki, but before I do that - does anybody
have a handy segment decoder ring?


== Segments ==

The initial segments that the guest boots with are dependent on the mode
of the guest and the hypervisor. If a 64-bit hypervisor is used, the guest
can be in either 64-bit mode or 32-bit mode. If 32-bit hypervisor (deprecated)
then obviously only a 32-bit guest can be started.

The initial segment values are set to be flat. They are also located at
the far end of the GDT as to not conflict with OS-es that have hard-coded
segment values. This means that when a guest boots the GDT indexes for
segment selectors are usually past 259.


If the guest is 64-bit, then DS.ES.FS, and GS all point to the NULL selector.
That is they contain the contents of 0x00.

If it is 32-bit, then the DS,ES,FS, and GS all point to a segment set for
ring 1 (0xe021), index 260. The GDT entry looks as so:

   0x00cfb2000000ffff     /* 0xe021 ring 1 data                */

The SS segment in 64-bit mode, contains the GDT index 262, and the RPL
is set for ring 3 (0xe033).  The GDT entry looks as so:

   0x00affa000000ffff     /* 0xe033 ring 3 code, 64-bit mode   */

In 32-bit mode, then the SS GDT index is 260, and in ring 1 (0xe021).
The GDT entry looks as so:

   0x00cfb2000000ffff     /* 0xe021 ring 1 data                */

The CS segment in 64-bit mode, contains the GDT index 262, and is in ring 3
(0xe033).  The GDT entry looks as so:

    0x00affa000000ffff     /* 0xe033 ring 3 code, 64-bit mode   */

The CS segment in 32-bit mode is index 259, ring 1 (0xe019), and contains:

   0x00cfba000000ffff     /* 0xe019 ring 1 code, compatibility */    

The 32-bit guest and 32-bit hypervisor segments are not explained.

[TBD: decode the GDT, explain how to program them, point to AMD Vol 2
document, explain the transition]

== Hyperpage ==

Depending on the mode of the guest (32-bit or 64-bit) the hypervisor
populates the hyperpage with appropriate instructions. The virtual address
where the hypervisor needs to populate the hyperpage is set by the ELF PT_NOTE
entry. Specifically the XEN_ELFNOTE_HYPERCALL_PAGE
(see http://xenbits.xen.org/docs/unstable/hypercall/include,public,elfnote.h.html#incontents_elfnote)

The contents of the page if the guest is 64-bit is:
   push %rcx
   push %r11
   mov $hypercall_entry, %eax
   syscall
   pop %r11
   pop %%rcx
   ret

For 32-bit it is:
   mov $hypercall_entry, %eax
   int 0x82
   ret

The hypercall_entry is a value from zero to 64 and they correspond to:
http://xenbits.xen.org/docs/unstable/hypercall/include,public,xen.h.html#incontents_hcalls 

One of the hypercalls (iret) is different b/c it does not return and expects
a special stack frame. Guests jump at this transfer point instead of calling it.
For 64-bit guests:

   push %rcx
   push %r11
   push %rax
   movl $__HYPERVISOR_iret, %eax
   syscall

For 32-bit guests:
   push %eax
   movl $__HYPERVISOR_iret, %eax
   int  0x82