Re: Is: paravirt docs and diet. Was:Re: [Lguest] lguest: unhandled trap 13 and CONFIG_MICROCODE_INTEL_EARLY

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Fri, May 10, 2013 at 11:07:10AM -0700, H. Peter Anvin wrote:
> More of a time target... even if far out.

The PVH (which is what Mukesh CC-ed here) not yet in the hypervisor
(even as an experiemental case). When that is in, and it works with
the base test-cases (launching guests, migration, etc) that would
start the clock.

We chatted about this last year at the Xen Developer meeting to
make sure we all are comfortable with this and also with the time
target. Which if I recall correctly was +5 years from the start of
the the base test-cases working and the PVH feature turned from
experimental to working.

Just to iterate, this would mean that a lot of paravirt MMU parts
would not been needed anymore.

Please note that 'killing PV' is a bit of broad word. The PV
(paravirtualization) of say drivers - so that we don't use emulated
drivers, or use faster IPIs, or what not - would not be eliminated.

This is just about paravirt ops reduction.

> 
> Matt Wilson <msw@amazon.com> wrote:
> 
> >On Fri, May 10, 2013 at 10:19:16AM -0700, H. Peter Anvin wrote:
> >> On 05/10/2013 07:51 AM, Konrad Rzeszutek Wilk wrote:
> >> > I hope it is clear that there is no resistance from me in this
> >diet-program.
> >> > The issue I face to help you are the same you do: priority - those
> >merge windows,
> >> > darn bugs, regressions, etc.
> >> 
> >> Of course.  Ultimately, we don't want to break things.  I would like
> >to
> >> see the Xen community more committed to a roadmap toward killing PV
> >in
> >> favor of HVM or what you call hybrid.
> >
> >I think that there is broad agreement both that we want to move in
> >that direction, and also that a migration will take time to realize.
> >
> >When you say "more committed," are you thinking of a declared
> >schedule? Or perhaps more visible progress toward that goal?
> >
> >--msw
> 
> -- 
> Sent from my mobile phone. Please excuse brevity and lack of formatting.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>