[Xen-devel] RE: [PROPOSAL] Doing work in idle-vcpu context

["Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>]

>-----Original Message-----
>From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
>Sent: Saturday, April 17, 2010 2:06 AM
>To: Jiang, Yunhong; George Dunlap; xen-devel@xxxxxxxxxxxxxxxxxxx
>Subject: [PROPOSAL] Doing work in idle-vcpu context
>
>George, Yunhong, and others,
>
>So, it seems that runing stop_machine_run(), and now
>continue_hypercall_on_cpu(), in softirq context is a bit of a problem.
>Because the softirq can stop the currently-running vcpu from being
>descheduled we can end up with subtle deadlocks. For example, with s_m_r()
>we try to rendezvous all cpus in softirq context -- we can have CPU A enter
>the softirq interrupting VCPU X, meanwhile VCPU Y on CPU B is spinning
>trying to pause VCPU X. Hence CPU B doesn't get into softirq, and so CPU A
>never leaves it, and we have deadlock.
>
>There are various possible solutions to this, but one of the architecturally
>neatest would be to run the s_m_r() and c_h_o_c() work in a
>'Linux-workqueue' type of environment -- i.e., in a proper non-guest vcpu
>context. Rather than introducing the whole kthread concept into Xen, one
>possibility would be to schedule this work on the idle vcpus -- effectively
>promoting idle vcpus to a more general kind of 'Xen worker vcpu' whose job
>can include running the idle loop.
>
>One bit of mechanism this would require is the ability to bump the idle vcpu
>priority up - preferably to 'max' priority forcing it to run next until we
>return it to idle/lowest priority. George: how hard would such a mechanism
>be to implement do you think?
>
>More generally: what do people think of this idea?

The only concern from me is, are there any assumption in other components that 
idle vcpu is always for idle, and is always lowest priority?

--jyh

>
> Thanks,
> Keir
>


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel