Xen devel - Jan 2013 - [PATCH] Add support for netconsole driver used on bridge device with VIF attached

When starting a VM which has virtual interface attached to the same bridge (i.e
vif = [type=netfront,bridge=xenbr0''] in vm.cfg) which is used for
netconsole the
following message appears (after about 60 seconds) and VM creation operation
fails.
     Error: Device 0 (vif) could not be connected. Hotplug scripts not working.

Note:
When trying to do the opposite, i.e. first create VM and then run
netconsole we got the error #524 - vif2.0 doesn''t support polling,
aborting.

As i see it, netconsole driver requires ndo_poll_controller from the
device''s controlling driver (function __netpoll_setup in
net/core/netpoll.c), a thing that is not supported currently in xen_netback
driver which is the driver that runs on dom0 and serve VM''s virtual
interface.

The following patch (to latest kernel) fix this bug by adding implementation to
ndo_poll_controller.

0001-Add-support-for-netconsole-driver-used-on-bridge-dev.patch
0 2001
From: Yuval <yuval.shaia@oracle.com>
Date: Tue, 8 Jan 2013 10:08:45 +0200
Subject: [PATCH] Add support for netconsole driver used on bridge device with
 VIF attached

Signed-off-by: Yuval <yuval.shaia@oracle.com>
---
 drivers/net/xen-netback/interface.c |    8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/net/xen-netback/interface.c
b/drivers/net/xen-netback/interface.c
index 601ae2a..10751f5 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -179,6 +179,13 @@ static u32 xenvif_fix_features(struct net_device *dev, u32
features)
 	return features;
 }
 
+static void xenvif_poll_controller(struct net_device *dev)
+{
+	disable_irq(dev->irq);
+	xenvif_interrupt(dev->irq, dev);
+	enable_irq(dev->irq);
+}
+
 static const struct xenvif_stat {
 	char name[ETH_GSTRING_LEN];
 	u16 offset;
@@ -237,6 +244,7 @@ static const struct net_device_ops xenvif_netdev_ops = {
 	.ndo_stop	= xenvif_close,
 	.ndo_change_mtu	= xenvif_change_mtu,
 	.ndo_fix_features = xenvif_fix_features,
+	.ndo_poll_controller = xenvif_poll_controller,
 };
 
 struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
-- 
1.7.9.5

On Mon, 2013-01-21 at 17:17 +0000, Yuval Shaia wrote:
> When starting a VM which has virtual interface attached to the same 
> bridge (i.e vif = [type=netfront,bridge=xenbr0''] in vm.cfg) which
is
> used for netconsole the
> following message appears (after about 60 seconds) and VM creation 
> operation fails.
>       Error: Device 0 (vif) could not be connected. Hotplug scripts not 
> working.
I''m not sure how this can relate netconsole since this happens before
the guest even runs, doesn''t it?
> As i see it, netconsole driver requires ndo_poll_controller from the
> device''s controlling driver (function __netpoll_setup in
> net/core/netpoll.c), a thing that is not supported currently in
> xen_netback driver which is the driver that runs on dom0 and serve
> VM''s virtual interface.
Which domain is using netconsole? Is it dom0 or domU? What parameters do
you give it?

I assume it is the domU but if that''s the case I don''t see why
a netback
rather than netfront patch would be required.

Or is dom0 doing netconsole where the log receiver is a domU?

Ian.

On 01/21/2013 07:28 PM, Ian Campbell wrote:
> On Mon, 2013-01-21 at 17:17 +0000, Yuval Shaia wrote:
>
>> When starting a VM which has virtual interface attached to the same
>> bridge (i.e vif = [type=netfront,bridge=xenbr0''] in vm.cfg)
which is
>> used for netconsole the
>> following message appears (after about 60 seconds) and VM creation
>> operation fails.
>>        Error: Device 0 (vif) could not be connected. Hotplug scripts
not
>> working.
> I''m not sure how this can relate netconsole since this happens
before
> the guest even runs, doesn''t it?
Running the same scenario without netconsole runs
smoothly.
>
>> As i see it, netconsole driver requires ndo_poll_controller from the
>> device''s controlling driver (function __netpoll_setup in
>> net/core/netpoll.c), a thing that is not supported currently in
>> xen_netback driver which is the driver that runs on dom0 and serve
>> VM''s virtual interface.
> Which domain is using netconsole? Is it dom0 or domU? What parameters do
> you give it?
dom0.
parameters:
netconsole=1111@src-ip/xenbr0,2002@dst-ip/dst-mac
>
> I assume it is the domU but if that''s the case I don''t
see why a netback
> rather than netfront patch would be required.
>
> Or is dom0 doing netconsole where the log receiver is a domU?
Log received at dom0 as output of xm cr vm.cfg command.
netconsole is used on dom0 to monitor its log
>
> Ian.
>

On Mon, 2013-01-21 at 18:00 +0000, yuval.shaia@oracle.com
wrote:
> On 01/21/2013 07:28 PM, Ian Campbell wrote:
> > On Mon, 2013-01-21 at 17:17 +0000, Yuval Shaia wrote:
> >
> >> When starting a VM which has virtual interface attached to the
same
> >> bridge (i.e vif = [type=netfront,bridge=xenbr0''] in
vm.cfg) which is
> >> used for netconsole the
> >> following message appears (after about 60 seconds) and VM creation
> >> operation fails.
> >>        Error: Device 0 (vif) could not be connected. Hotplug
scripts not
> >> working.
> > I''m not sure how this can relate netconsole since this
happens before
> > the guest even runs, doesn''t it?
> Running the same scenario without netconsole runs smoothly.
But why? I can''t make sense of your scenario and therefore cannot
explain why this patch would make any difference. Perhaps your patch is
just papering over some other issue?
> >> As i see it, netconsole driver requires ndo_poll_controller from
the
> >> device''s controlling driver (function __netpoll_setup in
> >> net/core/netpoll.c), a thing that is not supported currently in
> >> xen_netback driver which is the driver that runs on dom0 and serve
> >> VM''s virtual interface.
> > Which domain is using netconsole? Is it dom0 or domU? What parameters
do
> > you give it?
> dom0.
> parameters: netconsole=1111@src-ip/xenbr0,2002@dst-ip/dst-mac
You give these parameters to dom0 so that dom0''s own logs are sent to
some other host? 

Are dst-ip and dst-mac a domain on the same host or are they some offbox
logging service?

I can see why the *bridge* device might need an ndo_poll_controller hook
in this setup but I can''t see any reason why the netback device would
need one.
> >
> > I assume it is the domU but if that''s the case I
don''t see why a netback
> > rather than netfront patch would be required.
> >
> > Or is dom0 doing netconsole where the log receiver is a domU?
> Log received at dom0 as output of xm cr vm.cfg command.
> netconsole is used on dom0 to monitor its log
Are you now saying that logging goes from domU to dom0? Which is it?

In this scenario there is really no reason I can see that netback would
need an ndo_poll_controller hook -- that would be needed in the domU in
the netfront driver.

Please can you explain the exact code path which results in this new
hook being called.

BTW looking at the patch as it is any use of this hook should be wrapped
in CONFIG_NET_POLL_CONTROLLER.

Ian.

On 01/22/2013 11:23 AM, Ian Campbell wrote:
> On Mon, 2013-01-21 at 18:00 +0000, yuval.shaia@oracle.com wrote:
>> On 01/21/2013 07:28 PM, Ian Campbell wrote:
>>> On Mon, 2013-01-21 at 17:17 +0000, Yuval Shaia wrote:
>>>
>>>> When starting a VM which has virtual interface attached to the
same
>>>> bridge (i.e vif = [type=netfront,bridge=xenbr0''] in
vm.cfg) which is
>>>> used for netconsole the
>>>> following message appears (after about 60 seconds) and VM
creation
>>>> operation fails.
>>>>         Error: Device 0 (vif) could not be connected. Hotplug
scripts not
>>>> working.
>>> I''m not sure how this can relate netconsole since this
happens before
>>> the guest even runs, doesn''t it?
>> Running the same scenario without netconsole runs smoothly.
> But why? I can''t make sense of your scenario and therefore cannot
> explain why this patch would make any difference. Perhaps your patch is
> just papering over some other issue?
>
>>>> As i see it, netconsole driver requires ndo_poll_controller
from the
>>>> device''s controlling driver (function __netpoll_setup
in
>>>> net/core/netpoll.c), a thing that is not supported currently in
>>>> xen_netback driver which is the driver that runs on dom0 and
serve
>>>> VM''s virtual interface.
>>> Which domain is using netconsole? Is it dom0 or domU? What
parameters do
>>> you give it?
>> dom0.
>> parameters: netconsole=1111@src-ip/xenbr0,2002@dst-ip/dst-mac
> You give these parameters to dom0 so that dom0''s own logs are sent
to
> some other host?
>
> Are dst-ip and dst-mac a domain on the same host or are they some offbox
> logging service?
Sorry, my mistake, i should have attach network setup at first.

Anyway, here is my setup:
---------- ----------
| Host A |--bond0 -- | Host B |
|--------| |--xenbr0 | |
| VM A1 |--vif1.0 -- | | |
---------- | ----------
| |
---------------------------------------------
| LAN |
---------------------------------------------


I''m using netconsole to capture logs from Host-A and send them to
Host-B.
Host-A and Host-B are separate hosts (running XEN) which are connected 
to the same LAN.

src-ip is Host-A address.
dst-ip/mac is Host-B address.
>
> I can see why the *bridge* device might need an ndo_poll_controller hook
> in this setup but I can''t see any reason why the netback device
would
> need one.
Please note that without netback driver netconsole runs fine, i.e before 
trying to create VM which attached to the bridge.
>
>>> I assume it is the domU but if that''s the case I
don''t see why a netback
>>> rather than netfront patch would be required.
>>>
>>> Or is dom0 doing netconsole where the log receiver is a domU?
>> Log received at dom0 as output of xm cr vm.cfg command.
>> netconsole is used on dom0 to monitor its log
> Are you now saying that logging goes from domU to dom0? Which is it?
>
> In this scenario there is really no reason I can see that netback would
> need an ndo_poll_controller hook -- that would be needed in the domU in
> the netfront driver.
netback comes to play as soon as i''m attaching virtual interface to a 
bridge and since this bridge is under netconsole monitoring the function 
is triggered. Up to that point there is no issue getting logs in Host-B 
so i assume the problem is not with the bridge driver.
>
> Please can you explain the exact code path which results in this new
> hook being called.
init_netconsole() in netconsole.c -> alloc_param_target() -> 
netpoll_setup() in netpoll.c -> __netpoll_setup() which check if 
ndo_poll_controller() operation is supported.
>
> BTW looking at the patch as it is any use of this hook should be wrapped
> in CONFIG_NET_POLL_CONTROLLER.
>
> Ian.
>


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

On Tuesday 22 January 2013 11:23:32 am Ian Campbell
wrote:
> On Mon, 2013-01-21 at 18:00 +0000, yuval.shaia@oracle.com wrote:
> > On 01/21/2013 07:28 PM, Ian Campbell wrote:
> > > On Mon, 2013-01-21 at 17:17 +0000, Yuval Shaia wrote:
> > >> When starting a VM which has virtual interface attached to
the same
> > >> bridge (i.e vif = [type=netfront,bridge=xenbr0''] in
vm.cfg) which is
> > >> used for netconsole the
> > >> following message appears (after about 60 seconds) and VM
creation
> > >> operation fails.
> > >>        Error: Device 0 (vif) could not be connected. Hotplug
scripts
> > >> not working.
> > >
> > > I''m not sure how this can relate netconsole since this
happens before
> > > the guest even runs, doesn''t it?
> >
> > Running the same scenario without netconsole runs smoothly.
> 
> But why? I can''t make sense of your scenario and therefore cannot
> explain why this patch would make any difference. Perhaps your patch is
> just papering over some other issue?
> 
> > >> As i see it, netconsole driver requires ndo_poll_controller
from the
> > >> device''s controlling driver (function
__netpoll_setup in
> > >> net/core/netpoll.c), a thing that is not supported currently
in
> > >> xen_netback driver which is the driver that runs on dom0 and
serve
> > >> VM''s virtual interface.
> > >
> > > Which domain is using netconsole? Is it dom0 or domU? What
parameters
> > > do you give it?
> >
> > dom0.
> > parameters: netconsole=1111@src-ip/xenbr0,2002@dst-ip/dst-mac
> 
> You give these parameters to dom0 so that dom0''s own logs are sent
to
> some other host?
> 
> Are dst-ip and dst-mac a domain on the same host or are they some offbox
> logging service?
Sorry, my mistake, i should have attach network setup at first.
Anyway, here is my setup:
----------                       ----------
| Host A |--bond0--->|           | Host B |
|--------|           |--xenbr0   |        |
| VM A1  |--vif1.0-->|     |     |        |
----------                 |     ----------
                           |         |
                           V         V
---------------------------------------------
|                   LAN                     |
---------------------------------------------

I''m using netconsole to capture logs from  Host-A and send them to
Host-B.
Host-A and Host-B are separate hosts (running XEN) which are  connected to the 
same LAN.
src-ip is Host-A address.
dst-ip/mac is Host-B address.
> 
> I can see why the *bridge* device might need an ndo_poll_controller hook
> in this setup but I can''t see any reason why the netback device
would
> need one.
> 
Please note that without netback driver netconsole runs fine, i.e before trying 
to create VM which attached to the bridge.
> > > I assume it is the domU but if that''s the case I
don''t see why a
> > > netback rather than netfront patch would be required.
> > >
> > > Or is dom0 doing netconsole where the log receiver is a domU?
> >
> > Log received at dom0 as output of xm cr vm.cfg command.
> > netconsole is used on dom0 to monitor its log
> 
> Are you now saying that logging goes from domU to dom0? Which is it?
netback comes to play as soon as i''m attaching virtual interface to a
bridge
and since this bridge is under netconsole monitoring the function is 
triggered. Up to that point there is no issue getting logs in Host-B so i 
assume the problem is not with the bridge driver.
> 
> In this scenario there is really no reason I can see that netback would
> need an ndo_poll_controller hook -- that would be needed in the domU in
> the netfront driver.
> 
> Please can you explain the exact code path which results in this new
> hook being called.
> 
init_netconsole() in netconsole.c -> alloc_param_target() ->
netpoll_setup()
in netpoll.c -> __netpoll_setup() which check if ndo_poll_controller() 
operation is supported.
> BTW looking at the patch as it is any use of this hook should be wrapped
> in CONFIG_NET_POLL_CONTROLLER.
> 
> Ian.
>