You are not logged in.
I have been searching abit in this forum and on aw's vfio blog faq. When going through the talking points you had aw i got the impression that if i switch to using OVMF and UEFI on my windows8.1 guest, the vga arbiter issue with Nvidia proprietary host drivers is a non issue (your faq question 9) and i can install and use the nvidia driver on the host without patching?
Sorry if this question has been answered before i just had a hard time finding the answer that looked obvious from your talking points "VFIO, OVMF, GPU, and You ".
It's my understanding that this is true. The problem with the nvidia proprietary driver on the host is that it takes the VGA arbiter lock and never releases it. The expected usage model for the VGA arbiter is that the lock is held only while accesses to the legacy VGA space are being used. The lock is then released allowing other users of the arbiter a chance to acquire the lock and perform their access. This is how pseudo-concurrent VGA access works with multiple VGA assignment VMs. Therefore, so long as our VM is not performing VGA accesses, which can be enforced by disabling CONFIG_VFIO_PCI_VGA (or a vfio-pci module option I intend to add), there is no need to patch the host nvidia driver to prevent VGA locking.
Note however that while OVMF generally implies legacy-free, there is a legacy compatibility module, the CSM, available in some OVMF builds. The CSM will potentially do legacy VGA accesses and put you back in the position of needing to patch host drivers for VGA arbitration. You therefore want to make use of the "pure" version of OVMF to avoid this. On Fedora, the OVMF file to use is /usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd (avoid the "with-csm" versions). Your builds may name them differently.
http://vfio.blogspot.com
Looking for a more open forum to discuss vfio related uses? Try https://www.redhat.com/mailman/listinfo/vfio-users
Offline
I havent that good CPU Performance in Win8.1 using -smp 8,sockets=1,cores=4,threads=2 with my 4970k@4,6GHz so I saw Pin vcpu to pcpu in first post but this site seems to be do offline.
Can someone help me with that?
Specifying a CPU topology with threads is generally only recommended in combination with pinning. Using 100% of the host CPU resources for a guest is also likely to cause glitches when the host needs some CPU resources. There's plenty of information online for vCPU pinning. libvirt can do this for you and is detailed on their site.
http://vfio.blogspot.com
Looking for a more open forum to discuss vfio related uses? Try https://www.redhat.com/mailman/listinfo/vfio-users
Offline
PureTryOut wrote:I've seen this too (no need to patch host drivers if you're using OVMF). Sadly I have no clue how to make it work though.
From what I've read you should launch Qemu withqemu-system-x86_64 -L .
This while being in the directory where the UEFI bios.bin is in.
Well tried that, it did nothing, not even give me an UEFI shell.Is there a proper guide to OVMF in Qemu out there that we can use?
Assuming you're on arch:
Get OVMF-svn, build an install it.
Then launch qemu like this:
qemu-system-x86_64 -enable-kvm -m 1024 -cpu host,kvm=off -smp 2,sockets=1,cores=2,threads=1 \ -drive if=pflash,format=raw,readonly,file=/usr/share/ovmf/x64/ovmf_code_x64.bin \ -drive if=pflash,format=raw,file=/usr/share/ovmf/x64/ovmf_vars_x64.bin \ -device vfio-pci,host=07:00.0 -device vfio-pci,host=07:00.1 \ -vga none
Yes i'm on Arch
Well without -"vga none", it at least drops me in the EFI shell now which it didn't before, so that's progress.
Sadly now with -"vga none" added again it only shows me the "compat_monitor0 console" again...
I seriously don't understand what i'm missing here...
Offline
nbhs wrote:PureTryOut wrote:I've seen this too (no need to patch host drivers if you're using OVMF). Sadly I have no clue how to make it work though.
From what I've read you should launch Qemu withqemu-system-x86_64 -L .
This while being in the directory where the UEFI bios.bin is in.
Well tried that, it did nothing, not even give me an UEFI shell.Is there a proper guide to OVMF in Qemu out there that we can use?
Assuming you're on arch:
Get OVMF-svn, build an install it.
Then launch qemu like this:
qemu-system-x86_64 -enable-kvm -m 1024 -cpu host,kvm=off -smp 2,sockets=1,cores=2,threads=1 \ -drive if=pflash,format=raw,readonly,file=/usr/share/ovmf/x64/ovmf_code_x64.bin \ -drive if=pflash,format=raw,file=/usr/share/ovmf/x64/ovmf_vars_x64.bin \ -device vfio-pci,host=07:00.0 -device vfio-pci,host=07:00.1 \ -vga none
Yes i'm on Arch
Well without -"vga none", it at least drops me in the EFI shell now which it didn't before, so that's progress.
Sadly now with -"vga none" added again it only shows me the "compat_monitor0 console" again...
I seriously don't understand what i'm missing here...
You're supposed to get output on the monitor connected to your secondary gpu, that black console doesnt matter, make sure your hdmi/dvi cables are ok
Offline
Hmm, any idea how can I share CPU between two guest, assuming that CPU load is equal to 100% on both guests and host:
Max allowed CPU usage for guest#1 - 40%
-- for guest#2 - 40%
-- for host - 20%when guest#1 load is low, guest#2 is getting up to 80% of CPU usage and vice versa, host - always 20%.
Is this possible?
Also same thing, but with RAM.
I havent that good CPU Performance in Win8.1 using -smp 8,sockets=1,cores=4,threads=2 with my 4970k@4,6GHz so I saw Pin vcpu to pcpu in first post but this site seems to be do offline.
Can someone help me with that?
First get cpuset, (Arch pkg: cpuset.tar.gz) and set up huge pages as described here, also read http://www-01.ibm.com/support/knowledge … roctop.htm and http://wiki.qemu.org/QMP
i have an 8 core amd cpu, 16GB of ram and i want to achieve something like this:
VM1 running on cores 5-7 @ 6144MB
VM2 running on cores 2-4 @ 6144MB
I want my system task running on unused system cores @ 4GB
Create a "system" cpuset running on all cores [0-7]
cset set -c 0-7 -s system
cset: --> created cpuset "system"
Move all processes from the root cpuset to the new system cpuset
cset proc -m -f root -t system
cset: moving all tasks from root to /system
cset: moving 289 userspace tasks to /system
[==================================================]%
cset: done
We want to launch VM1 on cores [5-7] (5,6,7)
So we modify the "system" cpuset and reduce our cores dedicated to systems tasks from [0-7] to [0-4]
cset set -c 0-4 -s system
cset: --> modified cpuset "system"
Create a new cpuset called "VM1" for cores [5-7]
cset set -c 5-7 -s VM1
cset: --> created cpuset "VM1"
Launch qemu, as described on http://wiki.qemu.org/QMP, on cpuset "VM1"
cset proc -s VM1 -e -- qemu-system-x86_64 -enable-kvm -cpu host -smp 3,sockets=1,cores=3,threads=1 -m 6144 -mem-path /dev/hugepages/ (...) -qmp unix:./qmp-vm1,server,nowait
cset: --> last message, executed args into cpuset "/VM1", new pid is: 1950
Query the vcpu thread ids
echo "{ \"execute\": \"qmp_capabilities\" }" "{ \"execute\": \"query-cpus\" }" | socat UNIX-CONNECT:./qmp-vm1 STDIO | awk 'NR>1{print $1}' FS=} RS='"thread_id": '
2039
2040
2041
Use taskset to pin vcpu-pcpu
taskset -pc 5 2039
taskset -pc 6 2040
taskset -pc 7 2041
Once we're done with our vm we destroy our VM1 cpuset
cset set -d VM1
cset: --> processing cpuset "VM1", moving 0 tasks to parent "/"...
cset: --> deleting cpuset "/VM1"
cset: done
Modify the "system" cpuset back to [0-7] affinity
cset set -c 0-7 -s system
cset: --> modified cpuset "system"
Do the same for VM2
Comments? Advice?
Last edited by nbhs (2015-03-08 02:16:15)
Offline
You're supposed to get output on the monitor connected to your secondary gpu, that black console doesnt matter, make sure your hdmi/dvi cables are ok
See that explains things. I had no clue that I had to had a display connected to my GPU. I thought it would just boot in the window that popped up. I guess i'll have to get an extra monitor then...
I've plugged in an left-over screen for now in the HDMI port of my GTX 770 (which is want I want to use for the passthrough).
Now it gives me the following error:
qemu-system-x86_64: -device vfio-pci,host=02:00.0: vfio: Error: Failed to setup INTx fd: Device or resource busy
Offline
nbhs wrote:You're supposed to get output on the monitor connected to your secondary gpu, that black console doesnt matter, make sure your hdmi/dvi cables are ok
See that explains things. I had no clue that I had to had a display connected to my GPU. I thought it would just boot in the window that popped up. I guess i'll have to get an extra monitor then...
I've plugged in an left-over screen for now in the HDMI port of my GTX 770 (which is want I want to use for the passthrough).Now it gives me the following error:
qemu-system-x86_64: -device vfio-pci,host=02:00.0: vfio: Error: Failed to setup INTx fd: Device or resource busy
Offline
nbhs wrote:You're supposed to get output on the monitor connected to your secondary gpu, that black console doesnt matter, make sure your hdmi/dvi cables are ok
See that explains things. I had no clue that I had to had a display connected to my GPU. I thought it would just boot in the window that popped up. I guess i'll have to get an extra monitor then...
I've plugged in an left-over screen for now in the HDMI port of my GTX 770 (which is want I want to use for the passthrough).Now it gives me the following error:
qemu-system-x86_64: -device vfio-pci,host=02:00.0: vfio: Error: Failed to setup INTx fd: Device or resource busy
You cannot assign individual video output ports on your graphics cards, it's all or none, the whole card or not. Also make sure your VM isn't actually running already.
Offline
Lol as much as I would love that to work, it didn't...
After rebooting, Arch wouldn't detect my second GPU at all anymore.
Not with PCI (dmesg | grep pci-stub), and not with lspci.
Unplugged the display from the secondary GPU and rebooted, it booted fine.
Offline
nbhs wrote:Lol as much as I would love that to work, it didn't...
After rebooting, Arch wouldn't detect my second GPU at all anymore.
Not with PCI (dmesg | grep pci-stub), and not with lspci.
Unplugged the display from the secondary GPU and rebooted, it booted fine.
Do you really expect us to debug your hardware issues?
http://vfio.blogspot.com
Looking for a more open forum to discuss vfio related uses? Try https://www.redhat.com/mailman/listinfo/vfio-users
Offline
Do you really expect us to debug your hardware issues?
What? No, of course not! Look you guys seem to get irritated with me, and I can understand that.
However that is not what I want to do.
If this is a hardware issue then sorry, I had no clue. I have a fair bit of Linux and CLI knowledge but this is completely new to me. I'm have been trying to make this work for a while now, and even replaced my CPU and motherboard so they both would support VT-d... I get irritated with it not working myself too. Even though i'm faced with new errors each time I have a bit of progress, i'm not giving up as it is something I want to learn and have working to get rid of the dual-boot.
If you guys are not interested in helping me anymore, then please say so, I will search for solutions myself. I'm really sorry for bothering you guys with all of this, but like I said before, I really really want this to work.
Offline
aw wrote:Do you really expect us to debug your hardware issues?
What? No, of course not! Look you guys seem to get irritated with me, and I can understand that.
However that is not what I want to do.If this is a hardware issue then sorry, I had no clue. I have a fair bit of Linux and CLI knowledge but this is completely new to me. I'm have been trying to make this work for a while now, and even replaced my CPU and motherboard so they both would support VT-d... I get irritated with it not working myself too. Even though i'm faced with new errors each time I have a bit of progress, i'm not giving up as it is something I want to learn and have working to get rid of the dual-boot.
If you guys are not interested in helping me anymore, then please say so, I will search for solutions myself. I'm really sorry for bothering you guys with all of this, but like I said before, I really really want this to work.
Sorry, I kind of blew a gasket at seeing that you weren't even expecting output from the graphics card itself, which is covered in the first post here and should be evident from any of the videos you can find of this working. I suggest you actually try to understand the setup rather than blindly following your interpretation of the instructions and reporting the latest failures with minimal information. If you ask informed and direct questions, I'll be happy to try to help. If you don't understand something about the setup, ask rather than pushing forward with error reports.
http://vfio.blogspot.com
Looking for a more open forum to discuss vfio related uses? Try https://www.redhat.com/mailman/listinfo/vfio-users
Offline
I've seen this too (no need to patch host drivers if you're using OVMF). Sadly I have no clue how to make it work though.
From what I've read you should launch Qemu withqemu-system-x86_64 -L .
This while being in the directory where the UEFI bios.bin is in.
Well tried that, it did nothing, not even give me an UEFI shell.Is there a proper guide to OVMF in Qemu out there that we can use?
You should first check if your card supports EFI: http://vfio.blogspot.com/2014/08/does-m … t-efi.html
And assuming you have read this tread you will understand this guide: http://vfio.blogspot.com/2014/08/primar … t-vga.html
Offline
Just in case anyone has the same issue, I was running Win 7 under Slackware with qemu 2.1.0 using the command line and migrated to Arch. For some reason, the VM bluescreened on a HDD error only when passing through the graphics output. Finally got it working with a change in the script. Old version:
-enable-kvm -M q35 -m 8192 \
-cpu host,hv-time,hv_relaxed,hv_vapic,hv_spinlocks=0x1000 -smp 6,sockets=1,cores=6,thre$
-bios /usr/share/qemu/bios.bin -vga none -nographic \
-device ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root.1 \
-device vfio-pci,host=03:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on \
-device vfio-pci,host=03:00.1,bus=root.1,addr=00.1 \
-drive file=/dev/mapper/cryptvg2-win7,id=disk,if=virtio \
-device piix4-ide,bus=pcie.0,id=piix4-ide \
-drive file=/dev/cdrom,id=cddisk -device ide-cd,bus=piix4-ide.1,drive=cddisk \
-net vde,sock=/var/run/kvm0.ctl,vlan=0 -net nic,vlan=0,macaddr=XX:XX:XX:XX:00:01,model=virtio \
-device ich9-intel-hda,bus=pcie.0,addr=1b.0,id=sound0 \
-device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 \
-rtc base=localtime \
-monitor unix:/home/user/monitor,server,nowait
(Note that Slackware needs the sock=/var/run/kvm0.ctl,vlan=0, omitted for Arch)
-enable-kvm -rtc base=localtime \
-m 8192 -mem-path /dev/hugepages -smp 6,sockets=1,cores=6,threads=1 \
-cpu host,hv-time,hv_relaxed,hv_vapic,hv_spinlocks=0x1000 \
-vga none -nographic \
-monitor stdio -serial none -parallel none \
-nodefconfig \
-device intel-hda -device hda-output \
-drive file=/dev/mapper/cryptvg2-win7,cache=none,if=none,id=drive0,aio=threads \
-device virtio-blk-pci,drive=drive0,ioeventfd=on,bootindex=1 \
-device vfio-pci,host=0000:03:00.0,multifunction=on,addr=9.0,x-vga=on \
-device vfio-pci,host=0000:03:00.1,addr=9.1
-drive file=/dev/sr0,if=none,id=drive-ide0-0-0,readonly=on,format=raw -device ide-cd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 \
-net vde -net nic,vlan=0,macaddr=XX:XX:XX:XX:00:01,model=virtio \
-monitor unix:/home/user/monitor,server,nowait \
The extra parameters on the lines
-drive file=/dev/mapper/cryptvg2-win7,cache=none,if=none,id=drive0,aio=threads \
-drive file=/dev/sr0,if=none,id=drive-ide0-0-0,readonly=on,format=raw -device ide-cd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 \
were absolutely necessary in order to get the CD/DVD drive and the HDD working. Oddly enough the change to 440fx required a reactivation but caused no other problems... but I lost my desktop background for some reason.
Last edited by mostlyharmless (2015-03-07 19:10:04)
Offline
Is this the right place to ask questions? I cant really get it to run.
no errors up until I tried to run it the first time.
qemu-system-x86_64: -device vfio-pci,host=01:00.0,x-vga=on: vfio: error no iommu_group for device
qemu-system-x86_64: -device vfio-pci,host=01:00.0,x-vga=on: Device initialization failed.
qemu-system-x86_64: -device vfio-pci,host=01:00.0,x-vga=on: Device 'vfio-pci' could not be initialized
The binding process seems to work or at least, no errors.
dmesg output:
[ 0.000000] Command line: initrd=\initramfs-linux-missingacs-i915arbiter.img cryptdevice=UUID=f68cbc3f-37b1-46a1-8214-9d38bdd55453:root root=UUID=d4a843e2-ee3b-4c3e-8369-10e96f2f8b30 rootflags=subvol=BTRFSROOT/root quiet ro rw i915.enable_hd_vgaarb=1 pci-stub.ids=1002:6798,1002:aaa0 intel_iommu=on vfio_iommu_type1.allow_unsafe_interrupts=1
[ 0.000000] Kernel command line: initrd=\initramfs-linux-missingacs-i915arbiter.img cryptdevice=UUID=f68cbc3f-37b1-46a1-8214-9d38bdd55453:root root=UUID=d4a843e2-ee3b-4c3e-8369-10e96f2f8b30 rootflags=subvol=BTRFSROOT/root quiet ro rw i915.enable_hd_vgaarb=1 pci-stub.ids=1002:6798,1002:aaa0 intel_iommu=on vfio_iommu_type1.allow_unsafe_interrupts=1 pcie_acs_override=downstream
[ 0.456140] pci-stub: add 1002:6798 sub=FFFFFFFF:FFFFFFFF cls=00000000/00000000
[ 0.456154] pci-stub 0000:01:00.0: claimed by stub
[ 0.456162] pci-stub: add 1002:AAA0 sub=FFFFFFFF:FFFFFFFF cls=00000000/00000000
[ 0.456170] pci-stub 0000:01:00.1: claimed by stub
Hardware is:
i5 3570k
gigabyte z77 ud3h vt-d enabled
sapphire 7970 ghz edition
Has anyone got this working with the same or similar hardware and/or can help?
Offline
Your cpu = Intel® Virtualization Technology for Directed I/O (VT-d) = NO
Offline
Your cpu = Intel® Virtualization Technology for Directed I/O (VT-d) = NO
http://vfio.blogspot.com
Looking for a more open forum to discuss vfio related uses? Try https://www.redhat.com/mailman/listinfo/vfio-users
Offline
hmmh thanks. I thought it supported it since it was in the bios options
EDIT: can someone please tell me why the 3570 supports vt-d but the 3570k doesnt ? How does this make any sense ?
Last edited by giantegg (2015-03-07 20:02:49)
Offline
Sorry, I kind of blew a gasket at seeing that you weren't even expecting output from the graphics card itself, which is covered in the first post here and should be evident from any of the videos you can find of this working.
Well I can understand that, however I have not read this anywhere in this thread. Looking back I can still not find where it says that, but i'm probably just blind. Doesn't matter anyway, I know now.
I suggest you actually try to understand the setup rather than blindly following your interpretation of the instructions and reporting the latest failures with minimal information.
The thing is, I am trying to understand it, and i'm actually understanding it more and more.
This is my way of learning, I can't help it...
If you ask informed and direct questions, I'll be happy to try to help. If you don't understand something about the setup, ask rather than pushing forward with error reports.
I actually thought I was doing this, but clearly not. Sorry for that...
Anyways you'll be happy to know I finally got it working. Not sure why but it now detected the GPU properly with the monitor plugged in. In the end I didn't need to use OVMF and/or the NVIDIA driver patch.
So for the one that makes that spreadsheet, I run the following:
Host: Arch Linux 3.18.5 kernel with the ACS patch (from the first post), NVIDIA GTX 980
Guest: Windows 8.1, NVIDIA GTX 770
Motherboard: Asrock Extreme 6/ac
CPU: i7 4790k
One last question: is there any way to share the keyboard and mouse between the guest and host? I now just passthrough the specific usb devices, and although this works, I can't do anything in my host anymore until I turn off the VM.
Offline
aw wrote:Sorry, I kind of blew a gasket at seeing that you weren't even expecting output from the graphics card itself, which is covered in the first post here and should be evident from any of the videos you can find of this working.
Well I can understand that, however I have not read this anywhere in this thread. Looking back I can still not find where it says that, but i'm probably just blind. Doesn't matter anyway, I know now.
aw wrote:I suggest you actually try to understand the setup rather than blindly following your interpretation of the instructions and reporting the latest failures with minimal information.
The thing is, I am trying to understand it, and i'm actually understanding it more and more.
This is my way of learning, I can't help it...aw wrote:If you ask informed and direct questions, I'll be happy to try to help. If you don't understand something about the setup, ask rather than pushing forward with error reports.
I actually thought I was doing this, but clearly not. Sorry for that...
Anyways you'll be happy to know I finally got it working. Not sure why but it now detected the GPU properly with the monitor plugged in. In the end I didn't need to use OVMF and/or the NVIDIA driver patch.
So for the one that makes that spreadsheet, I run the following:
Host: Arch Linux 3.18.5 kernel with the ACS patch (from the first post), NVIDIA GTX 980
Guest: Windows 8.1, NVIDIA GTX 770
Motherboard: Asrock Extreme 6/ac
CPU: i7 4790kOne last question: is there any way to share the keyboard and mouse between the guest and host? I now just passthrough the specific usb devices, and although this works, I can't do anything in my host anymore until I turn off the VM.
Try Synergy, alternatively you could passthrough one of your usb controllers, my Case has 2 frontal usb3 ports, and 2 usb2 ports, so i passthrough the usb3 controller to windows and i switch my KB/M by changing the ports they're connected to
Last edited by nbhs (2015-03-07 23:13:46)
Offline
Try Synergy, alternatively you could passthrough one of your usb controllers, my Case has 2 frontal usb3 ports, and 2 usb2 ports, so i passthrough the usb3 controller to windows and i switch my KB/M by changing the ports they're connected to
Well i'm not going to pay for Synergy as good as it may be.
But your other solution is actually pretty smart, i'm going to use that. Thanks for all your help guys!
Offline
nbhs wrote:Try Synergy, alternatively you could passthrough one of your usb controllers, my Case has 2 frontal usb3 ports, and 2 usb2 ports, so i passthrough the usb3 controller to windows and i switch my KB/M by changing the ports they're connected to
Well i'm not going to pay for Synergy as good as it may be.
But your other solution is actually pretty smart, i'm going to use that. Thanks for all your help guys!
Synergy is free and libre afaik
Offline
Specifying a CPU topology with threads is generally only recommended in combination with pinning. Using 100% of the host CPU resources for a guest is also likely to cause glitches when the host needs some CPU resources. There's plenty of information online for vCPU pinning. libvirt can do this for you and is detailed on their site.
Could you elaborate on that? I always assumed the point of cpu pinning was to reserve/restrict cpu usage, regardless of topology. For example to preventing a test vm from stealing resources from a production vm.
The reason I'm asking is that I'm also using threads without pinning. When I first tried kvm with vfio I did some benchmarks(cinebench) and threads=8,cores=1,sockets=1 gave me the best results for a quad-core cpu with ht.
Offline
PureTryOut wrote:nbhs wrote:Try Synergy, alternatively you could passthrough one of your usb controllers, my Case has 2 frontal usb3 ports, and 2 usb2 ports, so i passthrough the usb3 controller to windows and i switch my KB/M by changing the ports they're connected to
Well i'm not going to pay for Synergy as good as it may be.
But your other solution is actually pretty smart, i'm going to use that. Thanks for all your help guys!Synergy is free and libre afaik
It changed recently, you can still get the source and build it yourself, or $10 for lifetime access to binaries. Worth it, IMHO.
http://vfio.blogspot.com
Looking for a more open forum to discuss vfio related uses? Try https://www.redhat.com/mailman/listinfo/vfio-users
Offline
aw wrote:Specifying a CPU topology with threads is generally only recommended in combination with pinning. Using 100% of the host CPU resources for a guest is also likely to cause glitches when the host needs some CPU resources. There's plenty of information online for vCPU pinning. libvirt can do this for you and is detailed on their site.
Could you elaborate on that? I always assumed the point of cpu pinning was to reserve/restrict cpu usage, regardless of topology. For example to preventing a test vm from stealing resources from a production vm.
The reason I'm asking is that I'm also using threads without pinning. When I first tried kvm with vfio I did some benchmarks(cinebench) and threads=8,cores=1,sockets=1 gave me the best results for a quad-core cpu with ht.
Here's an article i found very interesting http://www-01.ibm.com/support/knowledge … nprocs.htm, to restrict or reserve cpu usage i believe you need something like cgroups, see my previous post
Offline