[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.