[vfio-users] [Qemu-discuss] vfio pass through only works once after reboot

[Abdulla Bubshait]

And here I thought the problem I was running into was unique to my video
card.

I am running a Radeon R9 Fury X (Fiji) on windows guest (8.1 and 10)  OVMF
and suffer from a very similar issue. On guest reboot the monitor would
stay blank most of the times. The guest would be running fine and I can
verify that by logging into VNC. I am currently in the process of trying to
figure out what is going wrong in the reboot process. At first I thought it
would be an issue similar to the AMD reset issue since I could suspend the
host to get the guest working again, but I am still trying to figure a fix.

I have tried Alex's AMD Reset patch and added the Fiji to the list but it
didn't do anything. I was hoping to update my kernel and patch it to allow
seabios use since the Fiji doesn't have any UEFI code in its rom. I was
pretty confident that would resolve it but after reading your issues with
SeaBIOS as well I am not as confident.

I used to run a GTX 770 and it used to work fine.

I am currently running Linux Mint 17.1, kernel 3.19.3, qemu 2.4

Here is my current startup script

export QEMU_PA_SAMPLES=128
export QEMU_AUDIO_DRV=pa

  #CPU Options
  OPTS="-M pc-i440fx-2.1 -enable-kvm -m 8192 -mem-path /hugepages -smp
4,cores=4,threads=1,sockets=1"
  # DAMMIT NVIDIA
  case $1 in
        hv )  OPTS="$OPTS -cpu
host,kvm=off,hv_relaxed,hv_vapic,hv_time,hv_spinlocks=0x1000" ;;
        *  )  OPTS="$OPTS -cpu host,kvm=off" ;;
  esac


  #UEFI
  OPTS="$OPTS -drive if=pflash,format=raw,file=$HOME/bin/OVMF.fd"

  # The hard disk is exposed to the guest as a virtio-block device. OVMF
has a
  # driver stack that supports such a disk. We specify this disk as first
boot
  # option. OVMF recognizes the boot order specification.
  OPTS="$OPTS -device virtio-scsi-pci,id=scsi"
  OPTS="$OPTS -drive file=/dev/sdb,id=disk_primary,format=raw,if=none"
  OPTS="$OPTS -device scsi-hd,drive=disk_primary,bootindex=0"

  #VFIO Devices
  OPTS="$OPTS -device vfio-pci,host=01:00.0,multifunction=on,x-vga=on"
  OPTS="$OPTS -device vfio-pci,host=01:00.1"
  OPTS="$OPTS -device vfio-pci,host=05:00.0"

  OPTS="$OPTS -net nic -net tap,ifname=tap0,script=no,downscript=no"
  OPTS="$OPTS -rtc base=localtime,clock=host"
  OPTS="$OPTS -vga none"
  OPTS="$OPTS -soundhw hda"

  # The following setting enables S3 (suspend to RAM). OVMF supports S3
  # suspend/resume.
  OPTS="$OPTS -global PIIX4_PM.disable_s3=0"


for i in {2,3,6,7}; do
      echo performance >
/sys/devices/system/cpu/cpu${i}/cpufreq/scaling_governor
done


taskset -ac 2,3,6,7 qemu-system-x86_64 $OPTS


On Fri, Sep 4, 2015 at 7:52 AM Lucas Neves <lcneves at gmail.com> wrote:

> I'm very interested in the solution to this problem as well. I pass
> through a Radeon r9 285 (Tonga) to Windows.
>
> On my previous setup, with QEMU from the git emulating a Q35 chipset on
> SeaBIOS and a Windows 8.1 guest, the guest would work only once per boot of
> the host. If I soft-reset the guest or shut it down and tried to run QEMU
> again, the guest monitor would stay blank (although QEMU would continue
> running, with no error messages). I have noticed that this problem only
> occurs when using the proprietary AMD driver in the guest: running on the
> native Windows 8.1 video driver, the guest could reboot without problems.
>
> This week, I decided to change the whole system, hoping that something
> would fix this problem. So now I'm emulating a i440fx chipset, using OVMF,
> with a fresh install of Windows 10 as guest. Things have improved: now the
> guest system can withstand soft reboots without problems. But whenever I
> shut down the guest machine, it is still not possible to turn it on again
> without rebooting the host.
>
> Sorry I don't have my start script here, I can post it later if necessary.
> But I inkove QEMU as a super user (sudo qemu-system-x86_64). And my host OS
> is Ubuntu 15.04.
>
> Thanks,
> Lucas
>
> On Thu, Sep 3, 2015 at 3:39 PM Blank Field <ihatethisfield at gmail.com>
> wrote:
>
>> There is a special mailing list for all the vfio questions. It aims to
>> replace the arch forum thread.
>>
>> http://lists.nongnu.org/archive/html/qemu-discuss/2015-09/msg00003.html
>> I couldn't manage to not screw up the formatting with G-Mail, so there
>> you have it as a link to archives.
>>
>> Regarding the problem - i don't remember exactly, but running qemu as a
>> regular user requires some more steps than just chown.
>> _______________________________________________
>> vfio-users mailing list
>> vfio-users at redhat.com
>> https://www.redhat.com/mailman/listinfo/vfio-users
>>
> _______________________________________________
> 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/20150904/3d1e1c76/attachment.htm>