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

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



It ought to be the destination domain's event-channel info that gets
accessed, not that of the domain that happens to be running currently. Idle
domains have no event-channel info because it makes no sense for them to
have it. I don't know what xenpaging code you are specifically referring to,
but sounds like it is simply broken.

 K.

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

> I am playing with the xenpaging code that was checked into xen 4.0 and I hit a
> bug because it sends an event channel notification from a tasklet which was
> getting run from the idle domain on my box. Since domain_create() does not
> perform the evtchn_init for the idle domain, the event_lock was not
> initialized and the tasklet would hang the cpu when it tried to acquire the
> lock.
> 
> While my immediate problem seems easy enough to work around --- I really can't
> see the reason for the tasklet in the first place, so I just got rid of it ---
> the underlying issue needs a look. Should domain_create() simply initialize
> all of the idle_domain structure?  As far as I can tell, the only reason it
> doesn't is to save a little memory. While the event_lock issue can be dealt
> with simply enough by breaking out the initialization separately, it seems
> that having the special-case code for the idle domain opens up the possibility
> for bugs with respect to operations from tasklets.
> 
> Thanks,
> 
> John Byrne
> 
>  
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel



_______________________________________________
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®.