From: Alex Williamson <alex.williamson@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: qemu-devel@nongnu.org, "Paolo Bonzini" <pbonzini@redhat.com>,
"Eduardo Habkost" <ehabkost@redhat.com>,
"Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>,
"Richard Henderson" <rth@twiddle.net>,
qemu-arm@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>,
"Peter Maydell" <peter.maydell@linaro.org>,
"László Érsek" <lersek@redhat.com>,
libvir-list@redhat.com, "Erik Skultety" <eskultet@redhat.com>,
"Laine Stump" <laine@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v4 3/3] hw/vfio/display: add ramfb support
Date: Wed, 13 Jun 2018 13:50:47 -0600 [thread overview]
Message-ID: <20180613135047.5c1ce227@w520.home> (raw)
In-Reply-To: <20180613084149.14523-4-kraxel@redhat.com>
On Wed, 13 Jun 2018 10:41:49 +0200
Gerd Hoffmann <kraxel@redhat.com> wrote:
> So we have a boot display when using a vgpu as primary display.
>
> Use vfio-pci-ramfb instead of vfio-pci to enable it.
Using a different device here seems like it almost guarantees a very
complicated path to support under libvirt. What necessitates this
versus a simple ramfb=on option to vfio-pci?
I'm also not sure I understand the usage model, SeaBIOS and OVMF know
how to write to this display, but it seems that the guest does not. I
suppose in the UEFI case runtime services can be used to continue
writing this display, but BIOS doesn't have such an option, unless
we're somehow emulating VGA here. So for UEFI, I can imagine this
covers us from power on through firmware boot and up to guest drivers
initializing the GPU (assuming the vGPU supports a kernel mode driver,
does NVIDIA?), but for BIOS it seems we likely still have a break from
the bootloader to GPU driver initialization. For instance, what driver
is used to draw the boot animation (or blue screen) on SeaBIOS Windows
VM? I'm assuming that this display and the vGPU display are one in the
same, so there's some cut from one to the other. Thanks,
Alex
> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> ---
> include/hw/vfio/vfio-common.h | 2 ++
> hw/vfio/display.c | 10 ++++++++++
> hw/vfio/pci.c | 15 +++++++++++++++
> 3 files changed, 27 insertions(+)
>
> diff --git a/include/hw/vfio/vfio-common.h b/include/hw/vfio/vfio-common.h
> index a9036929b2..a58d7e7e77 100644
> --- a/include/hw/vfio/vfio-common.h
> +++ b/include/hw/vfio/vfio-common.h
> @@ -26,6 +26,7 @@
> #include "qemu/queue.h"
> #include "qemu/notify.h"
> #include "ui/console.h"
> +#include "hw/display/ramfb.h"
> #ifdef CONFIG_LINUX
> #include <linux/vfio.h>
> #endif
> @@ -143,6 +144,7 @@ typedef struct VFIODMABuf {
>
> typedef struct VFIODisplay {
> QemuConsole *con;
> + RAMFBState *ramfb;
> struct {
> VFIORegion buffer;
> DisplaySurface *surface;
> diff --git a/hw/vfio/display.c b/hw/vfio/display.c
> index 59c0e5d1d7..409d5a2e3a 100644
> --- a/hw/vfio/display.c
> +++ b/hw/vfio/display.c
> @@ -124,6 +124,9 @@ static void vfio_display_dmabuf_update(void *opaque)
>
> primary = vfio_display_get_dmabuf(vdev, DRM_PLANE_TYPE_PRIMARY);
> if (primary == NULL) {
> + if (dpy->ramfb) {
> + ramfb_display_update(dpy->con, dpy->ramfb);
> + }
> return;
> }
>
> @@ -181,6 +184,8 @@ static int vfio_display_dmabuf_init(VFIOPCIDevice *vdev, Error **errp)
> vdev->dpy->con = graphic_console_init(DEVICE(vdev), 0,
> &vfio_display_dmabuf_ops,
> vdev);
> + if (strcmp(object_get_typename(OBJECT(vdev)), "vfio-pci-ramfb") == 0)
> + vdev->dpy->ramfb = ramfb_setup(errp);
> return 0;
> }
>
> @@ -228,6 +233,9 @@ static void vfio_display_region_update(void *opaque)
> return;
> }
> if (!plane.drm_format || !plane.size) {
> + if (dpy->ramfb) {
> + ramfb_display_update(dpy->con, dpy->ramfb);
> + }
> return;
> }
> format = qemu_drm_format_to_pixman(plane.drm_format);
> @@ -300,6 +308,8 @@ static int vfio_display_region_init(VFIOPCIDevice *vdev, Error **errp)
> vdev->dpy->con = graphic_console_init(DEVICE(vdev), 0,
> &vfio_display_region_ops,
> vdev);
> + if (strcmp(object_get_typename(OBJECT(vdev)), "vfio-pci-ramfb") == 0)
> + vdev->dpy->ramfb = ramfb_setup(errp);
> return 0;
> }
>
> diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
> index 18c493b49e..6a2b42a595 100644
> --- a/hw/vfio/pci.c
> +++ b/hw/vfio/pci.c
> @@ -3234,9 +3234,24 @@ static const TypeInfo vfio_pci_dev_info = {
> },
> };
>
> +static void vfio_pci_ramfb_dev_class_init(ObjectClass *klass, void *data)
> +{
> + DeviceClass *dc = DEVICE_CLASS(klass);
> +
> + dc->hotpluggable = false;
> +}
> +
> +static const TypeInfo vfio_pci_ramfb_dev_info = {
> + .name = "vfio-pci-ramfb",
> + .parent = "vfio-pci",
> + .instance_size = sizeof(VFIOPCIDevice),
> + .class_init = vfio_pci_ramfb_dev_class_init,
> +};
> +
> static void register_vfio_pci_dev_type(void)
> {
> type_register_static(&vfio_pci_dev_info);
> + type_register_static(&vfio_pci_ramfb_dev_info);
> }
>
> type_init(register_vfio_pci_dev_type)
next prev parent reply other threads:[~2018-06-13 19:51 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-13 8:41 [Qemu-devel] [PATCH v4 0/3] ramfb: simple boot framebuffer Gerd Hoffmann
2018-06-13 8:41 ` [Qemu-devel] [PATCH v4 1/3] hw/display: add ramfb, a simple boot framebuffer living in guest ram Gerd Hoffmann
2018-06-13 8:41 ` [Qemu-devel] [PATCH v4 2/3] hw/display: add standalone ramfb device Gerd Hoffmann
2018-06-13 8:41 ` [Qemu-devel] [PATCH v4 3/3] hw/vfio/display: add ramfb support Gerd Hoffmann
2018-06-13 19:50 ` Alex Williamson [this message]
2018-06-13 22:36 ` Gerd Hoffmann
2018-06-14 8:32 ` Laszlo Ersek
2018-06-14 9:48 ` Erik Skultety
2018-06-15 7:53 ` Gerd Hoffmann
2018-06-13 9:37 ` [Qemu-devel] [PATCH v4 0/3] ramfb: simple boot framebuffer no-reply
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=20180613135047.5c1ce227@w520.home \
--to=alex.williamson@redhat.com \
--cc=ehabkost@redhat.com \
--cc=eskultet@redhat.com \
--cc=kraxel@redhat.com \
--cc=laine@redhat.com \
--cc=lersek@redhat.com \
--cc=libvir-list@redhat.com \
--cc=marcel.apfelbaum@gmail.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
/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).