2.6.38-rc dom0 kernel

[M A Young]

I have a new dom0 kernel available for testing 
(2.6.38-0.rc2.git3.1.xendom0.fc15) at 
http://koji.fedoraproject.org/koji/taskinfo?taskID=2742521
This is based on the xen/next-2.6.38 branch with a few extra memory fixes, 
including one which fixes a problem I had causing a crash during boot. 
xen/next-2.6.38 adds net and pci backends.

 	Michael Young

2.6.38-rc dom0 kernel and xen 4.1.0-rc2

[M A Young]

On Wed, 26 Jan 2011, M A Young wrote:

>  I have a new dom0 kernel available for testing 
>  (2.6.38-0.rc2.git3.1.xendom0.fc15) at 
>  http://koji.fedoraproject.org/koji/taskinfo?taskID=2742521 
>  ... with a few extra memory fixes, 
>  including one which fixes a problem I had causing a crash during boot.  
Actually it
didn't, but (2.6.38-0.rc2.git3.2.xendom0.fc15) does at 
http://koji.fedoraproject.org/koji/taskinfo?taskID=2744376

I also now have a build of xen-4.1.0-rc2 at 
http://koji.fedoraproject.org/koji/taskinfo?taskID=2744030

 	Michael Young

2.6.38-rc dom0 kernel and xen 4.1.0-rc2

[Marko Ristola]

27.01.2011 00:50, M A Young wrote:
>  On Wed, 26 Jan 2011, M A Young wrote:
>
> > I have a new dom0 kernel available for testing
> > (2.6.38-0.rc2.git3.1.xendom0.fc15) at
> > http://koji.fedoraproject.org/koji/taskinfo?taskID=2742521
>
> > ... with a few extra memory fixes,
> > including one which fixes a problem I had causing a crash during boot.
>  Actually it didn't, but (2.6.38-0.rc2.git3.2.xendom0.fc15) does at
>  http://koji.fedoraproject.org/koji/taskinfo?taskID=2744376 
Great work :)

I tested with2.6.38-0.rc2.git3.2.xendom0.fc15.x86_64.

Fonts and OpenGL textures work with Radeon card.  Games too.
Dom0 is now usable as a desktop computer.

I tested with Dom0 memory sizes 1GB and 3GB.
I have software IO TLB in use under Dom0.

Regards,
Marko Ristola

2.6.38-rc dom0 kernel and xen 4.1.0-rc2

[W. Michael Petullo]

>  Actually it didn't, but (2.6.38-0.rc2.git3.2.xendom0.fc15) does
> at 
>  http://koji.fedoraproject.org/koji/taskinfo?taskID=2744376
>  
>  I also now have a build of xen-4.1.0-rc2 at 
>  http://koji.fedoraproject.org/koji/taskinfo?taskID=2744030 
I am presently testing these Xen and kernel packages. My initial
impression is very positive. I am able to boot into X within Dom0 on my
previously difficult hardware. Previous experiences are documented on
this list, beginning with [1]. My WiFi adapter also works. So, I
agree with Marko's statement so far, "Dom0 is now usable as a desktop
computer." I will continue to use this as my primary environment and
will report any issues I come across.

Now, the last issue remaining for me is the backend drivers. My
understanding is that, in the absence of backends being accepted
upstream, we can use QEMU-based drivers. This would be acceptable for
our work. Has anyone been using these with Fedora 15?

[1] http://lists.fedoraproject.org/pipermail/xen/2010-March/005014.html

-- 
Mike

:wq

2.6.38-rc dom0 kernel and xen 4.1.0-rc2

[Jerry Amundson]

On Thu, Jan 27, 2011 at 11:51 AM, W. Michael Petullo <mike(a)flyn.org&gt; wrote:
> > Actually it didn't, but (2.6.38-0.rc2.git3.2.xendom0.fc15)
> does at
> > http://koji.fedoraproject.org/koji/taskinfo?taskID=2744376
> >
> > I also now have a build of xen-4.1.0-rc2 at
> > http://koji.fedoraproject.org/koji/taskinfo?taskID=2744030
>
>  I am presently testing these Xen and kernel packages. My initial
>  impression is very positive. I am able to boot into X within Dom0 on my
>  previously difficult hardware. Previous experiences are documented on
>  this list, beginning with [1]. My WiFi adapter also works. So, I
>  agree with Marko's statement so far, "Dom0 is now usable as a desktop
>  computer." I will continue to use this as my primary environment and
>  will report any issues I come across. 
Me too. My "Failsafe KDE" is stable over an hour now!!
Video:
01:00.0 VGA compatible controller: ATI Technologies Inc RV610 [Radeon
HD 2400 XT]
Smolt::
http://www.smolts.org/client/show/pub_10d63815-f25a-45cc-a80a-d16d3f5f4af0

However, my "standard" KDE desktop hangs X after a few minutes. Should
I report to bz.r.c? I can easily reproduce this...

thanks,
jerry

[  1336.505] [mi] EQ overflowing. The server is probably stuck in an
infinite loop.
[  1336.506]
Backtrace:
[  1336.507] 0: /usr/bin/X (xorg_backtrace+0x28) [0x4a0488]
[  1336.507] 1: /usr/bin/X (mieqEnqueue+0x1f4) [0x49f994]
[  1336.507] 2: /usr/bin/X (xf86PostMotionEventP+0xc4) [0x47c744]
[  1336.507] 3: /usr/lib64/xorg/modules/input/evdev_drv.so
(0x7ff026da1000+0x453f) [0x7ff026da553f]
[  1336.507] 4: /usr/bin/X (0x400000+0x6a447) [0x46a447]
[  1336.507] 5: /usr/bin/X (0x400000+0x118c43) [0x518c43]
[  1336.507] 6: /lib64/libc.so.6 (0x3a96200000+0x34100) [0x3a96234100]
[  1336.507] 7: /lib64/libc.so.6 (0x3a96200000+0x136400) [0x3a96336400]
[  1336.507] 8: /usr/lib64/xorg/modules/libfb.so (fbBlt+0xf8) [0x7ff027bd0118]
[  1336.507] 9: /usr/lib64/xorg/modules/libfb.so (fbBltStip+0x40)
[0x7ff027bd0ec0]
[  1336.507] 10: /usr/lib64/xorg/modules/libfb.so (fbGetImage+0x206)
[0x7ff027bd6616]
[  1336.507] 11: /usr/lib64/xorg/modules/libexa.so
(0x7ff0279a8000+0x13988) [0x7ff0279bb988]
[  1336.507] 12: /usr/lib64/xorg/modules/libexa.so
(0x7ff0279a8000+0xbef8) [0x7ff0279b3ef8]
[  1336.507] 13: /usr/bin/X (0x400000+0x1560d8) [0x5560d8]
[  1336.507] 14: /usr/lib64/xorg/modules/libexa.so
(exaGetPixmapFirstPixel+0xa9) [0x7ff0279bc839]
[  1336.507] 15: /usr/lib64/xorg/modules/libexa.so
(0x7ff0279a8000+0x10731) [0x7ff0279b8731]
[  1336.507] 16: /usr/bin/X (0x400000+0xd6503) [0x4d6503]
[  1336.507] 17: /usr/bin/X (0x400000+0xcf219) [0x4cf219]
[  1336.507] 18: /usr/bin/X (0x400000+0x2d4d1) [0x42d4d1]
[  1336.507] 19: /usr/bin/X (0x400000+0x2152e) [0x42152e]
[  1336.507] 20: /lib64/libc.so.6 (__libc_start_main+0xfd) [0x3a9621ee7d]
[  1336.507] 21: /usr/bin/X (0x400000+0x210d9) [0x4210d9]

2.6.38-rc dom0 kernel and xen 4.1.0-rc2

[M A Young]

On Thu, 27 Jan 2011, W. Michael Petullo wrote:

>  Now, the last issue remaining for me is the backend drivers. My
>  understanding is that, in the absence of backends being accepted
>  upstream, we can use QEMU-based drivers. This would be acceptable for
>  our work. Has anyone been using these with Fedora 15? 
In theory the block driver should work in 4.1.0, though I am not sure 
about the net driver. In practise I have failed so far to get the block 
driver working so far. This post today
http://lists.xensource.com/archives/html/xen-devel/2011-01/msg01847.html
talks about what block driver configurations should work.

 	Michael Young

