Re: HVMlite ABI specification DRAFT B + implementation outline

[Boris Ostrovsky <boris.ostrovsky@oracle.com>]

On 02/08/2016 02:03 PM, Roger Pau Monné wrote:
>
>   * PCI BARs: it's not possible for Xen to know the position of the BARs of
>     the PCI devices without hardware domain interaction. In order to have
>     the BARs of PCI devices properly mapped the hardware domain needs to
>     call the PHYSDEVOP_pci_device_add hypercall, that will take care of setting
>     up the BARs in the guest physical memory map using 1:1 MMIO mappings. This
>     procedure will be transparent from guest point of view, and upon returning
>     from the hypercall mappings must be already established.

We also want to use PHYSDEVOP_pci_device_add because that's how we pass 
device's PXM information to the hypervisor.

>
> Xen HVMlite implementation plan
> ===============================
>
> This is of course not part of the ABI, but I guess it makes sense to add it
> here in order to be able to more easily split the tasks required in order to
> make the proposed implementation above a reality. I've tried to split
> the tasks into smaller sub-tasks when possible.
>
> DomU
> ----
>
>   1. Initial HVMlite implementation based on a HVM guest: no emulated devices
>      will be provided, interface exactly the same as a PVH guest except for the
>      boot ABI.
>
>   2. Provide ACPI tables to HVMlite guests: the initial set of provided tables
>      will be: RSDT, FADT, MADT (iff local APIC is enabled).
>
>   3. Enable the local APIC by default for HVMlite guests.
>
>   4. Provide options to xl/libxl in order to allow admins to select the
>      presence of a local APIC and IO APIC to HVMlite guests.
>
>   5. Implement an emulated PCI Root Complex inside of Xen.
>
>   6. Provide a DSDT table to HVMlite guests in order to signal the presence
>      of PCI-passthrough devices.
>
> IMHO, we should focus on (2) and (3) at the moment, and (4) is quite trivial
> once those two are in place. (5) and (6) should be implemented once HVMlite
> hardware domains are functional.
>
> When implementing (2) it would be good to place the ACPI related code in a
> place that's accessible from libxl, hvmloader and Xen itself, in order
> to reduce code duplication. hvmloader already has most if not all the required
> code in order to build the tables that are needed for HVMlite DomU.

Since I started poking at ACPI code in hvmloader anyway I can take a 
stab at (2).

-boris


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