From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [PATCH 2/18 V2]: PVH xen: add XENMEM_add_to_physmap_range Date: Tue, 19 Mar 2013 09:40:35 -0400 Message-ID: <20130319134035.GF2706@phenom.dumpdata.com> References: <20130315172018.395bbbe3@mantra.us.oracle.com> <51470ACC02000078000C64CB@nat28.tlf.novell.com> <20130318201532.GI27433@phenom.dumpdata.com> <5148327602000078000C6A00@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: <5148327602000078000C6A00@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 08:40:06AM +0000, Jan Beulich wrote: > >>> On 18.03.13 at 21:15, Konrad Rzeszutek Wilk wrote: > > On Mon, Mar 18, 2013 at 11:38:35AM +0000, Jan Beulich wrote: > >> >>> On 16.03.13 at 01:20, Mukesh Rathor wrote: > >> > In this patch we add a new function xenmem_add_to_physmap_range(), and > >> > change xenmem_add_to_physmap_once parameters so it can be called from > >> > xenmem_add_to_physmap_range. There is no PVH specific change here. > >> > > >> > Changes in V2: > >> > - Do not break parameter so xenmem_add_to_physmap_once() but pass in > >> > struct xen_add_to_physmap. > >> > > >> > Signed-off-by: Mukesh Rathor > >> > --- > >> > xen/arch/x86/mm.c | 82 > > +++++++++++++++++++++++++++++++++++++++++++++++++++-- > >> > 1 files changed, 79 insertions(+), 3 deletions(-) > >> > >> This continued to lack compat mode support (i.e. modification to > >> xen/arch/x86/x86_64/compat/mm.c:compat_arch_memory_op()). > > > > Do we need it? Only 64-bit kernels can use PVH - and that was from the start > > the idea. > > I wasn't really aware of that, but I certainly do mind implementing > a hypercall usable by a PV or HVM guest only half way. Or did I > overlook code refusing the particular sub-op for plain PV and plain > HVM guests? There were some patches in the series (I can't recall the names of them thought) that had some of the PV hypercalls return -EINVAL (or -ENOSYS as I suggested). I think it might be better to introduce one patch that would neuter the PV/HVM hypercalls that we don't want to support or can't yet (for example b/c we haven't fixed the bugs). Are you OK if those paths are done in the common code? Meaning say for the PHYSDEV_op hypercalls some return -ENOSYS? Or would doing it via the grand hypercall[0->X] table that was in one of the patches and filtering the unsafe hypercalls? That seems a much easier way and won't mess with the generic code paths? > > Jan >