2.6.38-rc dom0 kernel and xen 4.1.0-rc2

[W. Michael Petullo]

> > Now, the last issue remaining for me is the backend drivers. My
> > understanding is that, in the absence of backends being accepted
> > upstream, we can use QEMU-based drivers. This would be acceptable for
> > our work. Has anyone been using these with Fedora 15? 
 
>  In theory the block driver should work in 4.1.0, though I am not
>  sure about the net driver. In practise I have failed so far to get
>  the block driver working so far. This post today
>  http://lists.xensource.com/archives/html/xen-devel/2011-01/msg01847.html
>  talks about what block driver configurations should work. 
I have written the following domain config (to try to force the QEMU
block backend):

kernel   =   '/tmp/openwrt-x86-xen_domu-vmlinuz'
memory   =    32
# NOTE: Generated with qemu-img convert -f raw -O qcow2 input.img output.qcow2
disk     = [ 'tap:qcow2:/tmp/openwrt-x86-xen_domu-rootfs-ext2.qcow2,xvda,r', ]
vif      = [ 'bridge=virbr0' ]
name     =   '2.6.38-DomU-Test'
root     =   '/dev/xvda1'
on_crash =   'destroy'

When I boot, I get:

[...]
NET: Registered protocol family 17
802.1Q VLAN Support v1.8 Ben Greear <greearb(a)candelatech.com&gt;
All bugs added by David S. Miller <davem(a)redhat.com&gt;
Using IPI No-Shortcut mode
XENBUS: Waiting for devices to initialise: 295s...290s...285s...280s...

When I try to use:

disk     = [ 'file:/tmp/openwrt-x86-xen_domu-rootfs-ext2.img,xvda,r', ]

I get:

[No boot]
Error: Device 51712 (vbd) could not be connected. Path closed or removed during hotplug
add: backend/vbd/13/51712 state: 1

-- 
Mike

:wq

2.6.38-rc dom0 kernel and xen 4.1.0-rc2

[Pasi Kärkkäinen]

On Thu, Jan 27, 2011 at 05:03:57PM -0600, W. Michael Petullo wrote:
>  >> Now, the last issue remaining for me is the backend drivers.
> My
>  >> understanding is that, in the absence of backends being accepted
>  >> upstream, we can use QEMU-based drivers. This would be acceptable for
>  >> our work. Has anyone been using these with Fedora 15?
>   
>  > In theory the block driver should work in 4.1.0, though I am not
>  > sure about the net driver. In practise I have failed so far to get
>  > the block driver working so far. This post today
>  > http://lists.xensource.com/archives/html/xen-devel/2011-01/msg01847.html
>  > talks about what block driver configurations should work.
>  
>  I have written the following domain config (to try to force the QEMU
>  block backend):
>  
>  kernel   =   '/tmp/openwrt-x86-xen_domu-vmlinuz'
>  memory   =    32
>  # NOTE: Generated with qemu-img convert -f raw -O qcow2 input.img output.qcow2
>  disk     = [ 'tap:qcow2:/tmp/openwrt-x86-xen_domu-rootfs-ext2.qcow2,xvda,r', ]
>  vif      = [ 'bridge=virbr0' ]
>  name     =   '2.6.38-DomU-Test'
>  root     =   '/dev/xvda1'
>  on_crash =   'destroy'
>  
>  When I boot, I get:
>  
>  [...]
>  NET: Registered protocol family 17
>  802.1Q VLAN Support v1.8 Ben Greear <greearb(a)candelatech.com&gt;
>  All bugs added by David S. Miller <davem(a)redhat.com&gt;
>  Using IPI No-Shortcut mode
>  XENBUS: Waiting for devices to initialise: 295s...290s...285s...280s...
>  
>  When I try to use:
>  
>  disk     = [ 'file:/tmp/openwrt-x86-xen_domu-rootfs-ext2.img,xvda,r', ]
>  
>  I get:
>  
>  [No boot]
>  Error: Device 51712 (vbd) could not be connected. Path closed or removed during hotplug
> add: backend/vbd/13/51712 state: 1
>   
Just making sure.. you're running Xen 4.1 ?
The userspace qemu blkback implementation is *only* in Xen 4.1 ..

And it should get used automatically if dom0 kernel blkback is not available.

-- Pasi

2.6.38-rc dom0 kernel and xen 4.1.0-rc2

[W. Michael Petullo]

> >>> Now, the last issue remaining for me is the backend
> drivers. My
> >>> understanding is that, in the absence of backends being accepted
> >>> upstream, we can use QEMU-based drivers. This would be acceptable for
> >>> our work. Has anyone been using these with Fedora 15? 
> >> In theory the block driver should work in 4.1.0, though I am
> not
> >> sure about the net driver. In practise I have failed so far to get
> >> the block driver working so far. This post today
> >> http://lists.xensource.com/archives/html/xen-devel/2011-01/msg01847.html
> >> talks about what block driver configurations should work. 
> > I have written the following domain config (to try to force the
> QEMU
> > block backend):
> > 
> > kernel   =   '/tmp/openwrt-x86-xen_domu-vmlinuz'
> > memory   =    32
> > # NOTE: Generated with qemu-img convert -f raw -O qcow2 input.img output.qcow2
> > disk     = [ 'tap:qcow2:/tmp/openwrt-x86-xen_domu-rootfs-ext2.qcow2,xvda,r',
> ]
> > vif      = [ 'bridge=virbr0' ]
> > name     =   '2.6.38-DomU-Test'
> > root     =   '/dev/xvda1'
> > on_crash =   'destroy'
> > 
> > When I boot, I get:
> > 
> > [...]
> > NET: Registered protocol family 17
> > 802.1Q VLAN Support v1.8 Ben Greear <greearb(a)candelatech.com&gt;
> > All bugs added by David S. Miller <davem(a)redhat.com&gt;
> > Using IPI No-Shortcut mode
> > XENBUS: Waiting for devices to initialise: 295s...290s...285s...280s...
> > 
> > When I try to use:
> > 
> > disk     = [ 'file:/tmp/openwrt-x86-xen_domu-rootfs-ext2.img,xvda,r', ]
> > 
> > I get:
> > 
> > [No boot]
> > Error: Device 51712 (vbd) could not be connected. Path closed or removed during
> hotplug add: backend/vbd/13/51712 state: 1 
>  Just making sure.. you're running Xen 4.1 ?
>  The userspace qemu blkback implementation is *only* in Xen 4.1 .. 
Yes. I am using Michael's Xen 4.1 package.
 
>  And it should get used automatically if dom0 kernel blkback is not
> available. 
That was my understanding, but I have not yet been able to get this
to work.

-- 
Mike

:wq

2.6.38-rc dom0 kernel and xen 4.1.0-rc2

[M A Young]

On Thu, 27 Jan 2011, W. Michael Petullo wrote:

>  When I try to use:
>
>  disk     = [ 'file:/tmp/openwrt-x86-xen_domu-rootfs-ext2.img,xvda,r', ]
>
>  I get:
>
>  [No boot]
>  Error: Device 51712 (vbd) could not be connected. Path closed or removed during hotplug
> add: backend/vbd/13/51712 state: 1 
I have finally got a domU to boot in this sort of situation, having found 
a few bugs in 4.1.0-rc2 on the way when trying to use pygrub as a 
bootloader. Note that you may have to use xl rather than xm because they 
are deprecating xm and xm may not have support for qemu block backends.

 	Michael Young

2.6.38-rc dom0 kernel and xen 4.1.0-rc2

[W. Michael Petullo]

>  I have finally got a domU to boot in this sort of situation, having
>  found a few bugs in 4.1.0-rc2 on the way when trying to use pygrub
>  as a bootloader. Note that you may have to use xl rather than xm
>  because they are deprecating xm and xm may not have support for qemu
>  block backends. 
Does anyone know where I can find documentatin on domain configuration
for xl? There does not seem to be a man page and a review of the Xen Wiki
did not find authoritative documentation. I am trying to figure out how
to write an xl configuration, i.e., rewrite xmexample1 to work with xl.

-- 
Mike

:wq

2.6.38-rc dom0 kernel and xen 4.1.0-rc2

[Todd Deshane]

