From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [PATCH 17/18 V2]: PVH xen: PVH dom0 creation... Date: Tue, 19 Mar 2013 09:32:19 -0400 Message-ID: <20130319133219.GE2706@phenom.dumpdata.com> References: <20130315180645.59f8618e@mantra.us.oracle.com> <51483D9602000078000C6A56@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <51483D9602000078000C6A56@nat28.tlf.novell.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: Jan Beulich Cc: xen-devel List-Id: xen-devel@lists.xenproject.org On Tue, Mar 19, 2013 at 09:27:34AM +0000, Jan Beulich wrote: > >>> On 16.03.13 at 02:06, Mukesh Rathor wrote: > > Finally, the hardest. Mostly modify construct_dom0() to boot PV dom0 in > > PVH mode. Introduce, opt_dom0pvh, which when specified in the command > > line, causes dom0 to boot in PVH mode. > > Now that Konrad mentioned that PVH is intended for 64-bit guests > only, I fail to see where this restriction is being enforced in this > patch. And it would certainly have been worthwhile to state that > more prominently, even more so since Konrad keeps telling people > that this patch set is expected to initiate a deprecation phase for > the PV MMU interfaces in Linux (which then would mean no 32-bit > PV guest support at all anymore). It was not in my mind for the first stage of this work, thought I have to admit that the 32-bit part completly vanished in my mind. You are right - we need then 32-bit support otherwise we are screwed in the X years we initiate the deprecation phase in the upstream PV MMU interface. I was not expecting that this set of patches would be the 'ok, the timer for deprecation is ticking once the patch goes in Xen' - rather when folks agree that it is the right time.