From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Deegan Subject: Re: [RFC 0 PATCH 3/3] PVH dom0: construct_dom0 changes Date: Wed, 9 Oct 2013 18:50:40 +0100 Message-ID: <20131009175040.GD40780@ocelot.phlegethon.org> References: <5244064102000078000F69AF@nat28.tlf.novell.com> <20130926171737.071f118f@mantra.us.oracle.com> <524547CF02000078000F73F7@nat28.tlf.novell.com> <20131002175358.5f31579c@mantra.us.oracle.com> <524E820002000078000F8C16@nat28.tlf.novell.com> <20131007175852.6583ea0d@mantra.us.oracle.com> <5253D58602000078000F975C@nat28.tlf.novell.com> <5253D87802000078000F9771@nat28.tlf.novell.com> <5253D2E5.6040107@eu.citrix.com> <6b1ddd55-6b5f-4c1e-8c8b-70b0116afc5d@email.android.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1VTxuN-0000wd-SZ for xen-devel@lists.xenproject.org; Wed, 09 Oct 2013 17:50:52 +0000 Content-Disposition: inline In-Reply-To: <6b1ddd55-6b5f-4c1e-8c8b-70b0116afc5d@email.android.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Konrad Rzeszutek Wilk Cc: George Dunlap , xen-devel , keir.xen@gmail.com, Jan Beulich List-Id: xen-devel@lists.xenproject.org At 08:30 -0400 on 08 Oct (1381221032), Konrad Rzeszutek Wilk wrote: > George Dunlap 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. Cheers, Tim.