[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 10/17] PVH xen: introduce vmx_pvh.c and pvh.c
On Fri, 26 Apr 2013 08:20:11 +0100 "Jan Beulich" <JBeulich@xxxxxxxx> wrote: > >>> On 26.04.13 at 03:16, Mukesh Rathor <mukesh.rathor@xxxxxxxxxx> > >>> wrote: > > On Thu, 25 Apr 2013 09:36:56 +0100 "Jan Beulich" > > <JBeulich@xxxxxxxx> wrote: > >> >>> On 25.04.13 at 02:57, Mukesh Rathor <mukesh.rathor@xxxxxxxxxx> > >> >>> 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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |