[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-users] PCI Passthrough
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |