Re: [Xen-devel] RFC: very initial PVH design document

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 22.08.14 at 16:55, <roger.pau@xxxxxxxxxx> wrote:
> It is important to highlight the following notes:
> 
>   * XEN_ELFNOTE_ENTRY: contains the memory address of the kernel entry point.

... the virtual memory address ...

>   * XEN_ELFNOTE_HYPERCALL_PAGE: contains the memory address of the hypercall
>     page inside of the guest kernel (this memory region will be filled by Xen
>     prior to booting).

Same here.

>   * XEN_ELFNOTE_FEATURES: contains the list of features supported by the 
> kernel.
>     In this case the kernel is only able to boot as a PVH guest, but those

"In this case" is not clear what it relates to. You should probably say
something like "In the example above".

> Xen will jump into the kernel entry point defined in `XEN_ELFNOTE_ENTRY` with
> paging enabled (either long or protected mode depending on the kernel bitness)

If I understand right how 32-bit PVH is intended to function, "protected
mode" is insufficient to state here, it ought to be "paged protect mode"
or "protected mode with paging turned on".

> ## Physical devices ##
> 
> When running as Dom0 the guest OS has the ability to interact with the 
> physical
> devices present in the system. A note should be made that PVH guests require
> a working IOMMU in order to interact with physical devices.
> 
> The first step in order to manipulate the devices is to make Xen aware of
> them. Due to the fact that all the hardware description on x86 comes from
> ACPI, Dom0 is responsible of parsing the ACPI tables and notify Xen about 
> the
> devices it finds. This is done with the `PHYSDEVOP_pci_device_add` 
> hypercall.
> 
> *TODO*: explain the way to register the different kinds of PCI devices, like
> devices with virtual functions.

I think both the second paragraph and the TODO don't belong here,
as there's no difference to PV, and this shouldn't be subject of this
document.

> ## Interrupts ##
> 
> All interrupts on PVH guests are routed over event channels, see
> [Event Channel Internals][event_channels] for more detailed information 
> about
> event channels. In order to inject interrupts into the guest an IDT vector 
> is
> used. This is the same mechanism used on PVHVM guests, and allows having
> per-cpu interrupts that can be used to deliver timers or IPIs.
> 
> 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
> 
> In order to know which event channel has fired, we need to look into the
> information provided in the `shared_info` structure. The `evtchn_pending`
> array is used as a bitmap in order to find out which event channel has
> fired. Event channels can also be masked by setting it's port value in the
> `shared_info->evtchn_mask` bitmap.
> 
> *TODO*: provide a reference about how to interact with FIFO event channels?

Or better don't be event-channel-ABI specific in the paragraph right
before the TODO, as this again isn't PVH-specific? (There are more
such items further down which I'll not further comment on; actually
it looks like very little of the rest of the document is really on PVH.)

Jan


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