Re: [Xen-devel] [RFC 0 PATCH 3/3] PVH dom0: construct_dom0 changes

[Mukesh Rathor <mukesh.rathor@xxxxxxxxxx>]

On Wed, 9 Oct 2013 18:50:40 +0100
Tim Deegan <tim@xxxxxxx> wrote:

> At 08:30 -0400 on 08 Oct (1381221032), Konrad Rzeszutek Wilk wrote:
> > George Dunlap <george.dunlap@xxxxxxxxxxxxx> wrote:
> > >If it were just a question of cleaning up those bits, I could
> > >probably have another draft posted sometime this week.  But if
> > >we're stepping back and looking at whether this is the right
> > >approach, or whether something like Tim has suggested -- basically
> > >making PVH to be HVM minus 
> > >qemu plus a handful of hypercalls, and most of the changes in the
> > >domain 
> > >builder rather than in Xen -- that will take a bit longer,
> > >particularly
> > >
> > >because it would probably mean me having to understand and modify
> > >the Linux side of things as well.  At this point I'm not really
> > >sure what the best approach is going forward.
> > 
> > Arrg.  I am not really sure how to express myself here but from the
> > start Mukesh has asking for assistance and review of ideas and
> > design of this and gotten it and acted on it. Now after two years
> > of going this path folks are suggesting a new design?
> 
> Sorry for not making the suggestion sooner -- it honestly hadn't
> occurred to me.  I had read a number of revisions of the PVH Xen
> patches (and many discussions of what the new type of guests should
> be called) before thinking that there didn't need to be a new kind of
> guest at all.

The orig series didn't have a new guest type, but I was sorta compelled
to create one. From guest perspective, it's in PV mode with auto
translate. It appears this is now losing sight of the orig goal. The
main problem being solved was 64bit PV syscall overhead. The best way to
solve the sys call overhead was to run in HVM container. I discussed
briefly with Ian P and then Keir on the sidelines of xen summit. Then I
did code walk with Steffano and Ian C at hackathon last year. Looked
like we were all on same page.

Still, if something could be done better, I'm in favor. But, lets
get something done asap so as to not get left behind. Everyone will
have a different opinion on the best approach, and unless some
compromises are made things can just drag on..... 

> FWIW, I don't think this would be a complete redesign. AFAICT the
> guest kernel changes would stay as they are, and most of the
> toolstack changes too.  Some of the Xen changes would stay
> (implementation of setvcpuinfo, for example) and some would just go
> away.

Good idea, but keep in mind that dom0 will need most of the xen 
changes for coming in PVH mode. So, there might not be enough to make
it worthwhile.

thanks
Mukesh

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