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

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


  • To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
  • From: "Byrne, John (HP Labs)" <john.l.byrne@xxxxxx>
  • Date: Thu, 3 Jun 2010 01:12:36 +0000
  • Accept-language: en-US
  • Acceptlanguage: en-US
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Wed, 02 Jun 2010 18:18:17 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcriXnhomNarVb6UQu+V77DxbzJ2aAAAtYXcAAAFtnAAFMrLrQAjuYDwABPekEMAc9fMIAAav54mBzRLg7A=
  • Thread-topic: [Xen-devel] [PATCH[ event_lock not initialized in the idle domain (permitted actions in a tasklet?)

Keir,

Sorry this dropped into a hole for a month.

I've attached a patches against xen-4.0-testing 21172:6e77bf0852ec. It fixes 
the hangs related to the notify_xen_via_event_channel() by adding the domain 
argument. The tasklet is deleted because it seems to provide no value.

With a couple of minor tweaks, I got paging to work against the 2.6.18 kernel 
--- the driver changes are not in the pvops kernel --- but there is some actual 
design work needed to do things right. (The grant failure/retry and the paging 
daemon need thought.) I'd certainly be happy to talk about things if someone 
cares and perhaps do the actual work, if time permits.

Signed-off-by: John Byrne <john.l.byrne@xxxxxx>

> -----Original Message-----
> From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
> Sent: Monday, April 26, 2010 10:49 PM
> To: Byrne, John (HP Labs)
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-devel] event_lock not initialized in the idle domain
> (permitted actions in a tasklet?)
> 
> On 27/04/2010 00:01, "Byrne, John (HP Labs)" <john.l.byrne@xxxxxx>
> wrote:
> 
> >> I don't know what dom0 does while the page is paged in? Probably
> just
> >> throws an error code and carries on? In which case thinking about
> >> [prepare_]wait_on_xen_event_channel() further would not be
> necessary,
> >> as a dom0 code path can just notify on teh channel and carry on its
> >> way.
> >>
> >
> > That is the way it is supposed to work, but there seems to be a bit
> of a
> > disconnect between grant-table code and the driver mods to handle the
> errors.
> > The driver mods expect a new error code GNTST_eagain, but the
> grant_table code
> > returns ENOENT in a couple of places. There were also a couple of
> > "GNTxxx_can_fail" flags added to grant-table interface, but they are
> unused.
> > So things don't look quite finished.
> 
> Yeah, I think that is pretty much the situation.
> 
>  -- Keir
> 

Attachment: notify.patch
Description: notify.patch

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