On 23/01/15 18:58, Luis R. Rodriguez wrote:
>
> Its not just hypercalls though, this is all about the interactions
> with multicalls no?
No. This applies to any preemptible hypercall and the toolstack doesn't
use multicalls for most of its work.
David
--
To unsubscribe from this list: send the
>>> On 23.01.15 at 19:58, wrote:
> On Fri, Jan 23, 2015 at 11:45:06AM +, David Vrabel wrote:
>> On 23/01/15 00:29, Luis R. Rodriguez wrote:
>> > @@ -1243,6 +1247,25 @@ void xen_evtchn_do_upcall(struct pt_regs *regs)
>> >set_irq_regs(old_regs);
>> > }
>> >
>> > +/*
>> > + * CONFIG_PREEMP
On Fri, Jan 23, 2015 at 11:45:06AM +, David Vrabel wrote:
> > + */
> > +void xen_end_upcall(struct pt_regs *regs)
> > +{
> > + if (xen_is_preemptible_hypercall(regs)) {
> > + int cpuid = smp_processor_id();
> > + if (_cond_resched())
> > + trace_xen_hyper
On Fri, Jan 23, 2015 at 11:45:06AM +, David Vrabel wrote:
> On 23/01/15 00:29, Luis R. Rodriguez wrote:
> > From: "Luis R. Rodriguez"
> >
> > Xen has support for splitting heavy work work into a series
> > of hypercalls, called multicalls, and preempting them through
> > what Xen calls contin
On 23/01/15 00:29, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> Xen has support for splitting heavy work work into a series
> of hypercalls, called multicalls, and preempting them through
> what Xen calls continuation [0]. Despite this though without
> CONFIG_PREEMPT preemption won't
