Re: [Xen-devel] [PATCH] docs: add PVH specification

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 16.09.14 at 17:53, <roger.pau@xxxxxxxxxx> wrote:
> +Also, the `rsi` (`esi` on 32bits) register is going to contain the virtual
> +memory address were Xen has placed the `start_info` structure. The `rsp` 
> (`esp`
> +on 32bits) will contain a stack, that can be used by the guest kernel. The

... will point to the top of an initial single page stack, ...

> +`start_info` structure contains all the info the guest needs in order to
> +initialize. More information about the contents can be found on the
> +`xen.h` public header.
> +
> +### Initial amd64 control registers values ###
> +
> +Initial values for the control registers are set up by Xen before booting the
> +guest kernel. The guest kernel can expect to find the following features
> +enabled by Xen.
> +
> +On `CR0` the following bits are set by Xen:

"In ..." or "CR0 has the following bits set by Xen:".

> +
> +  * PE (bit 0): protected mode enable.
> +  * ET (bit 4): 80387 external math coprocessor.

This bit nothing to do with an external coprocessor, it simply says
387 or newer as opposed to 287.

> +  * PG (bit 31): paging enabled.
> +
> +On `CR4` the following bits are set by Xen:
> +
> +  * PAE (bit 5): PAE enabled.
> +
> +And finally on `EFER` the following features are enabled:
> +
> +  * LME (bit 8): Long mode enable.
> +  * LMA (bit 10): Long mode active.

Perhaps also worth clarifying which bits are guaranteed to be clear
(right now one might imply all others, but that's not something we
can guarantee with forward compatibility in mind). Further I think
EFLAGS wants mentioning here too, and perhaps the debug registers.

> +
> +All the segment selectors (`cs`, `ds`, `ss`, `es`, `fs` and `gs`), the
> +`FS.base` and `GS.base` MSRs are zeroed out.

For the selector registers, specifying what the hidden portions hold
is a must I think, at the very least for %cs and %ss.

> MSR registers should be treated
> +like native.

Not sure what this is intended to mean.

> +In order to register the callback IDT vector the `HVMOP_set_param` hypercall
> +is used with the following values:
> +
> +    domid = DOMID_SELF
> +    index = HVM_PARAM_CALLBACK_IRQ
> +    value = (0x2 << 56) | vector_value

If we don't have #define-s for these two numbers, we urgently ought
to add ones.

> +### IO APIC interrupt routing ###
> +
> +IO APIC interrupts can be routed over event channels using `PHYSDEVOP`
> +hypercalls. First the IRQ is registered using the `PHYSDEVOP_map_pirq`
> +hypercall, as an example IRQ#9 is used here:
> +
> +    domid = DOMID_SELF
> +    type = MAP_PIRQ_TYPE_GSI
> +    index = 9
> +    pirq = 9
> +
> +After this hypercall, `PHYSDEVOP_alloc_irq_vector` is used to allocate a 
> vector:
> +
> +    irq = 9
> +    vector = 0
> +
> +*TODO*: I'm not sure why we need those two hypercalls, and it's usage is not
> +documented anywhere. Need to clarify what the parameters mean and what effect
> +they have.

PHYSDEVOP_alloc_irq_vector has been a dummy for a very long time
now - nothing should break if this call got omitted.

> +*NOTE*: when running as Dom0, the guest has to parse the interrupt overwrites
> +found on the ACPI tables and notify Xen about them.

... overrides ...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel