qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: qemu-devel <qemu-devel@nongnu.org>
Cc: kvm <kvm@vger.kernel.org>
Subject: Re: [Qemu-devel] VFIO VGA test branches
Date: Wed, 08 May 2013 10:05:20 -0600	[thread overview]
Message-ID: <1368029120.7331.38.camel@ul30vt.home> (raw)
In-Reply-To: <1367621792.22436.49.camel@ul30vt.home>

A few notes for anyone trying this...

      * I recommend the q35 machine type and using the default config
        file found in the docs directory.  This means your command line
        should include:

         -M q35 -nodefconfig -readconfig /path/to/qemu.git/docs/q35-chipset.cfg

      * You're likely passing through a graphics card that is attached
        to the host system below a root port, so make it appear that way
        to the guest too.  If your graphics card has a graphics function
        and audio function, assign them as:

        -device vfio-pci,host=2:00.0,x-vga=on,multifunction=on,bus=ich9-pcie-port-1,addr=0.0 \
        -device vfio-pci,host=2:00.1,bus=ich9-pcie-port-1,addr=0.1
        
        The bus name comes from the q35-chipset.cfg above.  If your
        graphics doesn't include a separate audio device, drop the
        second line and the multifunction option of the first (addr is
        also optional at that point, 0.0 will be the default).
        
      * If you follow both of the above, your VGA device is now below a
        root port, but the version of seabios in qemu doesn't support
        initializing VGA routing to that device.  To fix, use upstream
        seabios: git://git.seabios.org/seabios.git  The default config
        should work.  Then add the following to your qemu commandline:
        
        -L /path/to/seabios.git/out/ -L /path/to/qemu/bios/files/
        
        (the latter is likely /usr/local/share/qemu/)
        
      * You can use -nographic to prevent QEMU from trying to start SDL
        or need a vnc parameter.  You can also specify a -vnc option and
        use the window for mouse input.

      * Use -vga none.  At this point I'm not really interested in
        dual-headed VMs unless you're interested in working on it.
        Having an emulated VGA means we're not really testing VGA
        support through VFIO.

      * Do no use the vfio-pci romfile option unless you need it (ie.
        try w/o first).  Option ROMs check an internal signature against
        the hardware.  If they don't match, it isn't run.  If you
        download a ROM from the internet, you may get nowhere.  If you
        do need a ROM, it's best to scrape it off the device you're
        using.  You can do this through the "rom" file in sysfs for the
        device.  "echo 1 > rom" to enable it, the read it as "cat rom
        > /tmp/rom".  To do this, it should be a secondary graphics
        device and be untouched by host drivers.  You may have better
        luck booting from an install CD to get an environment where the
        device is untouched for this.

      * USB passthrough is handy for input and easier than figuring out
        which ports are connected to which USB controllers for vfio-pci
        assignment.  Use lsusb to find the devices, note the bus and
        device numbers, the use:

        -device usb-host,hostbus=8,hostaddr=2

I think that's it.  Feel free to reply with other best practices.
Thanks,

Alex

On Fri, 2013-05-03 at 16:56 -0600, Alex Williamson wrote:
> Hi folks,
> 
> A number of people have been trying VFIO's VGA support, a few have even
> been successful.  Resetting devices has been a problem and makes it
> very, very difficult to really use VGA assignment effectively.  The code
> in the branches below attempts to address this.  Discrete graphics
> devices are typically on their own bus, which we can reset so we
> theoretically get something pretty close to a power-on state for the GPU
> on each run (or after each guest reset).  With this I'm able to get
> multiple runs on my HD7850 with no need to reset the host.  Hopefully
> this will also cleanup after any host uses of the device so we can
> unload driver rather than blacklisting them.
> 
> If you've been playing with VFIO and VGA, please give the branches below
> a shot and report successes and failures.  Note that this new reset is
> only enable with the x-vga=on option, so should not do gratuitous bus
> resets for other devices.  Thanks,
> 
> Alex
> 
> git://github.com/awilliam/linux-vfio.git vfio-vga-reset
> git://github.com/awilliam/qemu-vfio.git vfio-vga-reset
> 
> PS - The above linux branch is v3.9 based which has a known kvm emulator
> bug.  If you're on Intel and nothing happens, try:
> 
> sudo modprobe -r kvm_intel
> sudo modprobe kvm_intel emulate_invalid_guest_state=0
> 
> This is required to execute the VGA BIOS on my HD7850.
> 
> If things still don't work, apply the following patch:
> 
> --- a/hw/misc/vfio.c
> +++ b/hw/misc/vfio.c
> @@ -40,7 +40,7 @@
>  #include "sysemu/kvm.h"
>  #include "sysemu/sysemu.h"
>  
> -/* #define DEBUG_VFIO */
> +#define DEBUG_VFIO
>  #ifdef DEBUG_VFIO
>  #define DPRINTF(fmt, ...) \
>      do { fprintf(stderr, "vfio: " fmt, ## __VA_ARGS__); } while (0)
> 
> And log the output (there will be lots).
> 
> Also, AMD/ATI and Nvidia are the only devices expected to have a
> reasonable shot at working.  I'm seeing reports of success on AMD/ATI HD
> 5xxx, 6xxx, and 7xxx, as well as Nvidia Geforce 7-series, 8-series, 4xx
> series, and 6xx series.  Older cards from those vendors probably aren't
> very interesting to support (honestly I wouldn't care much about 7/8
> series Nvidia or HD5xxx AMD, except I happen to have some for testing -
> use emulated VGA if you don't care about performance).
> 
> Intel IGD graphics has numerous issues since it's partially incorporated
> into the chipset.  Please don't bother to report IGD is broken unless
> you're interested in fixing it.

  reply	other threads:[~2013-05-08 16:05 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-03 22:56 [Qemu-devel] VFIO VGA test branches Alex Williamson
2013-05-08 16:05 ` Alex Williamson [this message]
2013-05-13 20:55 ` Knut Omang
2013-05-13 22:23   ` Alex Williamson
2013-05-14  6:42     ` Knut Omang
2013-05-19 15:35     ` Knut Omang
2013-05-19 19:26       ` Maik Broemme
2013-05-20  3:17         ` Alex Williamson
2013-05-20 11:05           ` Maik Broemme
2013-05-28  1:40             ` Maik Broemme
2013-05-28  3:21               ` Alex Williamson
2013-05-28 18:45               ` Maik Broemme
2013-05-28 22:28                 ` Alex Williamson
2013-05-29 15:27                   ` Maik Broemme
2013-05-29 16:16                     ` Maik Broemme
2013-05-29 17:07                       ` Alex Williamson
2013-05-20 21:08         ` Knut Omang
2013-05-20  4:15       ` Alex Williamson
2013-05-20 21:11         ` Knut Omang
2013-05-28  5:33           ` Knut Omang
2013-05-28 13:53             ` Alex Williamson
  -- strict thread matches above, loose matches on Subject: below --
2013-05-10 21:31 Justin Gottula
2013-05-10 21:38 ` Alex Williamson
2013-05-17  8:09   ` Justin Gottula
2013-05-20  3:44     ` Alex Williamson
2013-05-22  3:31       ` Justin Gottula
2013-06-04  8:06 Michael Nelson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1368029120.7331.38.camel@ul30vt.home \
    --to=alex.williamson@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).