On Sun November 13 2011, 7:35:18 PM, jim burns wrote:
> Ok - As I said, so long as the 3.1 domu config has
> CONFIG_XEN_NETDEV_FRONTEND=y (builtin) the network should theoretically
> work. Particularly since your Gentoo dom0 is also 3.1. The fact that your
> 2.6.37 domu network works, and 2.6.37 is the old xenlinux style, as opposed
> to the newer 3.1 pvops style, shows that qemu-dm is capable of hiding the
> differences. The fact that /etc/sysconfig/kernel asks for the old xennet,
> xenblk names shouldn't matter with the newer xen-netfront as a builtin. And
> again, your eth0 got an ipv4 address from the network - I assume you get
> addresses from dhcp?
Oy - I just realized this morning that I'm going about your network problem
all wrong. While it's true that CONFIG_XEN_NETDEV_BACKEND=y in your Gentoo
dom0 was a good thing, that's because a dom0 is always a pv domain. However,
we don't really need to care about CONFIG_XEN_NETDEV_FRONTEND=y or =m in an
hvm domu, because that also only matters to a pv domu. Qemu-dm (by default)
provides an emulated Realtek 8139 network card, so we are looking for the
kernel drivers 8139cp and/or 8139too. (Not sure which or both - your 2.6.37
dmesg initializes both. Do a 'lsmod|grep 8139' and tell me which one(s) you
have.) This is just like we didn't care about CONFIG_XEN_FBDEV_FRONTEND,
because we are using cirrusfb, not xen-netfront.
According to your 2.6.37 dmesg, the the network card is initialized this way:
[ 0.209416] pci 0000:00:04.0: [10ec:8139] type 0 class 0x000200
[ 0.209789] pci 0000:00:04.0: reg 10: [io 0xc100-0xc1ff]
[ 0.210096] pci 0000:00:04.0: reg 14: [mem 0xf3001000-0xf30010ff]
[...]
[ 8.550920] 8139cp: 8139cp: 10/100 PCI Ethernet driver v1.3 (Mar 22, 2004)
[ 8.551133] 8139cp 0000:00:04.0: PCI INT A -> GSI 32 (level, low) -> IRQ 32
[ 8.568729] xen_mem: Initialising balloon driver.
[ 8.771269] 8139cp 0000:00:04.0: eth0: RTL-8139C+ at 0xffffc90000c40000,
00:16:3e:00:00:21, IRQ 32
[ 8.771366] 8139cp 0000:00:04.0: setting latency timer to 64
[ 8.858934] netfront: Initialising virtual ethernet driver.
[ 8.919407] xen-vbd: registered block device major 3
[ 8.919450] blkfront: hda: barriers enabled
[ 8.922799] hda: hda1 hda2
[ 8.931426] 8139too: 8139too Fast Ethernet driver 0.9.28
[...]
[ 43.310820] eth0: link up, 100Mbps, full-duplex, lpa 0x05E1
My guess is the driver attached to the pci device 00:04.0, 8139cp, handles the
device, and 8139too handles the protocol. This is similar to wireless devices
being serviced by multiple kernel modules.
Your 3.1 dmesg says virtually the same thing (except for netfront & blkfront):
[ 0.685919] pci 0000:00:04.0: [10ec:8139] type 0 class 0x000200
[ 0.688990] pci 0000:00:04.0: reg 10: [io 0xc100-0xc1ff]
[ 0.692039] pci 0000:00:04.0: reg 14: [mem 0xf3001000-0xf30010ff]
[...]
[ 9.458707] 8139cp: 8139cp: 10/100 PCI Ethernet driver v1.3 (Mar 22, 2004)
[ 9.458839] xen: --> pirq=23 -> irq=32 (gsi=32)
[ 9.458845] 8139cp 0000:00:04.0: PCI INT A -> GSI 32 (level, low) -> IRQ 32
[ 9.475499] 8139cp 0000:00:04.0: eth0: RTL-8139C+ at 0xffffc900004fc000,
00:16:3e:00:00:21, IRQ 32
[ 9.475653] 8139cp 0000:00:04.0: setting latency timer to 64
[...]
[ 9.613185] 8139too: 8139too Fast Ethernet driver 0.9.28
[...]
[ 24.322502] 8139cp 0000:00:04.0: eth0: link up, 100Mbps, full-duplex, lpa
0x05E1
In other words, as far as the domu is concerned, for both kernels, eth0 has
been initialized, and the link is up. So the problem is in the dom0 to domu
frontend, backend communication, or the bridge. Can't do anything more with
this configuration, short of using tcpdump to troubleshoot.
(Btw, both kernels report the same BAR errors with cirrusfb, and fail, leaving
(presumably) vesa in charge.)
There is a 2nd configuration possible, though. Qemu-dm also supports an Intel
1000 Mbps card, which Pasi K. prefers to use in linux hvm domus. The vif= line
has a model= suboption. Model=rtl8139, or no model= option, picks the Realtek
emulation, model=e1000 picks the Intel emulation. Of course, if you change
your hvm config, you change it for both kernels. You might want to configure
both interfaces, giving you an eth0 and an eth1:
vif = [ 'type=ioemu, mac=00:16:3e:00:00:21, bridge=xenbr0, model=rtl8139',
'type=ioemu, mac=00:16:3e:00:00:22, bridge=xenbr0, model=e1000' ]
Note each interface has a unique mac address. They are also both attached to
xenbr0. This shouldn't case network loops, but if it does, you can always ifup
one, and ifdown the other.
And then there is a third possibility. Your kernel with the network problems,
3.1, is fully capable of booting as a pv domu. You have already compiled all
the xen frontends as builtin. Domu support has been available in mainline
kernels for some time now.
Of course, changing from hvm to pv drivers will cause some configuration
problems in your file system image. I've already mentioned how your
/dev/disk/by-id soft links won't be valid anymore. Not sure whether you should
be using /dev/sda<n>, or /dev/xvda<n> in your menu.lst, since I use
root=UUID=, but you will definitely be using /dev/xvda<n> in your /etc/fstab,
at least until you see whether something stays constant, like /dev/disk/by-
uuid. Rather than changing your fstab every time you want to change from hvm
to pv, if you have enough disk space, you might want to clone (copy) your file
system image file, and use it for pv.
Your menu.lst stanza will look very similar to the one for your kernel-xen
install.
Your head reeling yet? :-)
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home