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/
Home Products Support Community News


Re: [Xen-users] PCI Passthrough

To: "Mark Williamson" <mark.williamson@xxxxxxxxxxxx>
Subject: Re: [Xen-users] PCI Passthrough
From: "Christopher Isip" <cmisip@xxxxxxxxx>
Date: Sat, 24 May 2008 22:58:37 -0400
Cc: xen-users@xxxxxxxxxxxxxxxxxxx, Paul Schulze <avlex@xxxxxxx>
Delivery-date: Sat, 24 May 2008 19:59:12 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=ghnDtBuR9DUNMJmshAeezLV/zStBj5ZX+li/mJjRnpU=; b=GmbuZYgHj3gGeaEsMoybsuUTc7g/Iz7XM9LcXrfOXASVMZB961XAHBD4eQfPjBhPJ6htQlOwMBN3OLllrHsec8FnM+Xvrlcqmv5oVPP8anjFSsh7BNfzDDHwzgkC6l4DncngnXuqoM+BEE3bxSzQRK8ritvCV3NAKfv8yCOhn3Y=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=IwCHBXl0l6hwzbSDy7Y42vVuSe60xbPZI8nxkktD+yj87AgI6H91z3RqePEcivn5G4ht5AuqcRDZAsc+L7LOo+d6YWDarM1Kujx4xnst188QS3/i6m0eRNdvj1kLsGKPMUT8fO+ElBzJ5q9TO/hw774V7Oga0e3bVcla+D1CUa4=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <4bca5f6c0805241957j98a3234w381340cb3e8546a8@xxxxxxxxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
References: <46D155E5-0535-4AED-A0F9-C3ED427D7B3F@xxxxxxx> <4bca5f6c0805240535y2146b5fag5f49e870eae6e538@xxxxxxxxxxxxxx> <164F5CA3-BB1B-4CBB-9898-5EB769C141E0@xxxxxxx> <200805250122.45707.mark.williamson@xxxxxxxxxxxx> <4bca5f6c0805241957j98a3234w381340cb3e8546a8@xxxxxxxxxxxxxx>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
By the way, make sure to run the mythtv domU first before any other domU's.


On 5/24/08, Christopher Isip <cmisip@xxxxxxxxx> wrote:
> 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)
>         root (hd0,5)
>         kernel /boot/xen.gz-3.2
>         module /boot/vmlinuz-2.6-xen ro root=LABEL=/ rhgb quiet
>         module /boot/initrd-2.6-xen.img
> 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
> /etc/modprobe.conf
> #Our network
> 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
> --ignore-install e100
> /etc/xen/xend-pci-permissive.sxp
> (unconstrained_dev_ids
>       ('4444:0016:0070:e817'
>        '4444:0016:0070:e807'
>        '4444:0016:0070:4801'
>        '8086:27dc:1028:01ab')
> )
> /etc/xen/Ubuntu-Hardy-Mythtv.cfg
> bootloader = '/usr/bin/pygrub'
> memory = 640
> name = "Ubuntu-Hardy-Mythtv"
> disk =
> ['file:/vm/Ubuntu-Hardy-Mythtv.img,hda1,w','file:/vm/Ubuntu-Hardy-Mythtv-swap.img,hda2,w']
> vif = [ '' ]
> pci = [ "0000:03:02.0","0000:04:08.0","0000:04:09.0" ]
> extra = "swiotlb=force"
> Hope this helps
> Chris
> 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
>> aren't
>> 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
>> required?
>>> 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
>> fine
>> 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
>> answer
>> for you though.
>> Cheers,
>> Mark
>> --
>> Push Me Pull You - Distributed SCM tool
>> (http://www.cl.cam.ac.uk/~maw48/pmpu/)
>> _______________________________________________
>> Xen-users mailing list
>> Xen-users@xxxxxxxxxxxxxxxxxxx
>> http://lists.xensource.com/xen-users

Xen-users mailing list

<Prev in Thread] Current Thread [Next in Thread>