Hi,
Sorry I missed this thread the first time around. I actually just ran
into this same bug myself while trying to further/solidify the
mem_paging/mem_event stuff. And, in fact, came to all the same
conclusions and even the exact same fix. I was going to clean it up
and push it out, but it looks like now I don't have to :)
I'd be happy for any suggestions you have about how to improve things.
I'm fully aware the grant table code likely doesn't work. Around the
time we were prepping the mem_paging/mem_sharing patches for
submittal, there had been a big change to grant table stuff and I
didn't have access to an ept box at the time. However, that is no
longer the case and I would be more than happy to look at any and all
issues you've been having.
Patrick
On 2 June 2010 18:12, Byrne, John (HP Labs) <john.l.byrne@xxxxxx> wrote:
> 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
>>
>
>
> _______________________________________________
> 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
|