From: Alex Williamson <alex.williamson@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: qemu-devel@nongnu.org, Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v2 2/2] hw/vfio/display: add ramfb support
Date: Fri, 12 Oct 2018 07:05:38 -0600 [thread overview]
Message-ID: <20181012070538.121f85a1@t450s.home> (raw)
In-Reply-To: <20181012084302.so3aptiavcgvbbyh@sirius.home.kraxel.org>
On Fri, 12 Oct 2018 10:43:02 +0200
Gerd Hoffmann <kraxel@redhat.com> wrote:
> 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.
Not so much grouping the bools as simply making the struct a bit more
space efficient by not adding obvious alignment holes.
> > 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).
Yes, I'm also trying with an OVMF build from your firmware repo.
> > -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.
That's where my wrapper script was replacing
s/vfio-pci/vfio-pci-nohotplug/, I didn't know about the driver override
you list below, that's much cleaner.
> > <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.
Ok, I'll update my xml and also try the raw ramfb device and see if I
can make it work. Thanks,
Alex
prev parent reply other threads:[~2018-10-12 13:05 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20180917061729.22407-1-kraxel@redhat.com>
[not found] ` <20180917061729.22407-3-kraxel@redhat.com>
2018-10-11 21:19 ` [Qemu-devel] [PATCH v2 2/2] hw/vfio/display: add ramfb support Alex Williamson
2018-10-12 8:43 ` Gerd Hoffmann
2018-10-12 13:05 ` Alex Williamson [this message]
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=20181012070538.121f85a1@t450s.home \
--to=alex.williamson@redhat.com \
--cc=kraxel@redhat.com \
--cc=pbonzini@redhat.com \
--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).