[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [Patch] continue_hypercall_on_cpu rework using tasklets
On 19/04/2010 06:53, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx> wrote: >> Well, I think there are two issues: (1) we run the continuation as a >> softirq; (2) we don't run the continuation in the context of the original >> vcpu. I think (1) is a bigger problem than (2) as it introduces the >> possibility of all these nasty subtle deadlocks. (2) is obviously not >> desirable, *but* I don't think any callers much care about the context of >> the original caller, *and* if they do the resulting bug is generally going >> to be pretty obvious. That is, the hypercall just won't work, ever -- it's >> much less likely than (1) to result in very rare very subtle bugs. > > For issue 2, In fact this c_h_o_c is sometihng like xen action, i.e. it is > some utility provided by xen hypervisor that can be utilized by guest, so > maybe we can change the name of c_h_o_c, to be like call_xen_XXX? Well, the handler does provide the final hypercall return code, so it is still a hypercall continuation even if it doesn't run in the correct vcpu's context. > To your idle_vcpu context work, I think it is a bit like hvm domain waiting > for a IO assist from qemu (i.e., use prepare_wait_on_xen_event_channel()), is > it right? It's easier than that because the work flow does not leave the hypervisor itself. So we can simply pause/unpause the guest vcpu -- exactly as we are currently doing in the new tasklet-based c_h_o_c(). -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |