thr3ads.net - Xen devel - [Xen-devel] [patch] netfront: unregister net device at backend_changed() if network

If this information is useful, please help other people find it:
Share via:

Joe Jin

2008-Nov-18 06:01 UTC

[Xen-devel] [patch] netfront: unregister net device at backend_changed() if network_connect() failed

Subject: netfront: unregister net device at backend_changed() if
network_connect() failed
From: Joe Jin <joe.jin@oracle.com>

When network_connect() failed on backend_changed(), need to call 
unregister_netdev() to unregister the device, otherwise at vm maybe create
a no-mac address net device, the device sometime might confuse user.

Signed-off-by: Joe Jin <joe.jin@oracle.com>
---
 netfront.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff -r 2fb13b8cbe13 drivers/xen/netfront/netfront.c
--- a/drivers/xen/netfront/netfront.c	Thu Oct 30 13:34:43 2008 +0000
+++ b/drivers/xen/netfront/netfront.c	Tue Nov 18 13:52:34 2008 +0800
@@ -549,8 +549,10 @@
 	case XenbusStateInitWait:
 		if (dev->state != XenbusStateInitialising)
 			break;
-		if (network_connect(netdev) != 0)
+		if (network_connect(netdev) != 0) {
+			unregister_netdev(netdev);
 			break;
+		}
 		xenbus_switch_state(dev, XenbusStateConnected);
 		send_fake_arp(netdev);
 		break;




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

Keir Fraser

2008-Nov-18 10:47 UTC

head link

[Xen-devel] Re: [patch] netfront: unregister net device at backend_changed() if network_connect() failed

On 18/11/08 06:01, "Joe Jin" <joe.jin@oracle.com> wrote:
> Subject: netfront: unregister net device at backend_changed() if
> network_connect() failed
> From: Joe Jin <joe.jin@oracle.com>
> 
> When network_connect() failed on backend_changed(), need to call
> unregister_netdev() to unregister the device, otherwise at vm maybe create
> a no-mac address net device, the device sometime might confuse user.
If virtual devices are failing to initialise then a confusing no-mac
interface is presumably the least of the user''s worries?

 -- Keir



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

Joe Jin

2008-Nov-18 12:21 UTC

head link

[Xen-devel] Re: [patch] netfront: unregister net device at backend_changed() if network_connect() failed

> If virtual devices are failing to initialise then a confusing no-mac
> interface is presumably the least of the user''s worries?
However, initialized failed means device was unavailable, but 
at system ifconfig -a also show it, might be user ask what is
it? why it disabled? is there anything wrong on my systgem :-)
So, I think if device failed to initialise we''d better unregister
it. how do you think?

thanks,
Joe

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

Keir Fraser

2008-Nov-18 12:49 UTC

head link

[Xen-devel] Re: [patch] netfront: unregister net device at backend_changed() if network_connect() failed

On 18/11/08 12:21, "Joe Jin" <joe.jin@oracle.com> wrote:
>> If virtual devices are failing to initialise then a confusing no-mac
>> interface is presumably the least of the user''s worries?
> 
> However, initialized failed means device was unavailable, but
> at system ifconfig -a also show it, might be user ask what is
> it? why it disabled? is there anything wrong on my systgem :-)
And they''d be right wouldn''t they: Yes, something *is* wrong!
:-)
> So, I think if device failed to initialise we''d better unregister
> it. how do you think?
Have you actually seen this problem occur, in stress tests or elsewhere? Or
is this just a ''nice to have''? If the former I''d
rather fix the bug!

One concern I have is that leaving an interface structure allocated but
unregistered is not a state we''ve previously handled in netfront, and
could
cause bad kernel behaviour if, for example, the netif gets unprobed later.

 -- Keir




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

Joe Jin

2008-Nov-19 02:13 UTC

head link

Re: [Xen-devel] Re: [patch] netfront: unregister net device at backend_changed() if network_connect() failed

On 2008-11-18 12:49, Keir Fraser wrote:> On 18/11/08 12:21, "Joe Jin" <joe.jin@oracle.com> wrote:
> 
> >> If virtual devices are failing to initialise then a confusing
no-mac
> >> interface is presumably the least of the user''s worries?
> > 
> > However, initialized failed means device was unavailable, but
> > at system ifconfig -a also show it, might be user ask what is
> > it? why it disabled? is there anything wrong on my systgem :-)
> 
> And they''d be right wouldn''t they: Yes, something *is*
wrong! :-)
> 
> > So, I think if device failed to initialise we''d better
unregister
> > it. how do you think?
> 
> Have you actually seen this problem occur, in stress tests or elsewhere? Or
> is this just a ''nice to have''? If the former I''d
rather fix the bug!
> 
At vm config file set vif type to ioemu and booting guest with pv driver,
always saw the interface, unregister the device when network_connect(),
I just saw one nic with 8139 driver.

> One concern I have is that leaving an interface structure allocated but
> unregistered is not a state we''ve previously handled in netfront,
and could
> cause bad kernel behaviour if, for example, the netif gets unprobed later.
> 
I think if device initilise failed, we''d better release all resources
like
former''s netif_free(): http://xen.markmail.org/message/2bp3xgsqzdofwoy6
from patch description the patch tried to *"eliminates earlier workaround
patch
for an observed crash."* 
In fact the crashed caused by not unregister the device made the
interface''s
state is NETREG_REGISTERED, when network_connect() failed, call free_netdev()
would trigered BUG_ON, just add unregister_netdev() would solved the issue.


Thanks,
Joe




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

Keir Fraser

2008-Nov-19 08:54 UTC

head link

Re: [Xen-devel] Re: [patch] netfront: unregister net device at backend_changed() if network_connect() failed

On 19/11/08 02:13, "Joe Jin" <joe.jin@oracle.com> wrote:
>> Have you actually seen this problem occur, in stress tests or
elsewhere? Or
>> is this just a ''nice to have''? If the former
I''d rather fix the bug!
>> 
> 
> At vm config file set vif type to ioemu and booting guest with pv driver,
> always saw the interface, unregister the device when network_connect(),
> I just saw one nic with 8139 driver.
I think failure to connect in frontend should always be a bug condition.

In this case, xend shouldn''t be creating front and back directories at
all.
What happens if you make netif''s getDeviceDetails() return None for
devid if
type == ''ioemu''? This should cause DevController.py not to set
up the
front/back details and netfront.c will never get triggered.

Just need to make sure ioemu''s netdevice still works. Including across
save/restore. :-)

 -- Keir

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

Keir Fraser

2008-Nov-19 08:56 UTC

head link

Re: [Xen-devel] Re: [patch] netfront: unregister net device at backend_changed() if network_connect() failed

On 19/11/08 02:13, "Joe Jin" <joe.jin@oracle.com> wrote:
>> One concern I have is that leaving an interface structure allocated but
>> unregistered is not a state we''ve previously handled in
netfront, and could
>> cause bad kernel behaviour if, for example, the netif gets unprobed
later.
>> 
> 
> I think if device initilise failed, we''d better release all
resources like
> former''s netif_free():
http://xen.markmail.org/message/2bp3xgsqzdofwoy6
> from patch description the patch tried to *"eliminates earlier
workaround
> patch
> for an observed crash."*
> In fact the crashed caused by not unregister the device made the
interface''s
> state is NETREG_REGISTERED, when network_connect() failed, call
free_netdev()
> would trigered BUG_ON, just add unregister_netdev() would solved the issue.
My point is, if you unregister_netdev() on failed network_connect(), and
then do it unconditionally again in netfront_remove(), you will BUG_ON() in
unregister_netdevice().

 -- Keir



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

Joe Jin

2008-Nov-19 12:47 UTC

head link

Re: [Xen-devel] Re: [patch] netfront: unregister net device at backend_changed() if network_connect() failed

> My point is, if you unregister_netdev() on failed network_connect(), and
> then do it unconditionally again in netfront_remove(), you will BUG_ON() in
> unregister_netdevice().
Sorry I dont notice that
Could we add a test in netfront_remove like below?
static int __devexit netfront_remove(struct xenbus_device *dev)
{
<--snip-->
      if (info->netdev->reg_state == NETREG_REGISTERED)
           unregister_netdev(info->netdev);
<--snip-->
}

This will avoid the crash when call netfront_remove.

Thanks,
Joe


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

Joe Jin

2008-Nov-19 12:52 UTC

head link

Re: [Xen-devel] Re: [patch] netfront: unregister net device at backend_changed() if network_connect() failed

> In this case, xend shouldn''t be creating front and back
directories at all.
Agree, not sure why just set vif type to ioemu would create xen vnif device.
> What happens if you make netif''s getDeviceDetails() return None
for devid if
> type == ''ioemu''? This should cause DevController.py not
to set up the
> front/back details and netfront.c will never get triggered.
> Just need to make sure ioemu''s netdevice still works. Including
across
> save/restore. :-)
Will try it later. thanks for you suggestion.

Regards,
Joe

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

Joe Jin

2008-Nov-20 02:53 UTC

head link

Re: [Xen-devel] Re: [patch] netfront: unregister net device at backend_changed() if network_connect() failed

On 2008-11-19 08:54, Keir Fraser wrote:> On 19/11/08 02:13, "Joe Jin" <joe.jin@oracle.com> wrote:
> 
> >> Have you actually seen this problem occur, in stress tests or
elsewhere? Or
> >> is this just a ''nice to have''? If the former
I''d rather fix the bug!
> >> 
> > 
> > At vm config file set vif type to ioemu and booting guest with pv
driver,
> > always saw the interface, unregister the device when
network_connect(),
> > I just saw one nic with 8139 driver.
> 
> I think failure to connect in frontend should always be a bug condition.
> 
> In this case, xend shouldn''t be creating front and back
directories at all.
> What happens if you make netif''s getDeviceDetails() return None
for devid if
> type == ''ioemu''? This should cause DevController.py not
to set up the
> front/back details and netfront.c will never get triggered.
> 
The change could not stoped kernel insert xen_vnif driver.
From xend.log I did not saw xend have tried to create vnif device at all,
I''m not sure whether virtual device platform "Xen Platform
Device" have
preallocated the interface, then kernel try to load the driver?

Below are some xend logs:

[2008-11-20 10:43:01 16111] DEBUG (XendDomainInfo:85)
XendDomainInfo.create([''vm'', [''name'',
''hvm''], [''memory'',
''1024''], [''on_reboot'',
''restart''], [''on_crash'',
''preserve''], [''vcpus'', 1],
[''on_xend_start'', ''ignore''],
[''on_xend_stop'', ''ignore''],
[''image'', [''hvm'',
[''kernel'', ''/usr/lib/xen/boot/hvmloader''],
[''device_model'',
''/usr/lib/xen/bin/qemu-dm''], [''pae'', 1],
[''vcpus'', 1], [''boot'',
''c''], [''fda'', ''''],
[''fdb'', ''''],
[''timer_mode'', 0], [''localtime'', 0],
[''serial'', ''pty''],
[''stdvga'', 0], [''isa'', 0],
[''nographic'', 0], [''soundhw'',
''''], [''vnc'', 1],
[''vncunused'', 1], [''vncconsole'', 1],
[''vnclisten'', ''00.0.0''],
[''display'', ''localhost:11.0''],
[''xauthority'', ''/root/.Xauthority''],
[''rtc_timeoffset'', ''0''],
[''monitor'', 0], [''acpi'', 1],
[''apic'', 1], [''usb'', 0],
[''usbdevice'', ''''],
[''keymap'', ''''], [''hpet'',
0]]], [''device'', [''vbd'',
[''uname'',
''file:/root/OVM_EL5U1_X86_HVM_4GB/system.img''],
[''dev'', ''hda''], [''mode'',
''w'']]], [''device'', [''vif'',
[''bridge'', ''xenbr0''],
[''mac'', ''00:16:3E:40:F6:58''],
[''type'', ''ioemu'']]]])
[2008-11-20 10:43:01 16111] DEBUG (XendDomainInfo:1534)
XendDomainInfo.constructDomain
[2008-11-20 10:43:01 16111] DEBUG (balloon:116) Balloon: 1487380 KiB free; need
2048; done.
[2008-11-20 10:43:01 16111] DEBUG (XendDomain:434) Adding Domain: 50
[2008-11-20 10:43:01 16111] DEBUG (XendDomainInfo:1600)
XendDomainInfo.initDomain: 50 256
[2008-11-20 10:43:01 16111] DEBUG (image:337) args: boot, val: c
[2008-11-20 10:43:02 16111] DEBUG (image:337) args: fda, val: None
[2008-11-20 10:43:02 16111] DEBUG (image:337) args: fdb, val: None
[2008-11-20 10:43:02 16111] DEBUG (image:337) args: soundhw, val: None
[2008-11-20 10:43:02 16111] DEBUG (image:337) args: localtime, val: 0
[2008-11-20 10:43:02 16111] DEBUG (image:337) args: serial, val: pty
[2008-11-20 10:43:02 16111] DEBUG (image:337) args: std-vga, val: 0
[2008-11-20 10:43:02 16111] DEBUG (image:337) args: isa, val: 0
[2008-11-20 10:43:02 16111] DEBUG (image:337) args: acpi, val: 1
[2008-11-20 10:43:02 16111] DEBUG (image:337) args: usb, val: 0
[2008-11-20 10:43:02 16111] DEBUG (image:337) args: usbdevice, val: None
[2008-11-20 10:43:02 16111] DEBUG (image:337) args: k, val: None
[2008-11-20 10:43:02 16111] DEBUG (XendDomainInfo:1634)
_initDomain:shadow_memory=0x0, memory_static_max=0x40000000,
memory_static_min=0x0.
[2008-11-20 10:43:02 16111] DEBUG (balloon:116) Balloon: 1486344 KiB free; need
1065984; done.
[2008-11-20 10:43:02 16111] INFO (image:128) buildDomain os=hvm dom=50 vcpus=1
[2008-11-20 10:43:02 16111] DEBUG (image:281) domid          = 50
[2008-11-20 10:43:02 16111] DEBUG (image:282) image          =
/usr/lib/xen/boot/hvmloader
[2008-11-20 10:43:02 16111] DEBUG (image:283) store_evtchn   = 2
[2008-11-20 10:43:02 16111] DEBUG (image:284) memsize        = 1024
[2008-11-20 10:43:02 16111] DEBUG (image:285) vcpus          = 1
[2008-11-20 10:43:02 16111] DEBUG (image:286) acpi           = 1
[2008-11-20 10:43:02 16111] DEBUG (image:287) apic           = 1
[2008-11-20 10:43:02 16111] INFO (XendDomainInfo:1433) createDevice: vfb :
{''vncunused'': 1, ''vnclisten'':
''0.0.0.0'', ''uuid'':
''ae2833f3-19eb-8db8-edbf-2c7a4c654ffa'',
''other_config'': {''vncunused'': 1,
''vnclisten'': ''0.0.0.0''}}
[2008-11-20 10:43:02 16111] DEBUG (DevController:118) DevController: writing
{''state'': ''1'',
''backend-id'': ''0'',
''backend'':
''/local/domain/0/backend/vfb/50/0''} to
/local/domain/50/device/vfb/0.
[2008-11-20 10:43:02 16111] DEBUG (DevController:120) DevController: writing
{''vncunused'': ''1'',
''domain'': ''hvm'',
''frontend'': ''/local/domain/50/device/vfb/0'',
''uuid'':
''ae2833f3-19eb-8db8-edbf-2c7a4c654ffa'',
''vnclisten'': ''0.0.00'',
''state'': ''1'', ''online'':
''1'', ''frontend-id'': ''50''}
to /local/domain/0/backend/vfb/50/0.
[2008-11-20 10:43:02 16111] INFO (XendDomainInfo:1433) createDevice: vbd :
{''uuid'':
''4c32c5b6-def4-d808-46fd-259083eaa2e0'',
''bootable'': 1, ''driver'':
''paravirtualised'', ''dev'':
''hda'', ''uname'':
''file:/root/OVM_EL5U1_X86_HVM_4GB/system.img'',
''mode'': ''w''}
[2008-11-20 10:43:02 16111] DEBUG (DevController:118) DevController: writing
{''backend-id'': ''0'',
''virtual-device'': ''768'',
''device-type'': ''disk'',
''state'': ''1'', ''backend'':
''/local/domain/0/backend/vbd/50/768''} to
/local/domain/50/device/vbd/768.
[2008-11-20 10:43:02 16111] DEBUG (DevController:120) DevController: writing
{''domain'': ''hvm'',
''frontend'':
''/local/domain/50/device/vbd/768'', ''uuid'':
''4c32c5b6-def4-d808-46fd-259083eaa2e0'',
''format'': ''raw'', ''dev'':
''hda'', ''state'': ''1'',
''params'':
''/root/OVM_EL5U1_X86_HVM_4GB/system.img'',
''mode'': ''w'', ''online'':
''1'', ''frontend-id'': ''50'',
''type'': ''file''} to
/local/domain/0/backend/vbd/50/768.
[2008-11-20 10:43:02 16111] INFO (XendDomainInfo:1433) createDevice: vif :
{''bridge'': ''xenbr0'',
''mac'': ''00:16:3E:40:F6:58'',
''type'': ''ioemu'', ''uuid'':
''33f63ceb-c077-d4f8-8f56-d4ffb9395436''}
[2008-11-20 10:43:02 16111] DEBUG (DevController:118) DevController: writing
{''state'': ''1'',
''backend-id'': ''0'',
''backend'':
''/local/domain/0/backend/vif/50/0''} to
/local/domain/50/device/vif/0.
[2008-11-20 10:43:02 16111] DEBUG (DevController:120) DevController: writing
{''bridge'': ''xenbr0'',
''domain'': ''hvm'', ''handle'':
''0'', ''uuid'':
''33f63ceb-c077-d4f8-8f56-d4ffb9395436'',
''script'': ''/etc/xen/scripts/vif-bridge'',
''mac'': ''00:16:3E:40:F6:58'',
''frontend-id'': ''50'',
''state'': ''1'', ''online'':
''1'', ''frontend'':
''/local/domain/50/device/vif/0'', ''type'':
''ioemu''} to /local/domain/0/backend/vif/50/0.
[2008-11-20 10:43:02 16111] INFO (image:453) spawning device models:
/usr/lib/xen/bin/qemu-dm [''/usr/lib/xen/bin/qemu-dm'',
''-d'', ''50'', ''-vcpus'',
''1'', ''-boot'', ''c'',
''-serial'', ''pty'', ''-acpi'',
''-domain-name'', ''hvm'',
''-net'',
''nic,vlan=1,macaddr=00:16:3E:40:F6:58,model=rtl8139'',
''-net'',
''tap,vlan=1,ifname=tap50.0,bridge=xenbr0'',
''-vncunused'', ''-vnclisten'',
''0.0.0.0'', ''-vncviewer'']
[2008-11-20 10:43:02 16111] INFO (image:457) device model pid: 17913
[2008-11-20 10:43:02 16111] DEBUG (XendDomainInfo:2119) Storing VM details:
{''on_xend_stop'': ''ignore'',
''shadow_memory'': ''9'',
''uuid'':
''0cb51839-52ae-d4aa-8216-9bf0a1565801'',
''on_reboot'': ''restart'',
''start_time'': ''1227148982.39'',
''on_poweroff'': ''destroy'',
''on_xend_start'': ''ignore'',
''on_crash'': ''preserve'',
''xend/restart_count'': ''0'',
''vcpus'': ''1'',
''vcpu_avail'': ''1'',
''image'': ''(hvm (kernel /usr/lib/xen/boot/hvmloader)
(acpi 1) (apic 1) (boot c) (device_model /usr/lib/xen/bin/qemu-dm) (display
localhost:11.0) (isa 0) (localtime 0) (monitor 0) (nographic 0) (pae 1)
(rtc_timeoffset 0) (serial pty) (stdvga 0) (usb 0) (hpet 0) (vnc 1) (vncconsole
1) (vnclisten 0.0.0.0) (timer_mode 0) (vncunused 1) (xauthority
/root/.Xauthority) (notes (SUSPEND_CANCEL 1)))'',
''name'': ''hvm''}
[2008-11-20 10:43:02 16111] DEBUG (XendDomainInfo:923) Storing domain details:
{''console/port'': ''3'',
''name'': ''hvm'',
''console/limit'': ''1048576'',
''vm'':
''/vm/0cb51839-52ae-d4aa-8216-9bf0a1565801'',
''domid'': ''50'',
''image/suspend-cancel'': ''1'',
''cpu/0/availability'': ''online'',
''memory/target'': ''1048576'',
''control/platform-feature-multiprocessor-suspend'':
''1'', ''store/ring-ref'':
''262142'', ''store/port'':
''2''}
[2008-11-20 10:43:02 16111] DEBUG (DevController:118) DevController: writing
{''state'': ''1'',
''backend-id'': ''0'',
''backend'':
''/local/domain/0/backend/console/50/0''} to
/local/domain/50/device/console/0.
[2008-11-20 10:43:02 16111] DEBUG (DevController:120) DevController: writing
{''domain'': ''hvm'',
''frontend'':
''/local/domain/50/device/console/0'', ''uuid'':
''b5cbb9a8-20ea-3123-4146-664c8cde5b54'',
''frontend-id'': ''50'',
''state'': ''1'', ''location'':
''3'', ''online'': ''1'',
''protocol'': ''vt100''} to
/local/domain/0/backend/console/50/0.
[2008-11-20 10:43:02 16111] DEBUG (XendDomainInfo:1007)
XendDomainInfo.handleShutdownWatch
[2008-11-20 10:43:02 16111] DEBUG (DevController:151) Waiting for devices vif.
[2008-11-20 10:43:02 16111] DEBUG (DevController:156) Waiting for 0.
[2008-11-20 10:43:02 16111] DEBUG (DevController:590) hotplugStatusCallback
/local/domain/0/backend/vif/50/0/hotplug-status.
[2008-11-20 10:43:02 16111] DEBUG (DevController:590) hotplugStatusCallback
/local/domain/0/backend/vif/50/0/hotplug-status.
[2008-11-20 10:43:02 16111] DEBUG (DevController:604) hotplugStatusCallback 1.
[2008-11-20 10:43:02 16111] DEBUG (DevController:151) Waiting for devices usb.
[2008-11-20 10:43:02 16111] DEBUG (DevController:151) Waiting for devices vbd.
[2008-11-20 10:43:02 16111] DEBUG (DevController:156) Waiting for 768.
[2008-11-20 10:43:02 16111] DEBUG (DevController:590) hotplugStatusCallback
/local/domain/0/backend/vbd/50/768/hotplug-status.
[2008-11-20 10:43:03 16111] DEBUG (DevController:590) hotplugStatusCallback
/local/domain/0/backend/vbd/50/768/hotplug-status.
[2008-11-20 10:43:03 16111] DEBUG (DevController:604) hotplugStatusCallback 1.
[2008-11-20 10:43:03 16111] DEBUG (DevController:151) Waiting for devices irq.
[2008-11-20 10:43:03 16111] DEBUG (DevController:151) Waiting for devices vkbd.
[2008-11-20 10:43:03 16111] DEBUG (DevController:151) Waiting for devices vfb.
[2008-11-20 10:43:03 16111] DEBUG (vfbif:109) skip waiting for HVM vfb
[2008-11-20 10:43:03 16111] DEBUG (DevController:151) Waiting for devices
console.
[2008-11-20 10:43:03 16111] DEBUG (DevController:156) Waiting for 0.
[2008-11-20 10:43:03 16111] DEBUG (DevController:151) Waiting for devices pci.
[2008-11-20 10:43:03 16111] DEBUG (DevController:151) Waiting for devices
ioports.
[2008-11-20 10:43:03 16111] DEBUG (DevController:151) Waiting for devices tap.
[2008-11-20 10:43:03 16111] DEBUG (DevController:151) Waiting for devices vtpm.
[2008-11-20 10:43:03 16111] INFO (XendDomain:1121) Domain hvm (50) unpaused.






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

Keir Fraser

2008-Nov-20 08:05 UTC

head link

Re: [Xen-devel] Re: [patch] netfront: unregister net device at backend_changed() if network_connect() failed

On 20/11/08 02:53, "Joe Jin" <joe.jin@oracle.com> wrote:
>> In this case, xend shouldn''t be creating front and back
directories at all.
>> What happens if you make netif''s getDeviceDetails() return
None for devid if
>> type == ''ioemu''? This should cause DevController.py
not to set up the
>> front/back details and netfront.c will never get triggered.
>> 
> 
> The change could not stoped kernel insert xen_vnif driver.
> From xend.log I did not saw xend have tried to create vnif device at all,
> I''m not sure whether virtual device platform "Xen Platform
Device" have
> preallocated the interface, then kernel try to load the driver?
If you really return None for devid from getDeviceDetails then it should be
impossible to get further in DevController.py:createDevice(). If you take a
look at the implementation it immediately returns in that case. So something
odd is going on. Perhaps your new patch does not work.

 -- Keir



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

Xen devel - Nov 2008 - [patch] netfront: unregister net device at backend_changed() if network_connect() failed

[Xen-devel] [patch] netfront: unregister net device at backend_changed() if network_connect() failed

[Xen-devel] Re: [patch] netfront: unregister net device at backend_changed() if network_connect() failed

[Xen-devel] Re: [patch] netfront: unregister net device at backend_changed() if network_connect() failed

[Xen-devel] Re: [patch] netfront: unregister net device at backend_changed() if network_connect() failed

Re: [Xen-devel] Re: [patch] netfront: unregister net device at backend_changed() if network_connect() failed

Re: [Xen-devel] Re: [patch] netfront: unregister net device at backend_changed() if network_connect() failed

Re: [Xen-devel] Re: [patch] netfront: unregister net device at backend_changed() if network_connect() failed

Re: [Xen-devel] Re: [patch] netfront: unregister net device at backend_changed() if network_connect() failed

Re: [Xen-devel] Re: [patch] netfront: unregister net device at backend_changed() if network_connect() failed

Re: [Xen-devel] Re: [patch] netfront: unregister net device at backend_changed() if network_connect() failed

Re: [Xen-devel] Re: [patch] netfront: unregister net device at backend_changed() if network_connect() failed