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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 23/07/15 10:08, Ian Campbell 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.

I would not exclude migration from the basic domU use.  Migration is a
key feature of virtualisation, and being HVM-lite, means that the
existing HVM migration path should JustWork.

~Andrew

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