public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Phil Dennis-Jordan <lists@philjordan.eu>
To: edk2-devel@lists.01.org
Subject: [RFC PATCH v1 0/2] OvmfPkg/QemuVideoDxe: Add VMWare SVGA2 framebuffer support
Date: Wed, 29 Mar 2017 21:19:55 +1300	[thread overview]
Message-ID: <1490775597-24007-1-git-send-email-lists@philjordan.eu> (raw)

This extends the QemuVideoDxe driver to support the VMWare SVGA2 display
device implemented by Qemu. Drivers for this device exist for guest OSes
which do not support Qemu's other display adapters, so supporting it in
OVMF is useful in conjunction with those OSes.

I've tried to follow the existing pattern for device-specific code in
OVMF's QemuVideoDxe driver as much as possible, with the minimum of
additional code. I've marked this patch as RFC for 2 main reasons:

1. I've imported VMWare's own header file with device register constants
etc. verbatim. (patch 1/2) This doesn't follow any of the EDK2 coding
conventions, and it uses the MIT license, not BSD. Only a small percentage
of symbols are actually used in the driver. On the other hand, it's
obviously the authoritative source. I'm not sure what the correct
etiquette is here, define our own constants, or import the authoritative
header file?

2. For the functionality this driver uses, 2 I/O ports are used with
32-bit wide reads and writes. Unfortunately, one of them is not 32-bit
aligned. This is fine as far as x86/x86-64 is concerned, but neither
EDK2's IoLib nor other platforms support such an access pattern. It seems
this issue was already encountered/discussed on the edk2-devel list 4
years ago: http://edk2-devel.narkive.com/bwH3r0us/unaligned-i-o I couldn't
find any code resulting from that discussion, and Qemu definitely uses
unaligned port numbers for the SVGA2 device. (SVGA_IO_MUL is 1 in
hw/display/vmware_vga.c) It does not appear to make any provision for
non-x86 architectures, so I assume there's no sensible way to drive the
device in those cases. The patch therefore only detects the device on x86,
where it uses UnalignedIoWrite/Read32() helper functions which I've based
on IoLib's aligned ones. I have only tested the GCC version of these.
Feel free to suggest a better way of handling the issue.

Github feature branch: https://github.com/pmj/edk2/tree/ovmf_vmware_svga2_v1

Phil Dennis-Jordan (2):
  OvmfPkg: Add SVGA2 device register definition header from VMWare
  OvmfPkg: Add VMWare SVGA II support in QemuVideoDxe.

 OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf         |    6 +
 OvmfPkg/QemuVideoDxe/Qemu.h                   |   50 +
 OvmfPkg/QemuVideoDxe/UnalignedIoInternal.h    |   51 +
 OvmfPkg/QemuVideoDxe/svga_reg.h               | 1558 ++++++++++++++++++++
 OvmfPkg/QemuVideoDxe/Driver.c                 |   67 +
 OvmfPkg/QemuVideoDxe/Gop.c                    |   71 +-
 OvmfPkg/QemuVideoDxe/Initialize.c             |   88 ++
 OvmfPkg/QemuVideoDxe/UnalignedIoGcc.c         |   59 +
 OvmfPkg/QemuVideoDxe/UnalignedIoIcc.c         |   79 +
 OvmfPkg/QemuVideoDxe/UnalignedIoMsc.c         |   81 +
 OvmfPkg/QemuVideoDxe/UnalignedIoUnsupported.c |   53 +
 11 files changed, 2162 insertions(+), 1 deletion(-)
 create mode 100644 OvmfPkg/QemuVideoDxe/UnalignedIoInternal.h
 create mode 100644 OvmfPkg/QemuVideoDxe/svga_reg.h
 create mode 100644 OvmfPkg/QemuVideoDxe/UnalignedIoGcc.c
 create mode 100644 OvmfPkg/QemuVideoDxe/UnalignedIoIcc.c
 create mode 100644 OvmfPkg/QemuVideoDxe/UnalignedIoMsc.c
 create mode 100644 OvmfPkg/QemuVideoDxe/UnalignedIoUnsupported.c

-- 
2.3.2 (Apple Git-55)



             reply	other threads:[~2017-03-29  8:20 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-29  8:19 Phil Dennis-Jordan [this message]
2017-03-29  8:19 ` [RFC PATCH v1 1/2] OvmfPkg: Add SVGA2 device register definition header from VMWare Phil Dennis-Jordan
2017-03-29  8:19 ` [RFC PATCH v1 2/2] OvmfPkg: Add VMWare SVGA II support in QemuVideoDxe Phil Dennis-Jordan
2017-03-30  1:33 ` [RFC PATCH v1 0/2] OvmfPkg/QemuVideoDxe: Add VMWare SVGA2 framebuffer support Laszlo Ersek
2017-03-30 10:51   ` Phil Dennis-Jordan
2017-03-30 15:53     ` Laszlo Ersek

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-list 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=1490775597-24007-1-git-send-email-lists@philjordan.eu \
    --to=devel@edk2.groups.io \
    /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