Re: [Xen-devel] event_lock not initialized in the idle domain (permitted actions in a tasklet?)

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

On 22/04/2010 23:20, "Byrne, John (HP Labs)" <john.l.byrne@xxxxxx> wrote:

> The prepare_wait_on_xen_event_channel() looks to be totally bogus. The
> notify_via_xen_event_channel() is the source of my problem. The first thing it
> does is grab the lock on the current domain. If the tasklet is running on the
> idle domain, it hangs because the event_lock of the current domain is not
> initialized. Looking at the code for notify_via_xen_event_channel() more
> carefully, it seems it should be calling evtchn_send() instead.
> 
> I could provide a patch that does this. As I said in the my first e-mail, I
> don't see any advantage in doing the notification from a tasklet and my
> inclination would be to delete it as well and just make the call directly. I'm
> a little worried that I am only interested in xenpaging at the moment and it
> looks like it might impact the sharing path as well.

I think your approach of removing the tasklet was the correct one. See
arch/x86/hvm/hvm.c:hvm_send_assist_req() for an example of correct usage of
the *_xen_event_channel() helpers. Firstly, that function doesn't run as a
tasklet; Secondly, in fact 'v' *always* is current. Possibly we should even
ASSERT that on entry to the function to make it clearer.

I think that the correct functions probably are being used, just in the
wrong context. The aim after all is to pause the current vcpu until it
receives assistance from a helper in dom0. That is similar to the existing
(correct) use of *_xen_event_channel() which is to pause an HVM vcpu which
requires help from qemu-dm in a stubdomain or dom0 process.

 -- Keir



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