I have a new dom0 kernel available for testing
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.
As reported earlier, I have been using 2.6.38-0.rc2.git3.2.xendom0.fc15
with good results. One thing I have come across is that power management
does not seem to work. For example, "pm-suspend" does not suspend my
system. Instead, the system merely becomes unresponsive. On the other
hand, 188.8.131.52-174.2.xendom0 suspends fine.
2.6.38-0.rc2.git3.2.xendom0.fc15 also does not power down my system when
I run shutdown. The last things that is printed to the console is:
[7962.081194] Power down.
The system "halts" but does not power down.
I am trying to work out whether it is practical to propose Dom0 xen
support as a feature for Fedora 15.
The kernel situation is that Domain 0 has been accepted upstream for
2.6.37. Assuming a 3 month kernel release cycle, F15 will most likely ship
with a 2.6.37.x kernel, with 2.6.38 coming out either after the F15
release or just before but too late to be included. If the plan to get key
xen drivers into 2.6.38 succeeds, then F15 may be become usable as a
Domain 0 system at some point during its lifetime as the kernel package in
a Fedora version typically has one major update.
If the kernel team accept backported patches then it might just be
possible to ship F15 with usable Domain 0 support but the timescale for
that would be very tight.
The other thing we would need to consider is what needs to be done to make
xen friendly enough to be usable by an ordinary user. The page
https://fedoraproject.org/wiki/Features/XenPvopsDom0 contains plans from
when dom0 xen support was expected to make a quick return to Fedora, but
they are a couple of years old now so probably need updating.
I think as a minimum we would need a way to add a dom0 enabled grub entry
for a kernel, rather than requiring the user to hand edit the grub file.
We should also make sure that xen works with the other Fedora
What do others think about this? For example is it achievable as a
feature, is it too early and better to wait for F16, and what else should
we aim to do to make xen usable in Fedora?
This is something I raised on the upstream xen-devel mailing list. I
have not yet received any response, so I though I'd try to ask here:
I am using Xen with the included network-route and vif-route scripts. My
system runs Fedora 14 with Michael Young's Dom0 kernel.
When xend starts and network-route executes, I see the following error:
/etc/xen/scripts/network-route: line 28:
/proc/sys/net/ipv4/conf/eth/proxy_arp: No such file or directory
It seems that the problem is that the vifnum shell variable is not set.
Later, when I start an unprivileged domain, I see:
physdev match: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING
chains for non-bridged traffic is not supported anymore.
Are these messages expected?
I have submitted a report to the Red Hat Bugzilla system:
The report includes two patches that fix this issue for me.
I tried M A Young's precompiled 2.6.37 XEN kernel (under xen-4.0.1-6.fc14.x86_64, grub.conf modified.
I have a Radeon card.
I booted with and without modesetting, without success.
I booted successfully with Radeon driver without acceleration.
I'm sending this email from Dom0 :) Speed is as expected.
Here is the bug report:
Plain Radeon without any xorg.conf modifications on Fedora 14:
Initially there was a graphical modesetting based startup.
I switched from graphical startup progress graphics into text mode during boot: I could see textual progress messages during bootup.
When X tried to start, Radeon kernel driver caused a page fault, that it couldn't handle.
Full kernel stack trace was visible on the screen, and it could be looked up with Shift + page up / page down.
Unfortunately I don't have time to take a log via serial port this weekend.
With nomodeset, booting up progressed (disk IO heard), but the screen was blank all the time. I initiated a reboot from the keyboard.
With modesetting with the bug, keyboard didn't work. I initiated a reboot via reset button.
Here is the xorg.conf's part as a workaround for Radeon driver problem, /etc/xorg.conf.d/00-radeon.conf for Fedora 14:
Option "NoAccel" "true"
Option "DRI" "false"
Option "DPMS" "true"