On Sat, 2012-06-09 at 02:00 +0200, Andreas Hartmann wrote: > Alex Williamson wrote: > > On Fri, 2012-06-08 at 19:39 +0200, Andreas Hartmann wrote: > >> Andreas Hartmann wrote: > >>> Hello Alex, > >>> > >>> You can probably say, what this message on host side means: > >>> > >>> kernel: [ 3902.124109] vfio_dma_do_map: RLIMIT_MEMLOCK (65536) exceeded > >>> > >>> The WLAN card in the VM doesn't work any more. It came up after a few > >>> times of restarting the VM (with unbinding / rebinding - procedures). > >>> > >>> I'll see if it is reproducible. I had to reboot to get it working again. > >> > >> It is reproducible. And id seems not to be a problem of binding / > >> unbinding, but the fact of not starting it as root user seems to be the > >> problem. > >> > >> I never saw these problems with a root VM (and root does have the same > >> value for ulimit -l). > > > > Yes, this is expected when running as non-root. VFIO needs to lock > > pages on behalf of the user, so the user needs limits granted to be able > > to do that. Otherwise a VFIO user could lock down all the memory in the > > system. > > > >> - Is it possible to run the VM / VFIO in user context? > > > > Yes, this is one of the key design requirements of VFIO. > > Pre-requirements are that a privileged entity has sequestered all the > > devices as being owned by vfio-pci or pci-stub, the user has permissions > > to /dev/vfio/<group#> and /dev/vfio/vfio (the latter is expected to be > > safe to leave as 0666), and the user has limits set to lock pages > > sufficient for what they need (note that the default of 64k might be > > enough for some userspace driver applications). > > I already read about the permissions, but I wasn't aware, that I have to > set the max locked memory for the user. > > I set it to 512 MB (for a VM with 256 MB plus some overhead) for the > beginning. It most probably could be reduced. > > >> - What size should be used for ulimit -l? > > > > It should be about the size of memory assigned to the guest. > > Thanks for this hint! 64k is definitely not enough for my VM :-). > > > Once we have libvirt support, all of this should be relatively > > transparent as that will take care of the limits setting. > > If you are aware of it, it's no problem ... . > > > For now, it's > > a bit of a pain running it as a normal user. > > Not that much. It's good to become an understanding of what is going on. > > > If you come up with an > > easy way of doing it, please share. > > I don't know, if it's easy, but it's straight forward and working: > > 1. define a user for running the VM. > 2. create a VM for virsh (xml-File) > libvirt has the ability to freely define parameters for qemu. That's > the way I enabled libvirt to support VFIO: > > <domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'> > ... > <devices> > ... > </devices> > <qemu:commandline> <!-- instead of hostdev ... --> > <qemu:arg value='-device'/> > <qemu:arg value='vfio-pci,host=06:07.0'/> > <!-- <qemu:env name='QEMU_ENV' value='VAL'/> --> > </qemu:commandline> > </domain> > > 3. set max locked memory limit in /etc/security/limits.conf (PAM). > 4. write a small start script which contains the bindings and the start > of the VM as root with > su user -c "virsh start VM" > Don't forget to increase the max locked memory before virsh start if > the default size is less than the desired size for the VM. > 5. write a small stop script to shutdown the VM with > su user -c "virsh shutdown VM" and free the devices again. > > The start / stop scripts could be put to sudo to enable a user without > root authorization to start the VM. You can even start it with an icon > with your favourite GUI if you want to (women acceptance factor). > > > BTW: > During playing around (yes, it was my fault), I accidentally tried to > free the devices though the VM still has been running. Vfio wasn't that > happy about this accident :-) : > > > Jun 9 01:01:49 host kernel: [20108.859106] ------------[ cut here ]------------ > Jun 9 01:01:49 host kernel: [20108.859117] kernel BUG at /rpm/BUILD/kernel-desktop-3.4.1/linux-3.4/drivers/vfio/vfio.c:574! This is actually an intentional BUGON to catch just the sort of thing you did. This happens if the group is in use and one of the devices in the group is re-bound to something other than pci-stub or vfio-pci. Basically, the system has gone to a non-secure state, with kernel owned devices and user owned devices in the same active group. I'll probably end up attempting to kill the user process when this occurs, but for now it's just a BUGON. Thanks, Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
