From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juergen Gross Subject: Re: [PROPOSAL] Doing work in idle-vcpu context Date: Mon, 19 Apr 2010 07:00:07 +0200 Message-ID: <4BCBE357.7080104@ts.fujitsu.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: George Dunlap , "Jiang, Yunhong" , "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org Keir Fraser wrote: > 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? Sounds a little bit like my original proposal for the change of c_h_o_c(): Introduce a "hypervisor domain" for stuff like this. I still think, this would be cleaner. The hypervisor vcpus would run with high priority and they could block without rising major problems. Juergen -- Juergen Gross Principal Developer Operating Systems TSP ES&S SWE OS6 Telephone: +49 (0) 89 3222 2967 Fujitsu Technology Solutions e-mail: juergen.gross@ts.fujitsu.com Domagkstr. 28 Internet: ts.fujitsu.com D-80807 Muenchen Company details: ts.fujitsu.com/imprint.html