Xen devel - Feb 2012 - [PATCH] xenpaging:close domU's event channel and free port

# HG changeset patch
# User h00166998@h00166998.china.huawei.com
# Date 1328777452 -28800
# Node ID 9f4640e40d4f31563885427a5a8d9eae2e110514
# Parent  8ba7ae0b070b4de93fc033067c61714c202d64c1
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.

Signed-off-byhongkaixing<hongkaixing@huawei.com>,shizhen<bicky.shi@huawei.com>

diff -r 8ba7ae0b070b -r 9f4640e40d4f xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c	Tue Feb 07 18:46:50 2012 +0000
+++ b/xen/arch/x86/mm/mem_event.c	Thu Feb 09 16:50:52 2012 +0800
@@ -241,7 +241,12 @@
             mem_event_ring_unlock(med);
             return -EBUSY;
         }
-
+        
+        if( med->shared_page!=NULL )
+        {
+            free_xen_event_channel(d->vcpu[0],
(med->shared_page)->port);
+        }
+             
         unmap_domain_page(med->ring_page);
         med->ring_page = NULL;
 


--===============8265311217137370442=Content-Type: text/plain;
charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============8265311217137370442==--

At 16:53 +0800 on 09 Feb (1328806434), hongkaixing@huawei.com
wrote:
> # HG changeset patch
> # User h00166998@h00166998.china.huawei.com
> # Date 1328777452 -28800
> # Node ID 9f4640e40d4f31563885427a5a8d9eae2e110514
> # Parent  8ba7ae0b070b4de93fc033067c61714c202d64c1
> 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.
Yep, looks like a bug.
> diff -r 8ba7ae0b070b -r 9f4640e40d4f xen/arch/x86/mm/mem_event.c
> --- a/xen/arch/x86/mm/mem_event.c	Tue Feb 07 18:46:50 2012 +0000
> +++ b/xen/arch/x86/mm/mem_event.c	Thu Feb 09 16:50:52 2012 +0800
> @@ -241,7 +241,12 @@
>              mem_event_ring_unlock(med);
>              return -EBUSY;
>          }
> -
> +        
> +        if( med->shared_page!=NULL )
> +        {
> +            free_xen_event_channel(d->vcpu[0],
(med->shared_page)->port);
> +        }
> +             
But you shouldn''t use the value from the shared page, in case it has
been corrupted by a buggy or malicious guest.  Can you please save the
event channel in a new field in struct mem_event_domain, so the guest
can''t overwrite it?

Cheers,

Tim.

On 09/02/12 08:53, hongkaixing@huawei.com wrote:
> # HG changeset patch
> # User h00166998@h00166998.china.huawei.com
> # Date 1328777452 -28800
> # Node ID 9f4640e40d4f31563885427a5a8d9eae2e110514
> # Parent  8ba7ae0b070b4de93fc033067c61714c202d64c1
> 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.
>
>
Signed-off-by??hongkaixing<hongkaixing@huawei.com>,shizhen<bicky.shi@huawei.com>
>
> diff -r 8ba7ae0b070b -r 9f4640e40d4f xen/arch/x86/mm/mem_event.c
> --- a/xen/arch/x86/mm/mem_event.c	Tue Feb 07 18:46:50 2012 +0000
> +++ b/xen/arch/x86/mm/mem_event.c	Thu Feb 09 16:50:52 2012 +0800
> @@ -241,7 +241,12 @@
>              mem_event_ring_unlock(med);
>              return -EBUSY;
>          }
> -
> +        
You have introduced trailing whitespace onto this line as part of the patch
> +        if( med->shared_page!=NULL )
> +        {
> +            free_xen_event_channel(d->vcpu[0],
(med->shared_page)->port);
> +        }
> +             
>          unmap_domain_page(med->ring_page);
>          med->ring_page = NULL;
>  
>
-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com

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.

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

> -----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.
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

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?

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?
> 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

On Mon, Feb 13, Hongkaixing wrote:
>    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.
> 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();
Are you sure its the event channel?

I just tried to run xenpaging in a loop and after a while I got this
instead:

xc: detail: xenpaging init
xc: detail: watching ''/local/domain/1/memory/target-tot_pages''
xc: error: Error initialising shared page (28 = No space left on device):
Internal error

Is it that what you are seeing?

Olaf

On Tue, Feb 14, Olaf Hering wrote:
> xc: error: Error initialising shared page (28 = No space left on device):
Internal error
After reading the code more carefully I now see that mem_event_enable()
calls alloc_unbound_xen_event_channel() and stores it into
med->xen_port. As Tim suggested, your patch should use this value
instead of relying on the shared_page pointer.

Olaf

> -----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

> -----Original Message-----
> From: Olaf Hering [mailto:olaf@aepfle.de]
> Sent: Wednesday, February 15, 2012 5:19 AM
> To: Hongkaixing
> 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 Tue, Feb 14, Olaf Hering wrote:
> 
> > xc: error: Error initialising shared page (28 = No space left on
device): Internal error
> 
> After reading the code more carefully I now see that mem_event_enable()
> calls alloc_unbound_xen_event_channel() and stores it into
> med->xen_port. As Tim suggested, your patch should use this value
> instead of relying on the shared_page pointer.
Thanks for your advices.

