From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mukesh Rathor Subject: Re: [PATCH 02/18] PVH xen: add XENMEM_add_to_physmap_range Date: Fri, 7 Jun 2013 13:46:38 -0700 Message-ID: <20130607134638.0838901a@mantra.us.oracle.com> References: <1369445137-19755-1-git-send-email-mukesh.rathor@oracle.com> <1369445137-19755-3-git-send-email-mukesh.rathor@oracle.com> <51A8897602000078000D9F13@nat28.tlf.novell.com> <20130604173143.7ef56db1@mantra.us.oracle.com> <51AF05C402000078000DB564@nat28.tlf.novell.com> <20130605134146.2bb6b342@mantra.us.oracle.com> <51B04B9D02000078000DBC2A@nat28.tlf.novell.com> <20130606151945.3c2f6a97@mantra.us.oracle.com> <51B1961002000078000DC1C0@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <51B1961002000078000DC1C0@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 Fri, 07 Jun 2013 07:13:04 +0100 "Jan Beulich" wrote: > >>> On 07.06.13 at 00:19, Mukesh Rathor > >>> wrote: ... > I never said it's a regression. It's incomplete functionality you add. > Someone adding a use of this to PV or PV drivers, testing it on > 64-bit, may validly expect that this would work the same on 32-bit. > > > Moreover, in the past, you've asked to remove even the simplest > > benign line space change because it was unrelated to the patch. So > > changing something as part of PVH patchset for PV and HVM guests, > > wouldn't that be unrelated and contradictory to the message you've > > sent? > > In no way - I'm simply asking for consistency here. If you handled > the hypercall _only_ for PVH guests, and left the implementation > for 32-bit PVH out entirely because such guests can't work anyway > with the patch set in place, that would be consistent. But as said > before: This would artificially limit a hypercall, and that's a > separate reason not to accept such a partial implementation. One last time :), the hcall is *already* limited, I'm unlimiting it *one step at a time*. > > You've found some very genunie issues in the patchset, and I really > > appreciate that. But I struggle with this request. > > Then leave it out, and I'll waste my time on getting it implemented > once the patch set is in. But please add a clear note of this state > to the patch description. Ok, I'll add a note to the patch description. thanks Mukesh