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

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

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.

Ian.


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