On Sun, Jan 30, 2011 at 6:17 PM, W. Michael Petullo <mike(a)flyn.org&gt; wrote:
> > I have finally got a domU to boot in this sort of situation,
> having
> > found a few bugs in 4.1.0-rc2 on the way when trying to use pygrub
> > as a bootloader. Note that you may have to use xl rather than xm
> > because they are deprecating xm and xm may not have support for qemu
> > block backends.
>
>  Does anyone know where I can find documentatin on domain configuration
>  for xl? There does not seem to be a man page and a review of the Xen Wiki
>  did not find authoritative documentation. I am trying to figure out how
>  to write an xl configuration, i.e., rewrite xmexample1 to work with xl.
>  
You can pull examples for the Xen test suite, for example, take a look
at one of the tests:
http://www.chiark.greenend.org.uk/~xensrcts/logs/5501/

The syntax is rather similar, and we'll need to formally document it
on the xen wiki soon.

Hope that helps,
Todd

2.6.38-rc dom0 kernel and xen 4.1.0-rc2

[M A Young]

On Sun, 30 Jan 2011, W. Michael Petullo wrote:

> > I have finally got a domU to boot in this sort of situation,
> having
> > found a few bugs in 4.1.0-rc2 on the way when trying to use pygrub
> > as a bootloader. Note that you may have to use xl rather than xm
> > because they are deprecating xm and xm may not have support for qemu
> > block backends.
>
>  Does anyone know where I can find documentatin on domain configuration
>  for xl? There does not seem to be a man page and a review of the Xen Wiki
>  did not find authoritative documentation. I am trying to figure out how
>  to write an xl configuration, i.e., rewrite xmexample1 to work with xl. 
It is supposed to be a direct replacement for xm, the idea being for 
configuration files for xm to work for xl, though not necessarily the 
other way around. In practice, you can still find stuff that doesn't yet 
work.

 	Michael Young

2.6.38-rc dom0 kernel and xen 4.1.0-rc2

[Pasi Kärkkäinen]

On Sun, Jan 30, 2011 at 11:52:56PM +0000, M A Young wrote:
>  On Sun, 30 Jan 2011, W. Michael Petullo wrote:
>  
>  >> I have finally got a domU to boot in this sort of situation, having
>  >> found a few bugs in 4.1.0-rc2 on the way when trying to use pygrub
>  >> as a bootloader. Note that you may have to use xl rather than xm
>  >> because they are deprecating xm and xm may not have support for qemu
>  >> block backends.
>  >
>  > Does anyone know where I can find documentatin on domain configuration
>  > for xl? There does not seem to be a man page and a review of the Xen Wiki
>  > did not find authoritative documentation. I am trying to figure out how
>  > to write an xl configuration, i.e., rewrite xmexample1 to work with xl.
>  
>  It is supposed to be a direct replacement for xm, the idea being for 
>  configuration files for xm to work for xl, though not necessarily the 
>  other way around. In practice, you can still find stuff that doesn't yet 
>  work.
>   
With the exception that xl doesn't support embedded python code
in the cfgfiles.

-- Pasi

2.6.38-rc dom0 kernel and xen 4.1.0-rc2

[W. Michael Petullo]

> >>> I have finally got a domU to boot in this sort of
> situation, having
> >>> found a few bugs in 4.1.0-rc2 on the way when trying to use pygrub
> >>> as a bootloader. Note that you may have to use xl rather than xm
> >>> because they are deprecating xm and xm may not have support for qemu
> >>> block backends. 
> >> Does anyone know where I can find documentatin on domain
> configuration
> >> for xl? There does not seem to be a man page and a review of the Xen Wiki
> >> did not find authoritative documentation. I am trying to figure out how
> >> to write an xl configuration, i.e., rewrite xmexample1 to work with xl. 
> > It is supposed to be a direct replacement for xm, the idea being
> for 
> > configuration files for xm to work for xl, though not necessarily the 
> > other way around. In practice, you can still find stuff that doesn't yet 
> > work. 
>  With the exception that xl doesn't support embedded python code
>  in the cfgfiles. 
I am able to boot a DomU kernel using
xl with xen-4.1.0-0.1.rc2.fc14.x86_64 and
kernel-2.6.38-0.rc2.git3.2.xendom0.fc15.x86_64. Both block and network
devices work.

-- 
Mike

:wq