[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-users] PCI Passthrough

  • To: "Mark Williamson" <mark.williamson@xxxxxxxxxxxx>
  • 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
  • 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=
  • List-id: Xen user discussion <xen-users.lists.xensource.com>

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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.