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

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Thu, 2015-07-23 at 10:35 +0100, Andrew Cooper wrote:
> 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.

OK.


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