[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:57:52 -0400
  • Cc: xen-users@xxxxxxxxxxxxxxxxxxx, Paul Schulze <avlex@xxxxxxx>
  • Delivery-date: Sat, 24 May 2008 19:58:22 -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=xx8zaaQ4mUbipP3rjCb8CGyT14Po2LrBQUmi64Io5pszb7P0fqJPlOdWbqWygj76SPrvQVT5Yb/v8Se8x//7k207xKKlpe+LOpRi0aaTwCE8U+knyVsczPeSaPzMZfk7RKDrghHUAS09BM7XRMiyLvBvbVDlV0AafrZXykehaVA=
  • List-id: Xen user discussion <xen-users.lists.xensource.com>

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

#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



bootloader = '/usr/bin/pygrub'
memory = 640
name = "Ubuntu-Hardy-Mythtv"
disk = 
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
> 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®.