By the way, make sure to run the mythtv domU first before any other domU's.
Chris
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
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home