[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] [Patch] continue_hypercall_on_cpu rework using tasklets




>-----Original Message-----
>From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
>Sent: Thursday, April 15, 2010 4:22 PM
>To: Juergen Gross
>Cc: xen-devel@xxxxxxxxxxxxxxxxxxx; Jiang, Yunhong
>Subject: Re: [Xen-devel] [Patch] continue_hypercall_on_cpu rework using 
>tasklets
>
>On 15/04/2010 09:13, "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx> wrote:
>
>> 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.
>
>Actually that's a good example because it now won't work, but for other
>reasons! The hypercall continuation can interrupt another vcpu's execution,
>and then try to synchronously pause that vcpu. Which will deadlock.
>
>Luckily I think we can re-jig this code to freeze_domains() before doing the
>continue_hypercall_on_cpu(). I've cc'ed one of the CPU RAS guys. :-)

Hmm, I have cc'ed one of the PM guys because it is enter_state :-)
Can we add check in vcpu_sleep_sync() for current? It is meaningless to 
cpu_relax for current vcpu in that situation, especially if we are not in irq 
context.
I'm not sure why in freeze_domains it only checkes dom0's vcpu for current, 
instead of all domains.

--jyh

>
> -- Keir
>


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.