[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] xenpaging:close domU's event channel and free port
> -----Original Message----- > From: Ian Campbell [mailto:Ian.Campbell@xxxxxxxxxx] > Sent: Monday, February 13, 2012 8:12 PM > To: Hongkaixing > Cc: 'Olaf Hering'; bicky.shi@xxxxxxxxxx; xiaowei.yang@xxxxxxxxxx; > xen-devel@xxxxxxxxxxxxxxxxxxx; yanqiangjun@xxxxxxxxxx; > hanweidong@xxxxxxxxxx > Subject: Re: [Xen-devel] [PATCH] xenpaging:close domU's event channel and > free port > > On Mon, 2012-02-13 at 05:47 +0000, Hongkaixing wrote: > > > > > -----Original Message----- > > > From: Olaf Hering [mailto:olaf@xxxxxxxxx] > > > Sent: Saturday, February 11, 2012 12:40 AM > > > To: hongkaixing@xxxxxxxxxx > > > Cc: xen-devel@xxxxxxxxxxxxxxxxxxx; yanqiangjun@xxxxxxxxxx; > > > bicky.shi@xxxxxxxxxx; xiaowei.yang@xxxxxxxxxx; > > > hanweidong@xxxxxxxxxx > > > Subject: Re: [PATCH] xenpaging:close domU's event channel and free port > > > > > > On Thu, Feb 09, hongkaixing@xxxxxxxxxx wrote: > > > > > > > xenpaging:close domU's event channel and free port > > > > > > > > Every domain (X86 64 bit)has 4096 event channels.In source code, > > > > domU's event channel is allocated in mem_event_enable(),but just > > > > unbind dom0's event channel in xenpaging_teardown().This bug will > > > > result in that we can not use xenpaging after reopening it for 4096 > > > > times.We should free domU's event channel in mem_event_disable().so > > > > that we can reuse the port. > > > > > > Does that fix a real bug? > > > > > > xenpaging_teardown() does both xc_mem_paging_disable() and > > > xc_evtchn_unbind(). The former fails often because the domain is gone > > > and so it doesnt even reach the function in mem_event.c. > > > The latter is called unconditionally. > > > > I have tested whether the kernel driver does a cleanup of all used ports > > once xenpaging exits. > > Every domain has 1024 event channels.In xc_evtchn_unbind(),it just frees > > dom0's event channel's port, > > and changes its state to be ECS_FREE;but the remote domain(domU)'s port is > > still ECS_UNBOUND. > > Perhaps I'm misunderstanding something and/or showing my ignorance about > how xenpaging works but why does paging need a domU event channel > anyway? Surely paging is transparent to the guest. > > Or is this really a dom0<->Xen event channel which just appears to be > assigned to the guest? In xenpaging source code, there is an inter-domain event channel between dom0 and domU. > > Who assigns this remote domain port? Shouldn't it either be closed when > the dom0 end is closed or retained such that it can be reused each time > instead of leaking? In mem_event_enable(), the function alloc_unbound_xen_event_channel() allocates a free port for domU, and assigns to xen_consumer;When xenpaging tears down, it just frees dom0's event channel port by xc_evtchn_unbind(), leaves domU's port still occupied. So we should add the patch to free domU's port when xenpaging exits. > > > so when each domU triggers 1024 times of xenpaging,it will fail of "Error > > initialising shared page > > (28 = No space left on device): Internal error".Because there is no > > available free port for this domU. > > Only the port's state is ECS_FREE,then it can be allocated by > > get_free_port(); > > > > > > > > > > Also I would expect that once xenpaging exits the kernel driver does a > > > cleanup of all used ports. I havent checked wether thats true. > > > > > > Olaf > > > > > > _______________________________________________ > > 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |