[PATCH] xenpaging:close domU's event channel and free port

[PATCH] xenpaging:close domU's event channel and free port

[hongkaixing]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 1224 bytes --]

# 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;
         }
-
+        
+        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;
 


[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: [PATCH] xenpaging:close domU's event channel and free port

[Tim Deegan]

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.

Re: [PATCH] xenpaging:close domU's event channel and free port

[Andrew Cooper]

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

Re: [PATCH] xenpaging:close domU's event channel and free port

[Olaf Hering]

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

Re: [PATCH] xenpaging:close domU's event channel and free port

[Hongkaixing]

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

Re: [PATCH] xenpaging:close domU's event channel and free port

[Ian Campbell]

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

Re: [PATCH] xenpaging:close domU's event channel and free port

[Hongkaixing]

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

Re: [PATCH] xenpaging:close domU's event channel and free port

[Ian Campbell]

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.

Re: [PATCH] xenpaging:close domU's event channel and free port

[Hongkaixing]

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

Re: [PATCH] xenpaging:close domU's event channel and free port

[Ian Campbell]

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

Re: [PATCH] xenpaging:close domU's event channel and free port

[Hongkaixing]

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

Re: [PATCH] xenpaging:close domU's event channel and free port

[Olaf Hering]

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

Re: [PATCH] xenpaging:close domU's event channel and free port

[Olaf Hering]

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

Re: [PATCH] xenpaging:close domU's event channel and free port

[Hongkaixing]

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