I was trying to get a NVIDIA video driver working with the Fedora 9 kernel
188.8.131.52-41.fc9 (on x86_64) and it refused because it decided it was a xen
kernel, so I thought I would check this claim out.
My attempts to boot a xen guest with that kernel failed, though it got
past the boot loader stage, and I know Fedora 9 has kernel-xen packages,
but I was wondering whether this kernel would be expected to work or not.
Could someone with wiki access update that page.. it contains a lot of
out-of-date information. That page is also referenced in F10 release notes..
- "Work on getting Dom0 support in the upstream kernel has pretty much stalled
for the last number of months so this feature is postponed until work
- "Last updated: 2008-07-30"
- "x86_64 Dom0 No active work yet...."
And many more things are out-of-date, because they're based on earlier work
by Redhat/Fedora people..
Upstream (Xensource) is actively working on pv_ops dom0 now, and it's
getting close to being included upstream.
latest pv_ops dom0 patches:
Xen wiki pv_ops status page:
I have virt-manager with a static ip'ed windows server 2003 and a win xp
client so I can play with active directory etc for work. All under
Fedora 10 beta.
Can someone tell me if I can turn off the dhcp and dns in the
virt-manager framework (vibr0) as it is handing out an ip to my client
before the virtual windows server does. I believe this is confusing the
issue when I try to join the client to my virtual windows domain.
I only wish the virt-manager to nat vibr0 to my physical nic so i can
provide the other config items from within my virtual network.
Stephen Johnston 8 Lime Grove
Tel. +44 (0)1506 437766 Craigshill
Mob. 07786 733 150 Livingston
I can't seem to make a rawhide domU work on a RHEL5.2 dom0, because
virt-install doesn't think that there's a valid tree. Looking at it,
there is indeed no images/xen in the tree, are we using the standard
kernel for DomU's now, or is F10 not going to be supported as a domU?
This is on x86_64.
Sorry for the annoying cross post.
The next Fedora Weekly News will be published Monday, one day before
the release of Fedora 10. I would like dedicate a special section of the
Virtualization Beat to touting the advances and new features in F10.
As with the release notes, I am seeking your input. (A little late, I
know.) I'm interested not only in the new virtualization features and
breakthroughs found in the F10 release, but also any updates that might
be right around the corner in f10-updates.
Perhaps you have some special insight into the upstream progress of
pv_ops, or maybe you know about a almost complete implementation of a
libvirt API feature into virt-manager or...
I'm sorry if this is a little scattershot. For sometime, I've considered
trying to present questions in interview style to each of these lists,
but I just haven't gotten that together.
The publication deadline is Sunday night, but I'll be able to use
anything in the next edition of FWN. Please contribute, even if you read
this on Monday.
Dale Bewley - Unix Administrator - Shields Library - UC Davis
GPG: 0xB098A0F3 0D5A 9AEB 43F4 F84C 7EFD 1753 064D 2583 B098 A0F3
----- Forwarded message from Keir Fraser <keir.fraser(a)eu.citrix.com> -----
From: Keir Fraser <keir.fraser(a)eu.citrix.com>
To: "xen-devel(a)lists.xensource.com" <xen-devel(a)lists.xensource.com>
Cc: "Dugger, Donald D" <donald.d.dugger(a)intel.com>
Date: Fri, 21 Nov 2008 13:02:26 +0000
Subject: [Xen-devel] Linux 2.6.27 temporary tree on xenbits
As a stop-gap measure until full dom0 support is ready in pv_ops, I've
placed a Linux 2.6.27 tree at
Actually this is a Novell-patched 2.6.27 kernel -- see 00-README in the repo
for more details.
The intention is to give a single source tree to develop and test against
for those developers who need a more modern 2.6 kernel for advanced platform
work such as power management. Regular test and maintenance will continue to
focus on 2.6.18, with a grand switchover when pv_ops in kernel.org is
considered sufficiently ready.
Xen-devel mailing list
----- End forwarded message -----
I am new to Xen and have been having some problems getting it running. I had
posted on the xen-users list but they recommended that I direct my questions
to this list. So I apologize if this is misdirected. I am just trying to
find a solution to the issue I am having. I have read and followed several
tutorials and tried different fixes for this issue but have had no luck.
Here is my server setup first:
Dual Core - Dual Processor Xeon 5120
Virtualization support in bios is enabled
No direct console access, only remote access via SSH2
I have used the tutorial located at http://www.howtoforge.com/centos_5.0_xen
Everything works up until I run virt-install to create the domU. I run
virt-install with the -nographics switch and get the following
No console available for domain
Domain installation still in progress. You can reconnect to the console to
complete the installation process.
I then tried to connect to the console using
Xm console 5
And I get:
xenconsole: Could not read tty from store: No such file or directory
I looked at the qemu log in /var/log/xen
And this is what I see
qemu: the number of cpus is 1
*** image /local/domain/0/backend/vbd/5/768 format raw driver
*** image /local/domain/0/backend/vbd/5/5632 format raw driver
0x80e7940 Watching /local/domain/5/logdirty/next-active
Could not initialize SDL - exiting
I am however unable to find any information on this error. So basically I am
in need of help in getting a domU started and running. Can someone please
give me some advice, point me in the right direction etc?
Thanks in advance
----- Forwarded message from Jeremy Fitzhardinge <jeremy(a)goop.org> -----
From: Jeremy Fitzhardinge <jeremy(a)goop.org>
To: Ingo Molnar <mingo(a)elte.hu>
Cc: linux-kernel(a)vger.kernel.org, Xen-devel <xen-devel(a)lists.xensource.com>,
the arch/x86 maintainers <x86(a)kernel.org>,
Ian Campbell <ian.campbell(a)citrix.com>
Date: Thu, 13 Nov 2008 11:09:58 -0800
Subject: [PATCH 00 of 38] xen: add more Xen dom0 support
Here's the chunk of patches to add Xen Dom0 support (it's probably
worth creating a new xen/dom0 topic branch for it).
A dom0 Xen domain is basically the same as a normal domU domain, but
it has extra privileges to directly access hardware. There are two
issues to deal with:
- translating to and from the domain's pseudo-physical addresses and
real machine addresses (for ioremap and setting up DMA)
- routing hardware interrupts into the domain
ioremap is relatively easy to deal with. An earlier patch introduced
the _PAGE_IOMAP pte flag, which we use to distinguish between a
regular pseudo-physical mapping and a real machine mapping.
Everything falls out pretty cleanly. A consequence is that the
various pieces of table-parsing code - DMI, ACPI, MP, etc - work out
of the box.
Similarly, the series adds hooks into swiotlb so that architectures
can allocate the swiotlb memory appropriately; on the x86/xen side,
Xen hooks these allocation functions to make special hypercalls to
guarantee that the allocated memory is contiguous in machine memory.
Interrupts are a very different affair. The descriptions in each
patch describe how it all fits together in detail, but the overview
1. Xen owns the local APICs; the dom0 kernel controls the IO APICs
2. Hardware interrupts are delivered on event channels like everything else
3. To set this up, we intercept at pcibios_enable_irq:
- given a dev+pin, we use ACPI to get a gsi
- hook acpi_register_gsi to call xen_register_gsi, which
- allocates an irq (generally not 1:1 with the gsi)
- asks Xen for a vector and event channel for the irq
- program the IO APIC to deliver the hardware interrupt to the
The upshot is that the device driver gets an irq, and when the
hardware raises an interrupt, it gets delivered on that irq.
We maintain our own irq allocation space, since the hardware-bound
event channel irqs are intermixed with all the other normal Xen event
channel irqs (inter-domain, timers, IPIs, etc). For compatibility the
irqs 0-15 are reserved for legacy device interrupts, but the rest of
the range is dynamically allocated.
Initialization also requires care. The dom0 kernel parses the ACPI
tables as usual, in order to discover the local and IO APICs, and all
the rest of the ACPI-provided data the kernel requires. However,
because the kernel doesn't own the local APICs and can't directly map
the IO APICs, we must be sure to avoid actually touching the hardware
when running under Xen.
TODO: work out how to fit MSI into all this.
So, in summary, this series contains:
- dom0 console support
- dom0 xenbus support
- CPU features and IO access for a privleged domain
- making ioremap work on machine addresses
- swiotlb allocation hooks
- introduce PV io_apic operations
- add Xen-specific IRQ allocator
- switch to using all-Xen event delivery
- add pirq Xen interrupt type
- table parsing and setup
- intercept driver interrupt registration
All this code will compile away to nothing when CONFIG_XEN_DOM0 is not
enabled. If it is enabled, it will only have an effect if booted as a
dom0 kernel; normal native execution and domU execution should be
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
----- End forwarded message -----