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

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

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