[vfio-users] GPU passthrough to Windows problem: BOOT_DEVICE_INACCESSIBLE & general questions on passing physical disks

[Eric Hattemer]

On 10/30/2015 01:43 PM, Benjamin Slade wrote:
> Why is passing a physical drive not a good solution?  Part of the reason
> I wanted to do it like that was to allow for the option of dual booting.

I don't think there's anything wrong with that.  If you want to do it 
that way, more power to you.  I was doing that for a while, but my plan 
has always been to get my Windows VM so stable and awesome I never want 
to boot straight into Windows again.  I'm also interested in storage 
management, and Windows is absolutely garbage about that, in terms of 
things like volume snapshots, backups, ramdisks, multiple copy policies, 
etc.  So I'm using qcow2 now.  But if managing qcow2 images in 
interesting ways with snapshots and prefetching filesystem caches and 
other cool stuff isn't as compelling to you as being able to boot 
directly into Windows, then you should keep Windows on a primary partition.

Personally I ran into a number of problems and confusion with libvirt 
and switched to doing raw qemu as root.  I'd like to use libvirt again, 
but just getting qemu working was a bit of an effort and I didn't want 
to wonder at each milestone whether I was having a qemu problem or a 
libvirt problem.  I never did solve the problem with libvirt and vfio on 
Fedora 22.  It was getting permission denied on /dev/vfio/*, so I 
chmodded those.  But now it hits a different error when issuing ioctl's 
or something against those.  I think maybe it has to do with locked 
memory or some other limit, but I cranked up everything from ulimit into 
/etc/security/limits.d, so I don't know what's left.  I think I'll have 
to turn on verbose limits.d logging in the kernel if I can remember how 
to do that.  I don't even know what user libvirtd runs as...  So my plan 
was to get sudo qemu working, then translate those settings into a 
virt-manager profile, using qemu:commandline only when necessary.

-Eric Hattemer