On Wed, Jan 21, 2015 at 07:07:36PM -0800, Andy Lutomirski wrote: > On Wed, Jan 21, 2015 at 6:17 PM, Luis R. Rodriguez > <mcg...@do-not-panic.com> wrote: > > From: "Luis R. Rodriguez" <mcg...@suse.com> > > > > On kernels with voluntary or no preemption we can run > > into situations where a hypercall issued through userspace > > will linger around as it addresses sub-operatiosn in kernel > > context (multicalls). Such operations can trigger soft lockup > > detection. > > > > We want to address a way to let the kernel voluntarily preempt > > such calls even on non preempt kernels, to address this we first > > need to distinguish which hypercalls fall under this category. > > This implements xen_is_preemptible_hypercall() which lets us do > > just that by adding a secondary hypercall page, calls made via > > the new page may be preempted. > > > > Andrew had originally submitted a version of this work [0]. > > > > [0] http://lists.xen.org/archives/html/xen-devel/2014-02/msg01056.html > > > > Based on original work by: Andrew Cooper <andrew.coop...@citrix.com> > > > > Cc: Andy Lutomirski <l...@amacapital.net> > > Cc: Borislav Petkov <b...@suse.de> > > Cc: David Vrabel <david.vra...@citrix.com> > > Cc: Thomas Gleixner <t...@linutronix.de> > > Cc: Ingo Molnar <mi...@redhat.com> > > Cc: "H. Peter Anvin" <h...@zytor.com> > > Cc: x...@kernel.org > > Cc: Steven Rostedt <rost...@goodmis.org> > > Cc: Masami Hiramatsu <masami.hiramatsu...@hitachi.com> > > Cc: Jan Beulich <jbeul...@suse.com> > > Cc: linux-ker...@vger.kernel.org > > Signed-off-by: Luis R. Rodriguez <mcg...@suse.com> > > --- > > arch/x86/include/asm/xen/hypercall.h | 20 ++++++++++++++++++++ > > arch/x86/xen/enlighten.c | 7 +++++++ > > arch/x86/xen/xen-head.S | 18 +++++++++++++++++- > > 3 files changed, 44 insertions(+), 1 deletion(-) > > > > diff --git a/arch/x86/include/asm/xen/hypercall.h > > b/arch/x86/include/asm/xen/hypercall.h > > index ca08a27..221008e 100644 > > --- a/arch/x86/include/asm/xen/hypercall.h > > +++ b/arch/x86/include/asm/xen/hypercall.h > > @@ -84,6 +84,22 @@ > > > > extern struct { char _entry[32]; } hypercall_page[]; > > > > +#ifndef CONFIG_PREEMPT > > +extern struct { char _entry[32]; } preemptible_hypercall_page[]; > > A comment somewhere explaining why only non-preemptible kernels have > preemptible hypercalls might be friendly to some future reader. :)
Good idea, since this section is arch specific, I'll instead add a blurb explaining this on the upcall. > > + > > +static inline bool xen_is_preemptible_hypercall(struct pt_regs *regs) > > +{ > > + return !user_mode_vm(regs) && > > + regs->ip >= (unsigned long)preemptible_hypercall_page && > > + regs->ip < (unsigned long)preemptible_hypercall_page + > > PAGE_SIZE; > > +} > > This makes it seem like the page is indeed one page long, but I don't > see what actually allocates a whole page for it. What am I missing? arch/x86/xen/xen-head.S .pushsection .text .balign PAGE_SIZE ENTRY(hypercall_page) #ifndef CONFIG_PREEMPT ENTRY(preemptible_hypercall_page) .skip PAGE_SIZE #endif /* CONFIG_PREEMPT */ Does that suffice to be sure? Luis _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel