Xen devel - Oct 2011 - Xen 4.1.2 PVHVM guest with Linux 3.1.0 network problem, empty MAC address (all zeroes)

Hello,

While testing Fedora 16 Xen PVHVM guests I noticed the following problem:

When starting F16 PVHVM guest I can see the vifX.0 and tapX.0 interfaces appear
on dom0,
but after the guest kernel (Linux 3.1.0) starts and loads PVHVM drivers the 
vif/tap interfaces disappear from dom0.. 
so the bridge in dom0 doesn''t have any vifs/taps connected to it
anymore.

Has anyone seen that behaviour? 

I bet that''s also the reason why eth0 inside the PVHVM guest 
has a MAC address with only zeroes in it: 00:00:00:00:00:00.

If I disable PVHVM with "xen_platform_pci=0" in the domain cfgfile
then network for the guest works OK using the qemu-dm emulated nic.

PVHVM guest cfgfile:

kernel = "hvmloader"
builder=''hvm''
device_model = ''qemu-dm''
name = "f16pvhvm"
memory = 1024
vcpus=1
pae=1
acpi=1
apic=1
vif = [ ''type=ioemu, mac=00:16:5f:03:01:15, bridge=virbr0,
model=e1000'' ]
disk = [ ''phy:/dev/vg_f16/f16pvhvm,hda,w'',
''file:/root/iso/Fedora-16-Final-RC2-x86_64-DVD.iso,hdc:cdrom,r''
]
boot=''cd''
xen_platform_pci=1
on_poweroff = ''destroy''
on_reboot   = ''restart''
on_crash    = ''restart''
sdl=0
vnc=1
vncpasswd=''''
stdvga=0
serial=''pty''
tsc_mode=0
usb=1
usbdevice=''tablet''
keymap=''fi''

Some output from inside the PVHVM guest:

# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:00:00:00:00:00
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

# ethtool eth0
Settings for eth0:
        Link detected: no

# ethtool -i eth0
driver: vif
version:
firmware-version:
bus-info: vif-0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: no

Full PVHVM guest kernel (Linux 3.1.0) dmesg attached to this email.
Some parts of the guest dmesg here:

$ egrep -i ''xen|vif'' xen-4.1.2-f16pvhvm-linux-3.1.0-dmesg.txt
[    0.000000] DMI: Xen HVM domU, BIOS 4.1.2 10/21/2011
[    0.000000] Hypervisor detected: Xen HVM
[    0.000000] Xen version 4.1.
[    0.000000] Xen Platform PCI: I/O protocol version 1
[    0.000000] Netfront and the Xen platform PCI driver have been compiled for
this kernel: unplug emulated NICs.
[    0.000000] Blkfront and the Xen platform PCI driver have been compiled for
this kernel: unplug emulated disks.
[    0.000000] ACPI: RSDP 00000000000ea020 00024 (v02    Xen)
[    0.000000] ACPI: XSDT 00000000fc0134b0 00034 (v01    Xen      HVM 00000000
HVML 00000000)
[    0.000000] ACPI: FACP 00000000fc0132d0 000F4 (v04    Xen      HVM 00000000
HVML 00000000)
[    0.000000] ACPI: DSDT 00000000fc003440 0FE05 (v02    Xen      HVM 00000000
INTL 20100528)
[    0.000000] ACPI: APIC 00000000fc0133d0 000D8 (v02    Xen      HVM 00000000
HVML 00000000)
[    0.000000] Booting paravirtualized kernel on Xen HVM
[    0.000000] Xen HVM callback vector for event delivery is enabled
[    0.167992] Xen: using vcpuop timer interface
[    0.167998] installing Xen timer for CPU 0
[    1.761867] xen/balloon: Initialising balloon driver.
[    1.763774] xen-balloon: Initialising balloon driver.
[    1.777781] Switching to clocksource xen
[    1.911620] xen: --> pirq=16 -> irq=8 (gsi=8)
[    1.911716] xen: --> pirq=17 -> irq=12 (gsi=12)
[    1.911786] xen: --> pirq=18 -> irq=1 (gsi=1)
[    1.911856] xen: --> pirq=19 -> irq=6 (gsi=6)
[    1.911934] xen: --> pirq=20 -> irq=4 (gsi=4)
[    1.912011] xen: --> pirq=21 -> irq=7 (gsi=7)
[    3.246196] xen: --> pirq=22 -> irq=28 (gsi=28)
[    3.246201] xen-platform-pci 0000:00:03.0: PCI INT A -> GSI 28 (level,
low) -> IRQ 28
[    3.451348] xen: --> pirq=23 -> irq=23 (gsi=23)
[    4.273081] XENBUS: Device with no driver: device/vfb/0
[    4.286483] XENBUS: Device with no driver: device/vbd/768
[    4.302078] XENBUS: Device with no driver: device/vbd/5632
[    4.316760] XENBUS: Device with no driver: device/vif/0
[    4.331416] XENBUS: Device with no driver: device/console/0
[    5.296770] vbd vbd-5632: 19 xenbus_dev_probe on device/vbd/5632
[    9.747194] Initialising Xen virtual ethernet driver.
[    9.754392] vif vif-0: 2 parsing device/vif/0/mac


dom0 kernel (Linux 3.1.0 aswell) messages:

[ 1759.102852] device tap4.0 entered promiscuous mode
[ 1759.102914] virbr0: topology change detected, propagating
[ 1759.102920] virbr0: port 2(tap4.0) entering forwarding state
[ 1759.102931] virbr0: port 2(tap4.0) entering forwarding state
[ 1759.271512] virbr0: port 2(tap4.0) entering forwarding state
[ 1759.282639] virbr0: topology change detected, propagating
[ 1759.282647] virbr0: port 2(tap4.0) entering forwarding state
[ 1759.282654] virbr0: port 2(tap4.0) entering forwarding state
[ 1759.298054] device vif4.0 entered promiscuous mode
[ 1759.301103] ADDRCONF(NETDEV_UP): vif4.0: link is not ready
[ 1769.895245] tap4.0: no IPv6 routers present


"xm log" doesn''t have any errors.
Any ideas how to fix this? Why do the vif/tap devices disappear from dom0?

Thanks,


-- Pasi



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

On Mon, Oct 31, 2011 at 10:13:36PM +0200, Pasi Kärkkäinen
wrote:
> Hello,
> 
> While testing Fedora 16 Xen PVHVM guests I noticed the following problem:
> 
> When starting F16 PVHVM guest I can see the vifX.0 and tapX.0 interfaces
appear on dom0,
> but after the guest kernel (Linux 3.1.0) starts and loads PVHVM drivers the
> vif/tap interfaces disappear from dom0.. 
> so the bridge in dom0 doesn''t have any vifs/taps connected to it
anymore.
> 
> Has anyone seen that behaviour? 
> 
> I bet that''s also the reason why eth0 inside the PVHVM guest 
> has a MAC address with only zeroes in it: 00:00:00:00:00:00.
> 
> If I disable PVHVM with "xen_platform_pci=0" in the domain
cfgfile
> then network for the guest works OK using the qemu-dm emulated nic.
> 
> PVHVM guest cfgfile:
> 
<snip>
> 
> Some output from inside the PVHVM guest:
> 
> # ifconfig eth0
> eth0      Link encap:Ethernet  HWaddr 00:00:00:00:00:00
>           BROADCAST MULTICAST  MTU:1500  Metric:1
>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:1000
>           RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
> 
<snip>
> 
> Full PVHVM guest kernel (Linux 3.1.0) dmesg attached to this email.
> Some parts of the guest dmesg here:
> 
> $ egrep -i ''xen|vif''
xen-4.1.2-f16pvhvm-linux-3.1.0-dmesg.txt
> 
<snip>
> 
> dom0 kernel (Linux 3.1.0 aswell) messages:
> 
<snip>
> 
> 
> "xm log" doesn''t have any errors.
> Any ideas how to fix this? Why do the vif/tap devices disappear from dom0?
> 
Well.. it was actually as simple as removing "type=ioemu" from the vif
line.
Working vif-example for Xen PVHVM Linux guest VM:

vif = [ ''mac=00:16:5f:03:01:15, bridge=virbr0, model=e1000'' ]

So uhm.. when enabling PVHVM there''s no need to modify the disk line, 
but you need to modify the vif-line.. is that like it should be ?


-- Pasi


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

On Mon, Oct 31, 2011 at 10:51:34PM +0200, Pasi Kärkkäinen
wrote:
> On Mon, Oct 31, 2011 at 10:13:36PM +0200, Pasi Kärkkäinen wrote:
> > Hello,
> > 
> > While testing Fedora 16 Xen PVHVM guests I noticed the following
problem:
> > 
> > When starting F16 PVHVM guest I can see the vifX.0 and tapX.0
interfaces appear on dom0,
> > but after the guest kernel (Linux 3.1.0) starts and loads PVHVM
drivers the
> > vif/tap interfaces disappear from dom0.. 
> > so the bridge in dom0 doesn''t have any vifs/taps connected to
it anymore.
> > 
> > Has anyone seen that behaviour? 
> > 
> > I bet that''s also the reason why eth0 inside the PVHVM guest 
> > has a MAC address with only zeroes in it: 00:00:00:00:00:00.
> > 
> > If I disable PVHVM with "xen_platform_pci=0" in the domain
cfgfile
> > then network for the guest works OK using the qemu-dm emulated nic.
> > 
> > PVHVM guest cfgfile:
> > 
> 
> <snip>
> 
> > 
> > Some output from inside the PVHVM guest:
> > 
> > # ifconfig eth0
> > eth0      Link encap:Ethernet  HWaddr 00:00:00:00:00:00
> >           BROADCAST MULTICAST  MTU:1500  Metric:1
> >           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> >           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
> >           collisions:0 txqueuelen:1000
> >           RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
> > 
> 
> <snip>
> 
> > 
> > Full PVHVM guest kernel (Linux 3.1.0) dmesg attached to this email.
> > Some parts of the guest dmesg here:
> > 
> > $ egrep -i ''xen|vif''
xen-4.1.2-f16pvhvm-linux-3.1.0-dmesg.txt
> > 
> 
> <snip>
> 
> > 
> > dom0 kernel (Linux 3.1.0 aswell) messages:
> > 
> 
> <snip>
> 
> > 
> > 
> > "xm log" doesn''t have any errors.
> > Any ideas how to fix this? Why do the vif/tap devices disappear from
dom0?
> > 
> 
> Well.. it was actually as simple as removing "type=ioemu" from
the vif line.
> Working vif-example for Xen PVHVM Linux guest VM:
> 
> vif = [ ''mac=00:16:5f:03:01:15, bridge=virbr0,
model=e1000'' ]
> 
> So uhm.. when enabling PVHVM there''s no need to modify the disk
line,
> but you need to modify the vif-line.. is that like it should be ?
> 
It seems "type=ioemu" is not required for anything.. 
not even for normal HVM emulated nics.

So this works for both normal HVM and PVHVM:
vif = [ ''mac=00:16:5f:03:01:15, bridge=virbr0, model=e1000'' ]

And control the HVM/PVHVM mode with:
	xen_platform_pci=1
or
	xen_platform_pci=0



-- Pasi


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