Re: [Xen-users] PCI Passthrough

["Christopher Isip" <cmisip@xxxxxxxxx>]

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
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users