Re: [PATCH 10/17] PVH xen: introduce vmx_pvh.c and pvh.c

[Mukesh Rathor <mukesh.rathor@oracle.com>]

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