All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hongkaixing <hongkaixing@huawei.com>
To: 'Ian Campbell' <Ian.Campbell@citrix.com>
Cc: xiaowei.yang@huawei.com, 'Olaf Hering' <olaf@aepfle.de>,
	xen-devel@lists.xensource.com, hanweidong@huawei.com,
	yanqiangjun@huawei.com, bicky.shi@huawei.com
Subject: Re: [PATCH] xenpaging:close domU's event channel and free port
Date: Wed, 15 Feb 2012 10:24:37 +0800	[thread overview]
Message-ID: <003001cceb88$f7302930$e5907b90$@com> (raw)
In-Reply-To: <1329135113.31256.77.camel@zakaz.uk.xensource.com>



> -----Original Message-----
> From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> Sent: Monday, February 13, 2012 8:12 PM
> To: Hongkaixing
> Cc: 'Olaf Hering'; bicky.shi@huawei.com; xiaowei.yang@huawei.com; xen-devel@lists.xensource.com; yanqiangjun@huawei.com;
> hanweidong@huawei.com
> 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@aepfle.de]
> > > Sent: Saturday, February 11, 2012 12:40 AM
> > > To: hongkaixing@huawei.com
> > > Cc: xen-devel@lists.xensource.com; yanqiangjun@huawei.com; bicky.shi@huawei.com; xiaowei.yang@huawei.com;
> > > hanweidong@huawei.com
> > > Subject: Re: [PATCH] xenpaging:close domU's event channel and free port
> > >
> > > On Thu, Feb 09, hongkaixing@huawei.com 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@lists.xensource.com
> > http://lists.xensource.com/xen-devel

  reply	other threads:[~2012-02-15  2:24 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-09  8:53 [PATCH] xenpaging:close domU's event channel and free port hongkaixing
2012-02-10 16:22 ` Tim Deegan
2012-02-10 16:32 ` Andrew Cooper
2012-02-10 16:40 ` Olaf Hering
2012-02-13  5:47   ` Hongkaixing
2012-02-13 12:11     ` Ian Campbell
2012-02-15  2:24       ` Hongkaixing [this message]
2012-02-15  9:27         ` Ian Campbell
2012-02-17  6:21           ` Hongkaixing
2012-02-17  8:20             ` Ian Campbell
2012-02-17 10:28               ` Hongkaixing
2012-02-14 20:59     ` Olaf Hering
2012-02-14 21:19       ` Olaf Hering
2012-02-15  2:33         ` Hongkaixing

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='003001cceb88$f7302930$e5907b90$@com' \
    --to=hongkaixing@huawei.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=bicky.shi@huawei.com \
    --cc=hanweidong@huawei.com \
    --cc=olaf@aepfle.de \
    --cc=xen-devel@lists.xensource.com \
    --cc=xiaowei.yang@huawei.com \
    --cc=yanqiangjun@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.