[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.

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.

Anyway, given that I can't offer to help with the coding (I have
basically no time between now and XenSummit) I don't want to stand in
the way of this.  If it goes in in something like the current form I'll
try and work out a follow-up series that does it the other way.



Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.