[Xen-devel] Re: Netfront problems

[Ewan Mellor <ewan@xxxxxxxxxxxxx>]

On Fri, Nov 25, 2005 at 11:05:06AM -0200, Murillo Bernardes wrote:

> Hi,
> 
> I'm trying to fix the following error on netfront, but no sucess until now.
>
> 1. Problem:
>  -  On netfront_closing we unregister the net device (calling close_netdev)
>  -  When the frontend directory on store is removed the netfront_remove() is 
> called, and we call netif_disconnect_backend(), but "&info->tx_lock", 
> "&info->rx_lock" , etc, are not valid anymore and we get an OOOPS.
> 
> 2. If I call netif_free() from netfront_closing() I get:
> "WARNING: g.e. still in use!
> WARNING: leaking g.e. and page still in use!
> WARNING: g.e. still in use!
> WARNING: leaking g.e. and page still in use!"
> 
> Because this pages (info->tx and info->rx) still in use by hypervisor/dom0.

Yes, I've been discussing this with Keir and Ian, following your bug report
and first patch.  It would be nice if we could tear down cleanly, even when
packets are in flight, but as you've found out, this is quite fiddly, as the
backend may hold outstanding references to transmitted packets.  The easiest
solution might be to simply refuse to close down unless the network interface
has been closed down in userspace, and then it should be much easier to close
down the driver, because there will be no packets being transmitted.  This
does not seem like an unreasonable restriction to me.

For the receive queue it will be necessary to drop packets in the queue, and
remove the grants on that queue so that no more packets are received.  This
may require more synchronisation between frontend and backend than we have
already, I'm not sure.

Basically, it's quite a complicated piece of work still.  Network hotplugging
has never worked before, and it seems that there is still plenty of work
needed on the driver before it can support it.  You are more than welcome to
work on it, but I think that you probably ought to speak to Keir, who
understands the driver better than I do, before plowing in.

Cheers,

Ewan.

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