I use Centos 5.1 dom0 with xen 3.1 rpms and xen 3.2 rpms installed from xen.org
Here's my grub config:
title CentOS (2.6.18-xen_3.2.0)
module /boot/vmlinuz-2.6-xen ro root=LABEL=/ rhgb quiet
where vmlinuz-2.6-xen is a symlink to vmlinuz-2.6.18-xen_3.1.0
and initrd-2.6-xen.img is a symlink to initrd-2.6.18-xen_3.1.0.img
alias eth0 usbnet
alias eth1 e100
alias scsi_hostadapter ata_piix
#hide some pci devices: e100, pvr 250 video0, pvr 500 video1 and video2
options pciback hide=(0000:03:08.0)(0000:03:02.0)(0000:04:08.0)(0000:04:09.0)
install e100 /sbin/modprobe pciback ; /sbin/modprobe --first-time
bootloader = '/usr/bin/pygrub'
memory = 640
name = "Ubuntu-Hardy-Mythtv"
vif = [ '' ]
pci = [ "0000:03:02.0","0000:04:08.0","0000:04:09.0" ]
extra = "swiotlb=force"
Hope this helps
On 5/24/08, Mark Williamson <mark.williamson@xxxxxxxxxxxx> wrote:
>> I have already heard about IOMMU being implemented in Intel CPUs (or
>> probably the North Bridge, because as I hear that is where the Memory
>> Controller is located) only, however, as far as I can see AMD isn't
>> quiet there yet (I hear they postponed it to 2009 again, almost
>> reminds me of GNU/Hurd). However, that is one of the main problems I
>> am facing: Intel does not offer a suitable basis for low power
>> systems with desktop performance.
> How low do you need the power consumption to be? Intel's recent chips
> as scarily "hungrier than everything else" as they were back in the old
> Pentium 4 days, although I guess the "normal" power consumption has gone up
> since then too...
> I'd also note that there are now tiny motherboards based on Intel's Atom CPU
> for very low power applications, although they won't give you the desktop
> performance you want. You might want to consider splitting some of the
> functionality of this system off onto a minimal box like that so the
> powerful, hungry desktop hardware can be powered off completely when not
>> I already looked far and wide for a
>> suitable CPU + Mainboard combination with low power consumption and
>> onboard 3D graphics that are worth something and I'm sorry to say,
>> but Intel's are definitively not (compared to the AMD 4x50e CPUs with
>> AMD780G chipsets at least). So I am basically bound to AMD for this
>> particular project.
> OK. Well if you have a particularly compelling need for AMD then that's
> but it is going to be a problem for the security of PCI passthrough...
>> I already looked around for clues on a software IOMMU implementation
>> too, but the only thing I could find was SWIOTLB. As I understand it,
>> this solution merely allows 32bit devices to use more than 4gb of
>> RAM, or is there a way to use it as a software IOMMU in the sense of
>> Intel VT-d too? If not, is there another way to emulate IOMMU or at
>> least protect the system from a potentially compromised privileged
>> DomU until AMD CPUs supporting this feature are available?
> I'm afraid there's no practical way of doing untrusted PCI passthrough
> securely without having an IOMMU in hardware. Without special hardware to
> enforce memory access controls, a domain with direct access to a PCI card
> will be able to get it to access memory it should not be touching :-(
> I'm afraid the "solution" to running untrusted operating systems is to
> virtualise the devices too - using virtual network, graphics, etc devices,
> it's possible to provide more stringent controls on what they can / can't do
> than if you've given a guest *real* hardware. Unfortunately, this doesn't
> seem to be a particularly good fit for most of what you want to do :-(
>> And am I
>> correct to assume that a possible feature for AMD CPUs will possibly
>> not need support from the chipset, because the Memory Controller is
>> located on the CPU?
> That sounds sane but I don't know enough about the AMD platform (and their
> corporate plans!) to answer that one reliably.
>> I hope someone can help me out of my confusion,
> I hope that clears things up a bit. Sorry if it's not really the ideal
> for you though.
> Push Me Pull You - Distributed SCM tool
> Xen-users mailing list
Xen-users mailing list