WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] event_lock not initialized in the idle domain (permitted

To: "Byrne, John (HP Labs)" <john.l.byrne@xxxxxx>
Subject: RE: [Xen-devel] event_lock not initialized in the idle domain (permitted actions in a tasklet?)
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxxx>
Date: Sat, 24 Apr 2010 10:45:49 +0100
Accept-language: en-US
Acceptlanguage: en-US
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Sat, 24 Apr 2010 02:50:46 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <469F2699A483D44BA6D2B311B1089D3A7B08CA82D9@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <469F2699A483D44BA6D2B311B1089D3A7B08C465A2@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C7F70750.1238A%keir.fraser@xxxxxxxxxxxxx>, <469F2699A483D44BA6D2B311B1089D3A7B08CA82D9@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcriXnhomNarVb6UQu+V77DxbzJ2aAAAtYXcAAAFtnAAFMrLrQAjuYDwABPekEM=
Thread-topic: [Xen-devel] event_lock not initialized in the idle domain (permitted actions in a tasklet?)
Well, [prepare_]wait_on_xen_event_channel() makes no sense to call on another 
domain, certainly given their current implementation. But 
notify_via_xen_event_channel() could, and you could add a domain parameter to 
it.

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.

 -- Keir
________________________________________
From: Byrne, John (HP Labs) [john.l.byrne@xxxxxx]
Sent: Saturday, April 24, 2010 1:30 AM
To: Keir Fraser
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: RE: [Xen-devel] event_lock not initialized in the idle domain 
(permitted actions in a tasklet?)

Unfortunately, in the page sharing case as of now, p2m_mem_paging_populate() 
(which will eventually want to send the event) can be called from dom0 in the 
grant code. (Maybe you can see a way to re-engineer this, but it is not obvious 
to me.)  So, I need an interface that allows me to specify the domain. I don't 
see one for Xen event channels and the cleanest way I see to implement this is 
to simply add one. I'm certainly open to suggestions.

The handling in the grant code for paging is pretty ugly. There are a couple of 
holes. The biggest is that I don't see an obvious way to keep mapped grant 
pages from being evicted, again. However, I think it will work well enough for 
me to test what I need.

John




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