WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-users

Re: [Xen-users] OpenSuse 11 hvm domU: screen resolution up to 640x480

To: Flavio <fbcyborg@xxxxxxxxx>
Subject: Re: [Xen-users] OpenSuse 11 hvm domU: screen resolution up to 640x480
From: jim burns <jim_burn@xxxxxxxxxxxxx>
Date: Mon, 14 Nov 2011 18:16:02 -0500
Cc: xen-users@xxxxxxxxxxxxxxxxxxx, "Fajar A. Nugraha" <list@xxxxxxxxx>
Delivery-date: Mon, 14 Nov 2011 16:50:55 -0800
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bellsouth.net; s=s1024; t=1321312570; bh=VU/haefMOi7X7WW1dcnu3JCRK3utbJ+nWoGVX1MpV3o=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:From:To:Cc:Subject:Date:Message-ID:User-Agent:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Content-Type; b=OwPPgkMamSYpUYKD534ILKWxokEKcc1cpe0zGcMQX1XMn9btl5X0EpDg1qXGavpfZrGzZ2XD3dmS8ZVjiLauuSPoj8x6qbtALTLObtabzUbqgJgrGWD3vm+u95L2bU+FkRKU7xFdAhUpQ+Tv6R2R0WmLPczzHtMKi/ofB98pJUw=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4592072.7zkAKQjZAl@dell4550>
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
References: <7877809.94pu0BOf0I@dell4550> <CAP8Jb=r=zh=P990ELbveBbUk0ND3=5TP60BhAVVH6SMXEtiA7A@xxxxxxxxxxxxxx> <4592072.7zkAKQjZAl@dell4550>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/4.7.3 (Linux/2.6.37.6-0.9-default; KDE/4.7.3; i686; ; )
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