And In your another mail, you have mentioned the problem like this:

xc: detail: xenpaging init
xc: detail: watching ''/local/domain/1/memory/target-tot_pages''
xc: error: Error initialising shared page (28 = No space left on device):
Internal error

Yes, I am sure it is the error we have met before!
> 
> Olaf

On Wed, 2012-02-15 at 02:24 +0000, Hongkaixing wrote:
> 
> > -----Original Message-----
> > From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> > 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.
The two ends of that event channel are actually dom0 and Xen, because
chn->xen_consumer is not NULL, even though the Xen end does live in the
domU evtchn address space. It is not exactly dom0 and domU as you
suggest, which is where my confused question arose.

Ian.

> -----Original Message-----
> From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> Sent: Wednesday, February 15, 2012 5:27 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 Wed, 2012-02-15 at 02:24 +0000, Hongkaixing wrote:
> >
> > > -----Original Message-----
> > > From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> > > 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.
> 
> The two ends of that event channel are actually dom0 and Xen, because
> chn->xen_consumer is not NULL, even though the Xen end does live in the
> domU evtchn address space. It is not exactly dom0 and domU as you
> suggest, which is where my confused question arose.
   See what xenpaging_init() does when xenpaging is launched:
   xc_mem_paging_enable() ---> this function allocate a event channel of
domain U, the remote port is stored in paging->mem_event.shared_page->port
            |
            V
    Xc_event_bind_interdomain() --> this function bind dom0 with domU port
allocated above

   But when xenpaging is tear down:
   xc_mem_paging_disable()  -->  do nothing about event channel
            |
            V
   xc_evtchn_unbind()  -->  free the dom0 port, but leave remote port(domU ) 
ECS_UNBOUND


 Hong Kaixing.
> 
> Ian.

On Fri, 2012-02-17 at 06:21 +0000, Hongkaixing wrote:
> 
> > -----Original Message-----
> > From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> > Sent: Wednesday, February 15, 2012 5:27 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 Wed, 2012-02-15 at 02:24 +0000, Hongkaixing wrote:
> > >
> > > > -----Original Message-----
> > > > From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> > > > 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.
> > 
> > The two ends of that event channel are actually dom0 and Xen, because
> > chn->xen_consumer is not NULL, even though the Xen end does live in
the
> > domU evtchn address space. It is not exactly dom0 and domU as you
> > suggest, which is where my confused question arose.
> 
>    See what xenpaging_init() does when xenpaging is launched:
>    xc_mem_paging_enable() ---> this function allocate a event channel of
domain U, the remote port is stored in paging->mem_event.shared_page->port
>             |
>             V
>     Xc_event_bind_interdomain() --> this function bind dom0 with domU
port allocated above
> 
>    But when xenpaging is tear down:
>    xc_mem_paging_disable()  -->  do nothing about event channel
>             |
>             V
>    xc_evtchn_unbind()  -->  free the dom0 port, but leave remote
port(domU )  ECS_UNBOUND
I wasn''t querying the presence of the leak or the validity of the fix,
I
was asking what the domU event channel was even for (i.e. why does it
exist at all?).

I answered that myself in my previous mail -- it''s actually a Xen event
channel not a guest visible one.

Ian.
> 
> 
>  Hong Kaixing.
> 
> > 
> > Ian.
>

> -----Original Message-----
> From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> Sent: Friday, February 17, 2012 4:21 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 Fri, 2012-02-17 at 06:21 +0000, Hongkaixing wrote:
> >
> > > -----Original Message-----
> > > From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> > > Sent: Wednesday, February 15, 2012 5:27 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 Wed, 2012-02-15 at 02:24 +0000, Hongkaixing wrote:
> > > >
> > > > > -----Original Message-----
> > > > > From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> > > > > 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.
> > >
> > > The two ends of that event channel are actually dom0 and Xen,
because
> > > chn->xen_consumer is not NULL, even though the Xen end does
live in the
> > > domU evtchn address space. It is not exactly dom0 and domU as you
> > > suggest, which is where my confused question arose.
> >
> >    See what xenpaging_init() does when xenpaging is launched:
> >    xc_mem_paging_enable() ---> this function allocate a event
channel of domain U, the remote port is stored in
> paging->mem_event.shared_page->port
> >             |
> >             V
> >     Xc_event_bind_interdomain() --> this function bind dom0 with
domU port allocated above
> >
> >    But when xenpaging is tear down:
> >    xc_mem_paging_disable()  -->  do nothing about event channel
> >             |
> >             V
> >    xc_evtchn_unbind()  -->  free the dom0 port, but leave remote
port(domU )  ECS_UNBOUND
> 
> I wasn''t querying the presence of the leak or the validity of the
fix, I
> was asking what the domU event channel was even for (i.e. why does it
> exist at all?).
Sorry! The event channel is used to wake domU up when its page has already been
paged in.
> 
> I answered that myself in my previous mail -- it''s actually a Xen
event
> channel not a guest visible one.
> 
> Ian.
> 
> >
> >
> >  Hong Kaixing.
> >
> > >
> > > Ian.
> >