-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello everyone, I am currently in the planning phase for a new HTPC system, I want to set up and there are several questions related to Xen that I was not able to find answers to. The goal of that system in the long run is to replace not only my server and TV receiver, but also my primary desktop and access point for several LAN and Wifi clients. Though this might sound rather simple, the solution I am hoping for has to separate all these tasks in virtual machines, leaving the Dom0 strictly as a controller for those and only accessible by SSH from one virtual machine (probably the Desktop). This would ensure that I can work on one instance (which might need tinkering with the kernel for example) while all other services are still available and it would help me sandbox all the components, so none of them directly influences the other. The system would be an AMD Athlon X2 4850e CPU on an Asus M3A-H mainboard (AMD 780G chipset). The questions I have now are: 1. Is it possible to successfully pass through a graphics adapter, in this case probably an onboard ATI HD 3200 PCIe (currently only supported with the non-free fglrx driver), so that the Desktop/TV virtual machine has exclusive use of the hardware including (future) 3D support? I would also like to try other systems that can not be paravirtualized, while the other services have to still be running. In some of these systems I would like to have 3D hardware acceleration support (Desktop VM would have to be shut down as I understand it), since they heavily depend on it (like Vista or maybe Mac OS X). Is that possible? I already read that it is rather problematic to pass through the primary VGA adapter, because Xen itself will always claim it for console output at boot time, but wouldn''t it be possible to use a serial port for that instead? Are there any other pitfalls that will not permit me to achieve this? 2. Is it possible to have a virtual machine hosting a MythTV backend, that has exclusive use of a PCI(e) or PCMCIA DVB-T/S/S2 adapter. This backend should not run in the Desktop instance, because I would prefer it if the Desktop doesn''t have to be running for other clients to use it. This would also come in handy, because not running a full blown desktop while using the MythTV backend from another client could possibly save a bit on the energy bill (and the whole system is supposed to help me reduce that at least a bit) 3. I would like to pass 3 NICs (HP 4 port gbit switch pci card, D- Link 4x T100Base card and a Ralink pci 802.11n draft 2.0 adapter) directly to an AP/Router virtual maschine, so the Dom0 is not connected directly to the network, but only to the Desktop VM by a separate bridge and the onboard gbit adapter (for backups/failover). Is that possible and am I really gaining security for the whole system or is this just my imagination and doesn''t make any sense at all? How about the performance, especially for the graphics adapter, do I have to factor in bigger losses there (maybe because PCI passthrough doesn''t support the full PCIe 16x speed)? Has anyone tried something similar yet or am I the first to think this might be a good idea? I hope someone can give me an answer or at least a hint on how far I am from reality. Thanks, Paul. - -- Paul Schulze avlex@gmx.net Public Key: http://solaris-net.dyndns.org/keys/key_avlex.asc "Making mistakes is human, but to really fuck things up you need Computers" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFIN4QuYDWOGtiChoARAn2yAJ9RsIf7zLpGWhHQ1JJcb+cX739jAQCeNgRg tP8MXF4wMjaauElDH/oboz8=LHN/ -----END PGP SIGNATURE----- _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi Paul, I''m not going to answer all your questions since I don''t have a lot of experience with many of the things you mention. However I can do the second part and give some hints on what I do know.> Is that possible and am I really gaining security for the whole system or is > this just my imagination and doesn''t make any sense at all? How about the > performance, especially for the graphics adapter, do I have to factor in > bigger losses there (maybe because PCI passthrough doesn''t support the full > PCIe 16x speed)? Has anyone tried something similar yet or am I the first to > think this might be a good idea?For PCI passthrough to be secure you need a system that has an IOMMU. It is my understanding that the only IOMMUs that are currently available are in the Intel VT-d systems. The reason you need the IOMMU is that otherwise the domain that you give direct access to the physical device could DMA into main memory and compromise the security of the system. So, you first need to look for a system with an IOMMU. I really like you explanation of what you want and what you are trying to accomplish, I believe you are right on in terms of the VGA passthrough and using serial for the Xen output instead. I have read the experiences of others for that case and it seems that part you could do. People have also reported using Xen and mythTV, so I think that is also quite possible. There are a lot of details to get right, but by the sounds of it you are willing to figure them and make things work. As for all the networking stuff Xen is pretty good at that already and it will be a matter of setting it up. Your biggest initial hurdle is the IOMMU. Take a look at the VT-d stuff there is a lot going on with that on the xen mailing lists. (try xen.markmail.org if you haven''t already, it has pretty good search). You can find information on some of the other things as well, but I would expect that within the next few days others would share their experiences on some of the items that you mentioned. Cheers, Todd _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Fri, May 23, 2008 at 11:57 PM, Todd Deshane <deshantm@gmail.com> wrote:> Hi Paul, > > I''m not going to answer all your questions since I don''t have a lot of > experience with many of the things you mention. However I can do > the second part and give some hints on what I do know. > > > Is that possible and am I really gaining security for the whole system or > is > > this just my imagination and doesn''t make any sense at all? How about the > > performance, especially for the graphics adapter, do I have to factor in > > bigger losses there (maybe because PCI passthrough doesn''t support the > full > > PCIe 16x speed)? Has anyone tried something similar yet or am I the first > to > > think this might be a good idea? > > For PCI passthrough to be secure you need a system that has an IOMMU. It is > my understanding that the only IOMMUs that are currently available are in > the > Intel VT-d systems. The reason you need the IOMMU is that otherwise the > domain that you give direct access to the physical device could DMA into > main memory and compromise the security of the system. > > So, you first need to look for a system with an IOMMU. > > I really like you explanation of what you want and what you are trying to > accomplish, I believe you are right on in terms of the VGA passthrough and > using serial for the Xen output instead. I have read the experiences of > others > for that case and it seems that part you could do. > > People have also reported using Xen and mythTV, so I think that is also > quite possible. > > There are a lot of details to get right, but by the sounds of it you are > willing > to figure them and make things work. As for all the networking stuff Xen is > pretty good at that already and it will be a matter of setting it up. > > Your biggest initial hurdle is the IOMMU. Take a look at the VT-d stuff > there > is a lot going on with that on the xen mailing lists. (try > xen.markmail.org if > you haven''t already, it has pretty good search). > > You can find information on some of the other things as well, but I would > expect that within the next few days others would share their experiences > on some of the items that you mentioned. > > Cheers, > Todd > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users >I am currently running a mythtv backend in a Xen domU. It seems to be working well. I am on the last stages of configuration. Its using Ubuntu Hardy. Since it is a 2.6.24 kernel (compared to my Dom0 2.6.18), there are far fewer DMA errors. Some issues that I haven''t resolved yet: mythfilldatabase segfault in dmesg ( runs fine on command line) PVR 250/500 record at default bitrate (2.2 Gb an hour) as opposed to settings in the database. The domU does not have a mysql server. This is still in dom0 but I will be moving that to its own domU next. It also nfs mounts the video directories from dom0. I like to keep my DomUs at 4 Gigabyte or less for easy backup to a DVD. If you need help setting up your mythtv DomU, let me know. Chris _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Christopher Isip schrieb:> > If you need help setting up your mythtv DomU, let me know. > > ChrisHello ! I also want to run mythbuntu backend in a DomU if its not a problem to pass thru the DVB S/S2 PCI-Card(s) (in the moment only one Hauppauge HVR 4000). Would you be so kind to post the XEN Config Files dor the mythbuntu DomU and your grub-settings dor Dom0 ? -- __________________________________________________ Ralf Schenk fon (02 41) 9 91 21-0 fax (02 41) 9 91 21-59 rs@databay.de Databay AG Hüttenstraße 7 D-52068 Aachen www.databay.de Vorstand: Jens Conze, Ralf Schenk, Aresch Yavari Aufsichtsratvorsitzender: Ansgar Vögeli Sitz/Amtsgericht Aachen HRB:8437 USt-IdNr.: DE 210844202 Databay - einfach machen. _________________________________________________ _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> I am currently in the planning phase for a new HTPC system, I want to > set up and there are several questions related to Xen that I was not > able to find answers to. The goal of that system in the long run is > to replace not only my server and TV receiver, but also my primary > desktop and access point for several LAN and Wifi clients. Though > this might sound rather simple, the solution I am hoping for has to > separate all these tasks in virtual machines, leaving the Dom0 > strictly as a controller for those and only accessible by SSH from > one virtual machine (probably the Desktop). This would ensure that I > can work on one instance (which might need tinkering with the kernel > for example) while all other services are still available and it > would help me sandbox all the components, so none of them directly > influences the other. The system would be an AMD Athlon X2 4850e CPU > on an Asus M3A-H mainboard (AMD 780G chipset).As Todd mentioned, the only VT-d capable systems available currently are the Intel ones, AFAIK. I understand that AMD''s IOMMU systems will be along in the not-too-distant future but they''re not with us yet.> The questions I have now are: > 1. Is it possible to successfully pass through a graphics adapter, in > this case probably an onboard ATI HD 3200 PCIe (currently only > supported with the non-free fglrx driver), so that the Desktop/TV > virtual machine has exclusive use of the hardware including (future) > 3D support? I would also like to try other systems that can not be > paravirtualized, while the other services have to still be running. > In some of these systems I would like to have 3D hardware > acceleration support (Desktop VM would have to be shut down as I > understand it), since they heavily depend on it (like Vista or maybe > Mac OS X). Is that possible? I already read that it is rather > problematic to pass through the primary VGA adapter, because Xen > itself will always claim it for console output at boot time, but > wouldn''t it be possible to use a serial port for that instead? Are > there any other pitfalls that will not permit me to achieve this?Funnily enough, quite recently a patch was posted which apparently enables you to start an HVM domain (on a system with VT-d) and pass the host''s primary graphics card to it. (xen-devel thread here: http://markmail.org/message/gecwbq4oqttszxvo) Bear in mind that''s development code so it''s not guaranteed to work stably / at all. Still, it''s a step in the right direction and hopefully it might make it into a future release of Xen - it''s not even in the -unstable tree yet though, so if you wanted to try it you''d have to apply the patch yourself and build Xen. In principle this would allow you to do what you want to do for your desktop VM, *if* you were happy to run it in HVM. This would mean a bit of a performance hit for Linux but probably not too bad if you installed PV drivers in the guest. For Windows, you''d need to run it in HVM anyhow. For MacOS, an off-the-shelf guest won''t work because HVM doesn''t have EFI; the MacOSx86 project have done work on getting MacOS running on non-EFI systems, though. Of course, Apple''s EULA still requires that you only run MacOS on a Mac ... People have also made some progress with using PCI passthrough to give a non-primary graphics card to a PV domU but I''m not sure if anyone managed to get a full X server running, so I don''t know if you could do this :-/> 2. Is it possible to have a virtual machine hosting a MythTV backend, > that has exclusive use of a PCI(e) or PCMCIA DVB-T/S/S2 adapter. This > backend should not run in the Desktop instance, because I would > prefer it if the Desktop doesn''t have to be running for other clients > to use it. This would also come in handy, because not running a full > blown desktop while using the MythTV backend from another client > could possibly save a bit on the energy bill (and the whole system is > supposed to help me reduce that at least a bit)This should be doable. You''ve been able to pass through many PCI cards to PV domUs for ages without needing any special hardware. This always had the consequence that the domU had to be trusted because by abusing the PCI device it could gain dom0-equivalent privileges (if a sufficiently clever and determined attacker took it over, for instance). Support has just gone into the -unstable tree for restricting PV domUs using VT-d so that they can be less trusted. I don''t know if the intention is to allow them to be completely untrusted but VT-d certainly closes a big loophole! People have done this sort of thing before with PV guests and today somebody posted saying he''d passed a TV card to an HVM guest. Some cards misbehave when using PCI passthrough so it may be worth searching the mailing lists for success reports.> 3. I would like to pass 3 NICs (HP 4 port gbit switch pci card, D- > Link 4x T100Base card and a Ralink pci 802.11n draft 2.0 adapter) > directly to an AP/Router virtual maschine, so the Dom0 is not > connected directly to the network, but only to the Desktop VM by a > separate bridge and the onboard gbit adapter (for backups/failover).Wow! Again, passing those through to a domU using PCI passthrough ought to work in principle but it''s worth searching for success reports as to whether the cards / drivers play well with PCI passthrough.> Is that possible and am I really gaining security for the whole > system or is this just my imagination and doesn''t make any sense at > all? How about the performance, especially for the graphics adapter, > do I have to factor in bigger losses there (maybe because PCI > passthrough doesn''t support the full PCIe 16x speed)? Has anyone > tried something similar yet or am I the first to think this might be > a good idea?No idea what performance you can expect from the graphics passthrough (once, that is, it is available in Xen at all). PCI passthrough should be fairly low overhead but because there are more virtual machines contending for the CPU (and Xen will potentially have to switch virtual machines each time a PCI device needs servicing) you may take some performance hit. Virtualisation always introduces overheads. Xen is fortunate in that these overheads are often very small but you''re definitely going to reduce the *overall throughput* the machine is capable of by doing this. If the overall throughput was more than you needed / used anyhow then this may not actually matter. Still, it''s worth bearing in mind. Instances where you hop over the virtual network within Xen will reduce network performance - again, going through the virtual NIC (and the Linux bridging code) adds overheads. You''re also adding to the number of context switches that your CPU has to do in order to get data in / out of the system, on top of the processing time. Again, this may not actually be that noticeable in your system but it''s worth bearing in mind. Security judgements are very difficult to make. By introducing Xen you''ve actually *increased* the size of the Trusted Computing Base - code which you rely upon being secure in order to protect your system. Equally well, you''ll have put up some harder partitions between components of your system which may help you. Of course, if you do all your internet browsing and file editing in your Desktop VM then maybe that''s the only one whose security is really critical - in which case you wouldn''t have changed that much! Splitting up your system like this *may* eventually (when all the support in Xen is there and you have the appropriate hardware) make things more flexible for you - e.g. ability to do 3D stuff in Vista whilst running a Linux Myth backend on the same system. That''s something that you just can''t do without some sort of virtual machine layer. And you''re able to contain administrator mistakes, kernel panics, etc that may occur in any one virtual machine (though typically these are rare, one hopes!). I guess what I''m saying is "Yes, you can do that, yes it may work well. Security benefits debatable but you *may* be more robust to certain problems and able to do some really cool stuff." Other things you could consider, which may work out simpler / cheaper or not: 1) run Windows as primary OS and either - can you run Myth on Windows? - separate router box? - run non-hardware-dependent Linux stuff either in a conventional virtual machine system or look at using CoLinux (http://colinux.org/) 2) Run Linux as primary OS and maybe look into using OpenVZ (http://openvz.org/) to partition different Linux-based workloads within the system. You''d need to dual-boot to Windows, or have a separate machine. Still, you could shut that machine down entirely when not using it, the Linux box could perhaps be lower power. 3) Bear in mind that there are other Open Source virtualisers, although I don''t think any others will do PCI passthrough for you. There are various approaches - other than PCI passthrough - to accelerated 3D graphics in guest VMs being worked on or starting to be available currently, both for Xen and for other virtualisers.> I hope someone can give me an answer or at least a hint on how far I > am from reality. > Thanks,I hope my comments help a bit. Sorry for rambling :-) Cheers, mark -- Push Me Pull You - Distributed SCM tool (http://www.cl.cam.ac.uk/~maw48/pmpu/) _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi again, Thanks Chris, this sounds very promising. If I run into any problems, I will take you up on your offer. For now I am still in the planning stage for this project of mine, which by the way proves to be much more work than I initially thought. Thanks alot for the hint about IOMMU, Todd, I think you nailed the main problem I am facing, my initial thoughts were that as long as only one DomU has exclusive rights to a certain PCI device, it would not pose a threat to the entire system. 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. 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. 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? 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? I hope someone can help me out of my confusion, Paul. - -- Paul Schulze avlex@gmx.net Public Key: http://solaris-net.dyndns.org/keys/key_avlex.asc "Making mistakes is human, but to really fuck things up you need Computers" Am 24.05.2008 um 14:35 schrieb Christopher Isip:> > > On Fri, May 23, 2008 at 11:57 PM, Todd Deshane <deshantm@gmail.com> > wrote: > Hi Paul, > > I''m not going to answer all your questions since I don''t have a lot of > experience with many of the things you mention. However I can do > the second part and give some hints on what I do know. > > > Is that possible and am I really gaining security for the whole > system or is > > this just my imagination and doesn''t make any sense at all? How > about the > > performance, especially for the graphics adapter, do I have to > factor in > > bigger losses there (maybe because PCI passthrough doesn''t > support the full > > PCIe 16x speed)? Has anyone tried something similar yet or am I > the first to > > think this might be a good idea? > > For PCI passthrough to be secure you need a system that has an > IOMMU. It is > my understanding that the only IOMMUs that are currently available > are in the > Intel VT-d systems. The reason you need the IOMMU is that otherwise > the > domain that you give direct access to the physical device could DMA > into > main memory and compromise the security of the system. > > So, you first need to look for a system with an IOMMU. > > I really like you explanation of what you want and what you are > trying to > accomplish, I believe you are right on in terms of the VGA > passthrough and > using serial for the Xen output instead. I have read the > experiences of others > for that case and it seems that part you could do. > > People have also reported using Xen and mythTV, so I think that is > also > quite possible. > > There are a lot of details to get right, but by the sounds of it > you are willing > to figure them and make things work. As for all the networking > stuff Xen is > pretty good at that already and it will be a matter of setting it up. > > Your biggest initial hurdle is the IOMMU. Take a look at the VT-d > stuff there > is a lot going on with that on the xen mailing lists. (try > xen.markmail.org if > you haven''t already, it has pretty good search). > > You can find information on some of the other things as well, but I > would > expect that within the next few days others would share their > experiences > on some of the items that you mentioned. > > Cheers, > Todd > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users > > > I am currently running a mythtv backend in a Xen domU. It seems to > be working well. I am on the last stages of configuration. Its > using Ubuntu Hardy. Since it is a 2.6.24 kernel (compared to my > Dom0 2.6.18), there are far fewer DMA errors. > > Some issues that I haven''t resolved yet: > mythfilldatabase segfault in dmesg ( runs fine on command line) > PVR 250/500 record at default bitrate (2.2 Gb an hour) as opposed > to settings in the database. > > The domU does not have a mysql server. This is still in dom0 but I > will be moving that to its own domU next. It also nfs mounts the > video directories from dom0. I like to keep my DomUs at 4 Gigabyte > or less for easy backup to a DVD. > > > If you need help setting up your mythtv DomU, let me know. > > Chris > > >-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFIOJCaYDWOGtiChoARAg7OAJ9AndUfRxJ0ry4Hw1TBNYTpD49JrQCdHxef trWM+6qHbE7NolGi8jwkc38=W9mE -----END PGP SIGNATURE----- _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> 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@lists.xensource.com http://lists.xensource.com/xen-users
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@cl.cam.ac.uk>
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@lists.xensource.com
> http://lists.xensource.com/xen-users
>
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
By the way, make sure to run the mythtv domU first before any other domU''s. Chris On 5/24/08, Christopher Isip <cmisip@gmail.com> 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@cl.cam.ac.uk> 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@lists.xensource.com >> http://lists.xensource.com/xen-users >> >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Mark, Am 25.05.2008 um 02:22 schrieb Mark Williamson:>> 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...Thats a good question, as low as possible. For the platform I am currently working on that means something around 50W, 70W at the most when "idling" (might sound a little too enthusiastic, but its the general target). I assume that most of the tasks I give it will leave the machine more or less idling (below 10% on the CPU), even virtualized, which only works with a CPU with enough power, so it can clock down if the full speed isn''t needed. The low power requirement practically disqualifies anything without onboard graphics, since the system has to deal with at least 2 HDDs and the network and wifi hardware, not to mention the TV tuner card. I had a look at the X3500 IGP on Intels new chipset, but it seems like it still is no alternative to the AMD 780G and I strongly suspect the nForce780a chipset to not support VT-d (besides it being not available for Intel CPUs at the moment). The requirements for extension slots practically dismiss all the available mainboards for mobile Intel CPUs, since those are either MicroATX or ITX too. I would really have prefered an Intel CPU, but the current situation doesnt offer much of a choice.> 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?And there is the problem, I want one box that can handle it all, because first of all, two boxes are more expensive and second of all, if I need the desktops power over night, it will still have to run, ultimately leaving me with two maschines worth of power drawn and noise produced. In my opinion, for this case a single system can meet the requirements perfectly well and scales better for this kind of application. Intel''s Atom CPU is out of the question though, It will probably not be able to handle all the services I would require from the platform at peek times. That includes HDTV decoding and reencoding for possible MythTV clients (3 at the moment), which alone would more or less kill the whole system. Having this part handled by the Desktop system is impractical too, because whomever wants to use the MythTV server over network would have to turn on the Desktop first (and the current server provides resources for people outside my apartment too... and sucks power like crazy doing it because of a defect, which is why its going to be replaced).>> 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 rather wouldn''t, but the alternatives in form of performance combined with low power consumption are less compelling and if it comes down to it, it is supposed to be a multimedia and home server. However, if possible, I would still like to close security holes, especially for the Firewall and Access Point VM (which is probably the most critical part).>> 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 > 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 know what you mean, I am only guessing here too. And I will probably have to stake a whole system on that guess unless another solution pops up. It will be a real pain to secure the VMs though.>> 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.It does, and don''t worry, I wasn''t looking for an ideal answer anyways. If that would exist, the whole project wouldn''t interest me at all :) . Besides, if there were a simple way, we would have linux distros for sandboxed multimedia systems already. It really wouldn''t be fun that way. Thanks again, Paul. - -- Paul Schulze avlex@gmx.net Public Key: http://solaris-net.dyndns.org/keys/key_avlex.asc "Making mistakes is human, but to really fuck things up you need Computers"> Cheers, > Mark > > -- > Push Me Pull You - Distributed SCM tool (http://www.cl.cam.ac.uk/ > ~maw48/pmpu/)-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFION3MYDWOGtiChoARArzSAJ495Qz/LgLA0nvfoY2eoYmLg96F2gCfY/1n YukeMvDhI5KVEIOBBMrGp6g=qIY3 -----END PGP SIGNATURE----- _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users