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

Fri Oct 30 21:58:21 UTC 2015

here you are my xml for win 8.1.

I'm actually working on my wrapper script to clean as much as possible xml
definition.

<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
  <name>win8.1</name>
  <uuid>6efc8a3c-5c45-4d51-9fc6-a086d3e267b2</uuid>
  <memory unit='KiB'>4194304</memory>
  <currentMemory unit='KiB'>4194304</currentMemory>
  <vcpu placement='static'>2</vcpu>
  <os>
    <type arch='x86_64' machine='pc-i440fx-2.5'>hvm</type>
    <loader readonly='yes'
type='pflash'>/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd</loader>
    <nvram>/var/lib/libvirt/qemu/nvram/win8.1_VARS.fd</nvram>
    <bootmenu enable='yes'/>
  </os>
  <features>
    <acpi/>
    <apic/>
    <pae/>
    <hyperv>
      <relaxed state='on'/>
      <vapic state='on'/>
      <spinlocks state='on' retries='8191'/>
    </hyperv>
    <kvm>
      <hidden state='on'/>
    </kvm>
  </features>
  <cpu mode='custom' match='exact'>
    <model fallback='allow'>Haswell</model>
  </cpu>
  <clock offset='localtime'>
    <timer name='rtc' tickpolicy='catchup'/>
    <timer name='pit' tickpolicy='delay'/>
    <timer name='hpet' present='no'/>
    <timer name='hypervclock' present='yes'/>
  </clock>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>restart</on_crash>
  <pm>
    <suspend-to-mem enabled='no'/>
    <suspend-to-disk enabled='no'/>
  </pm>
  <devices>
    <emulator>/usr/sbin/qemu-system-x86_64</emulator>
    <disk type='block' device='disk'>
      <driver name='qemu' type='raw' cache='none' io='threads'/>
      <source dev='/dev/mapper/vgSSD-logicSSD'/>
      <target dev='vda' bus='virtio'/>
      <boot order='3'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04'
function='0x0'/>
    </disk>
    <disk type='block' device='disk'>
      <driver name='qemu' type='raw' cache='none' io='threads'/>
      <source dev='/dev/mapper/vgData-logicVirtual'/>
      <target dev='vdb' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x07'
function='0x0'/>
    </disk>
    <controller type='usb' index='0' model='ich9-ehci1'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05'
function='0x7'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci1'>
      <master startport='0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05'
function='0x0' multifunction='on'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci2'>
      <master startport='2'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05'
function='0x1'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci3'>
      <master startport='4'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05'
function='0x2'/>
    </controller>
    <controller type='pci' index='0' model='pci-root'/>
    <controller type='ide' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01'
function='0x1'/>
    </controller>
    <interface type='network'>
      <mac address='52:54:00:76:8a:69'/>
      <source network='default'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03'
function='0x0'/>
    </interface>
    <serial type='pty'>
      <target port='0'/>
    </serial>
    <console type='pty'>
      <target type='serial' port='0'/>
    </console>
    <input type='tablet' bus='usb'/>
    <input type='mouse' bus='ps2'/>
    <input type='keyboard' bus='ps2'/>
    <graphics type='vnc' port='-1' autoport='yes'/>
    <video>
      <model type='vga' vram='16384' heads='1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02'
function='0x0'/>
    </video>
    <hostdev mode='subsystem' type='pci' managed='yes'>
      <source>
        <address domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
      </source>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x08'
function='0x0'/>
    </hostdev>
    <hostdev mode='subsystem' type='pci' managed='yes'>
      <source>
        <address domain='0x0000' bus='0x01' slot='0x00' function='0x1'/>
      </source>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x09'
function='0x0'/>
    </hostdev>
    <memballoon model='virtio'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06'
function='0x0'/>
    </memballoon>
  </devices>
  <qemu:commandline>
    <qemu:arg value='-cpu'/>
    <qemu:arg value='host,hv_vendor_id=deadbeef,kvm=off'/>
  </qemu:commandline>
</domain>

2015-10-30 22:09 GMT+01:00 Eric Hattemer <hattenator at gmail.com>:

> 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
>
>
> _______________________________________________
> vfio-users mailing list
> vfio-users at redhat.com
> https://www.redhat.com/mailman/listinfo/vfio-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/vfio-users/attachments/20151030/ac8bc332/attachment.htm>