From mboxrd@z Thu Jan  1 00:00:00 1970
From: Mukesh Rathor <mukesh.rathor@oracle.com>
Subject: Re: [PATCH 10/17] PVH xen: introduce vmx_pvh.c and pvh.c
Date: Fri, 26 Apr 2013 19:06:19 -0700
Message-ID: <20130426190619.1de6d337@mantra.us.oracle.com>
References: <1366752366-16594-1-git-send-email-mukesh.rathor@oracle.com>
	<1366752366-16594-11-git-send-email-mukesh.rathor@oracle.com>
	<5177B85B02000078000D03CA@nat28.tlf.novell.com>
	<20130424175714.11d53ffc@mantra.us.oracle.com>
	<5179074802000078000D099C@nat28.tlf.novell.com>
	<20130425181628.5ea45b33@mantra.us.oracle.com>
	<517A46CB02000078000D0F84@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <517A46CB02000078000D0F84@nat28.tlf.novell.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel <xen-devel@lists.xen.org>
List-Id: xen-devel@lists.xenproject.org

On Fri, 26 Apr 2013 08:20:11 +0100
"Jan Beulich" <JBeulich@suse.com> wrote:

> >>> On 26.04.13 at 03:16, Mukesh Rathor <mukesh.rathor@oracle.com>
> >>> wrote:
> > On Thu, 25 Apr 2013 09:36:56 +0100 "Jan Beulich"
> > <JBeulich@suse.com> wrote:
> >> >>> On 25.04.13 at 02:57, Mukesh Rathor <mukesh.rathor@oracle.com>
> >> >>> wrote:
> >>> I am not sure I understant what you mean by copying
> >>> hypercall_table. You mean copy all the calls in this table above
> >>> from entry.S?  
> > 
> >>Yes - memcpy() the whole table, then overwrite the (few) entries
> >>you need to overwrite. After all, in the long run adding a new
> >>hypercall ought to "just work" for PVH (and in most cases even for
> > 
> > How would a poor soul who is trying to find all callers of do_xxx()
> > find it then? And is it really that often that hypercalls are added
> > that it is such a big deal?
> 
> It's no that often, but I nevertheless dislike that redundancy.
> Ideally there would be just one hypercall table (not considering
> the compat case, which has to have a different one because of
> the different calling convention), and the hypercall handlers
> would take care of the details...

I beg to differ.  I'll make my code DEBUG in next patch.  I'll let you
do the memcpy of the table - I wouldn't want my name on something I
consider to be bad software engineering practice.

thanks
Mukesh