|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] [Patch] continue_hypercall_on_cpu rework using tasklets
Keir Fraser wrote:
> On 15/04/2010 08:57, "Juergen Gross" <juergen.gross@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx
Domagkstr. 28 Internet: ts.fujitsu.com
D-80807 Muenchen Company details: ts.fujitsu.com/imprint.html
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- RE: [Xen-devel] [Patch] continue_hypercall_on_cpu rework using tasklets, (continued)
- Re: [Xen-devel] [Patch] continue_hypercall_on_cpu rework using tasklets, Keir Fraser
- RE: [Xen-devel] [Patch] continue_hypercall_on_cpu rework using tasklets, Jiang, Yunhong
- Re: [Xen-devel] [Patch] continue_hypercall_on_cpu rework using tasklets, Keir Fraser
- RE: [Xen-devel] [Patch] continue_hypercall_on_cpu rework using tasklets, Jiang, Yunhong
- Re: [Xen-devel] [Patch] continue_hypercall_on_cpu rework using tasklets, Keir Fraser
- RE: [Xen-devel] [Patch] continue_hypercall_on_cpu rework using tasklets, Jiang, Yunhong
- Re: [Xen-devel] [Patch] continue_hypercall_on_cpu rework using tasklets,
Juergen Gross <=
- Re: [Xen-devel] [Patch] continue_hypercall_on_cpu rework using tasklets, Keir Fraser
|
|
|
|
|