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

[Roger Pau Monnà <roger.pau@xxxxxxxxxx>]

El 23/07/15 a les 11.08, Ian Campbell ha escrit:
> 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:

Thanks, this is a really good summary/plan of action IMHO.

>       * 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.

Just FYI, this is what I had planned for FreeBSD:

 - Entry point is a code32 section that setups page tables and jumps
into long mode. The page tables setup by the asm stub are exactly the
same as the ones that are created by the native FreeBSD loader (the low
1GiB of physical memory is mapped using 2MiB pages).
 - The asm stub calls into a Xen specific function that setups all the
necessary PV hooks, then the native FreeBSD early boot function is called.

>       * 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.

I will also update the design document about the boot protocol, and
possibly merge it into the PVH specification that's already committed to
Xen.

Roger.


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