From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juergen Gross Subject: Re: [Patch] continue_hypercall_on_cpu rework using tasklets Date: Thu, 15 Apr 2010 10:29:21 +0200 Message-ID: <4BC6CE61.1010505@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: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org Keir Fraser wrote: > On 15/04/2010 08:57, "Juergen Gross" wrote: > >>> What revision did you test? I put in some fixes as c/s 21173. >> My highest c/s was 21167. >> c/s 21173 is hanging, too (sorry for the delay, but I had to remove my cpupool >> stuff due to the scheduler changes for credit2). > > Ah yes, just done a test myself (clearly my dom0 setup is not doing > microcode updates) and I've now fixed it as c/s 21176. Thanks! Great! Works for me, too. > >> Is a call of sync_vcpu_execstate() fro a tasklet really allowed? I don't >> think the ASSERTs in __sync_lazy_execstate() are all fulfilled in this case. > > Better hope so or e.g., > acpi_enter_sleep > ->continue_hypercall_on_cpu(enter_state_helper) > ->enter_state > ->freeze_domains > ->domain_pause > ->vcpu_sleep_sync > ->sync_vcpu_execstate > Also wouldn't work. > > There is only one ASSERT in __sync_lazy_execstate, and it's safe for this > case. Bear in mind that our softirqs always run in the context of whatever > domain happens to be running on that cpu currently -- they don't have their > own proper vcpu context. I don't see how it should be guaranteed that the current vcpu MUST be an idle one... > > By the by, your original attempt at synchronisation (spin on return value in > regs changing) was risky as it could be unbounded time before the vcpu > registers get copied out of the original cpu's stack. Especially during > early dom0 boot, when the system is very idle. Indeed. I realized my version had another flaw in case of nested calls of c_h_o_c: if one call would return a non-zero value and issue another call of c_h_o_c, the tasklet would hang for ever... Your version is cleaner. 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