Re: [Xen-devel] [MINUTES] Monthly Xen.org Technical Call (2015-07-22)

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On July 23, 2015 5:08:46 AM EDT, Ian Campbell <ian.campbell@xxxxxxxxxx> wrote:
>On Wed, 2015-07-22 at 18:07 +0100, Ian Campbell wrote:
>> This was the rescheduled 8 July call, on the topic of PVH and related
>
>> work
>
>CCing people who were on the call this time.
>
>Perhaps a summary of what we discussed/agreed (AIUI) would be easier to
>(dis)agree with than the raw minutes:
>
>      * Going forward we will switch to using the hvmlite/no-dm
>        approach to PV, rather than the existing "classic PVH"
>        approach.
>      * Any work which is specific to classic PVH may as well stop, but
>        anything which is common to both approaches could continue
>              * Boris' classic-PVH 32-bit domU support is basically
>                ready and there were no strong objections to putting it
>                in (after the 4.6 freeze, of course).
>      * The entry point shall be a flat 32-bit, paging disabled, entry
>        point (same as hvmloader today)
>              * Discovery of the Xen entrypoint will be via an ELF note
>              * For Linux:
>                      * The Xen entrypoint shall point to a "stub" in
>                        the same vein of the UEFI stub.
>                      * The stub will set up a basic initial set of
>                        page tables, fills in bootinfo and then jump to
>                        the native 32- or 64-bit entry point as
>                        appropriate.Â
>                      * The stub can/should live in linux.git
>                        (presumably arch/x86/xen) but should be self
>                        -contained and isolated from the main body of
>                        Linux code. It does setup to impedance match
>                        the Xen entry point to the Linux native entry
>                        point.
>                      * Other things (e.g. lack of ACPI) should be
>                        addressed by fixing the native Linux entry path
>                        to be able to cope without them. Likewise
>                        installing PV hooks may need hypervisor
>                        detection to be moved earlier in the native
>                        boot path.
>              * For BSD:
>                      * I suppose Roger is on the case wrt agreeing
>                        things with the BSD maintainers. I think model
>                        is not dissimilar to that described for Linux.
>      * In Xen device models will be made optional and disabled.
>      * Secondary CPU bring up will be done using the PV paths
>      * Priority is to declare a stable API for basic domU use
>        excluding dom0, PCI passthrough and migration in the short
>        term. We are aiming to have this by ~January.
>
>Boris and Roger will be the primary people working on this. Roger will
>be looking at the no-dm loader side and then disabling Xen device
>models, Boris will be looking at the Linux stub aspect.
>
>There was talk about other things (e.g. VLAPIC using h/w support, UEFI
>firmware) but those are future considerations.

We forgot to speak about dom0. This work outlined will lay out how to do it - 
but the pieces for dom0 are not implemented and would need work (which actually 
may be following most of the is_pvh in the hypervisor).

>
>Ian.



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