Re: [Qemu-devel] [PATCH v2 2/2] hw/vfio/display: add ramfb support

[Gerd Hoffmann]

  Hi,

> >      OnOffAuto display;
> > +    bool enable_ramfb;
> >      int32_t bootindex;
> >      uint32_t igd_gms;
> >      OffAutoPCIBAR msix_relo;
> 
> Hi Gerd,
> 
> One tiny nit here, we can move this new bool down in the struct with
> the rest of the bools for better alignment.  I can change that on
> commit.

I've grouped it with the display option because it is display related
too, but if you prefer to group the bools instead this is fine with me.

> However, I'm not having luck getting ramfb to work; the
> display is only getting initialized once the guest driver loads.  This
> is a 440FX/SeaBIOS VM, it looks like you've already updated bios.bin in
> qemu.git with ramfb support,

Yes, seabios (and vgabios) bundled with 3.0 (and master branch) should work 
fine.

There is a standalone device you can use for testing (-vga none -device
ramfb), to see whenever the firmware side of things works correctly.

OVMF has ramfb support too btw (merged a few months back).

> -device 
> vfio-pci-nohotplug,id=hostdev0,sysfsdev=...,display=on,bus=pci.0,addr=0x9 \

>     <hostdev mode='subsystem' type='mdev' managed='no' model='vfio-pci' 
> display='on'>
>       <source>
>         <address uuid='cd4fa69f-c24c-476f-a61d-abca705e2a13'/>
>       </source>
>       <address type='pci' domain='0x0000' bus='0x00' slot='0x09' 
> function='0x0'/>
>     </hostdev>

Hmm, that actually uses vfio-pci-nohotplug?
But when ramfb=on doesn't throw an error, then yes, appearently.

>   <qemu:commandline>
>     <qemu:arg value='-set'/>
>     <qemu:arg value='device.hostdev0.x-igd-opregion=on'/>
>     <qemu:arg value='-set'/>
>     <qemu:arg value='device.hostdev0.ramfb=on'/>
>   </qemu:commandline>

I have this (additionally):

    <qemu:arg value='-set'/>
    <qemu:arg value='device.hostdev0.driver=vfio-pci-nohotplug'/>

> This is a Windows 10 VM, but as I understand this ramfb support, I
> think I'm still supposed to see SeaBIOS boot messages and perhaps even
> the Windows boot animation before the guest driver takes over, is that
> correct?

Yes, you should see both.

cheers,
  Gerd