Re: [edk2] nonzero LUN on USB Bulk Only Transfer fails with QEMU+edk2

[Gerd Hoffmann]

  Hi,

> (2) If I change the cmdline to "lun=5", then the exchange is:

Not supported (by the usb protocol).

The protocol has a control message to query the number of devices (grep
for GetMaxLun in qemu).  LUNs are not allowed to be sparse.  So, with a
single storage device the LUN must be zero.  With two devices the LUNs
must be 0,1, with three 0,1,2 etc., you get the idea :)

Maybe usb-bot should check for that and throw an error, I think right
now we only have the generic scsi code check which will verify the lun
isn't too big (<= 15) but will not check the non-sparse requirement.

cheers,
  Gerd

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Drop CSM support in OvmfPkg?

[Gerd Hoffmann]

On Tue, Jan 22, 2019 at 04:23:06PM +, David Woodhouse wrote:
> On Tue, 2019-01-22 at 16:13 +, Ni, Ray wrote:
> > David,
> > I'd like to re-start the discussion.
> > Could you please kindly explain the background/reason of adding CSM
> > support in OVMF?
> > Maybe knowing the reason can help to make further decisions of
> > whether to
> > A. keep it outside OvmfPkg
> > B. keep it inside OvmfPkg
> > C. maybe have a chance to just remove the CSM support after
> > revisiting
> 
> The idea was to make it simple to have a single firmware image for
> virtual machines which would support both UEFI and Legacy boot for
> guests simultaneously.

The idea never really took off though.

> In libvirt there has been an alternative approach, where the BIOS image
> is switched between OVMF and SeaBIOS according to the configuration of
> the guest VM.

It's not mandated by libvirt, you can easily create a VM configuration
which uses a OVMF build with CSM support.

But, yes, it is rarely seen in practice.

Microsoft is doing the same btw:  hyper-v has gen1 (bios) and gen2
(uefi) guest types.

> That's fine for libvirt, but in situations where VM hosting is provided
> as a service, it becomes quite painful to manage the 'UEFI' vs.
> 'Legacy' flags on guest images and then switch firmware images
> accordingly.

Seems people try to address this by building cloud images which support
both BIOS and UEFI.

> A one-size-fits-all BIOS using OVMF+CSM is very much
> preferable.

Building a one-size-fits-all BIOS is pretty much impossible due to CSM
being incompatible with secure boot.

cheers,
  Gerd

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Drop CSM support in OvmfPkg?

[Gerd Hoffmann]

On Mon, Dec 17, 2018 at 10:54:25AM +0100, Laszlo Ersek wrote:
> (Adding Kevin, Gerd, David)
> 
> On 12/17/18 03:23, Ni, Ruiyu wrote:
> > Hi OvmfPkg maintainers and reviewers,
> > I am working on removing IntelFrameworkModulePkg and IntelFrameworkPkg. The 
> > biggest dependency now I see is the CSM components that OVMF depends on.
> > So I'd like to know your opinion about how to handle this. I see two 
> > options here:
> > 
> >   1.  Drop CSM support in OvmfPkg.
> >   2.  Create a OvmfPkg/Csm folder to duplicate all CSM components there.
> > 
> > What's your opinion about this?
> 
> (1) Personally I never use CSM builds of OVMF. The OVMF builds in RHEL
> and Fedora also don't enable the CSM (mainly because I had found
> debugging & supporting the CSM *extremely* difficult). For
> virtualization, we generally recommend "use SeaBIOS directly if you need
> a traditional BIOS guest".

On a virtual machine it is very simple to switch the firmware (unlike on
physical machines), which I think is the main reason ovmf+csm never
really took off.

> (3) However, David and Kevin had put a *lot* of work into enabling
> SeaBIOS to function as a CSM in combination with OVMF. Today, the CSM
> target is a dedicated / separate "build mode" of SeaBIOS.

IIRC there are still some corner cases which are not working and nobody
wants put any effort into fixing them.  S3 suspend comes to mind.

I'm not even sure it still works.  It builds, yes, my jenkins instance
does that.  But there is no testing beyond that, and I doubt that
someone else does regular ovmf+csm regression testing.  So the chances
that any runtime breakage goes unnoticed are pretty high ...

> (4) I also think an open source CSM implementation should exist, just so
> people can study it and experiment with it.

It'll not be deleted from git, so it'll be there even when removed from
master branch.

> In short, I think the community would benefit if someone continued to
> maintain the CSM infrastructure in edk2,

But what is the point in keeping the infrastructure if even physical
hardware starts to drop csm support?

So, I'd go with option (1).

cheers,
  Gerd

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 4/4] OvmfPkg: simply use the Bochs interface for vmsvga

[Gerd Hoffmann]

On Wed, Oct 24, 2018 at 02:40:08PM +0800, yuchen...@synology.com wrote:
> From: yuchenlin 
> 
> BAR  |std vga |  vmsvga
> -
> 0|   Framebuffer  | I/O space
> 1|   Reserved | Framebuffer
> 2|   MMIO | FIFO
> 
> Because of the PCI BARs difference between std vga and
> vmsvga, we can not simply recognize the "QEMU VMWare SVGA"
> as the QEMU_VIDEO_BOCHS_MMIO variant.
> 
> Instead, we remain variant QEMU_VIDEO_VMWARE_SVGA, and use
> it for:
> 
> (1) Get framebuffer from correct PCI BAR
> (2) Prevent using BAR2 for MMIO

looks good to me.  seavgabios uses the same logic.

cheers,
  Gerd

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] OvmfPkg: initialize bochs when initializing vmsvga

[Gerd Hoffmann]

  Hi,

> Please help me see the situation better. Here's my current
> understanding.
> 
> (1) QemuVideoDxe doesn't set up the VMW SVGA FIFO, and does not store 1
> to the SVGA_REG_CONFIG_DONE register. And this is not a "small
> missing step" -- the FIFO setup can be considered a separate
> feature.
> 
> (2) We don't intend to implement the FIFO setup feature. (In particular
> because we don't intend to track changed rectangles and send updates
> via the FIFO.)
> 
> (3) The intent of the original VMW SVGA enablement patch for
> QemuVideoDxe, namely commit c137d9508169, was to enable booting some
> UEFI operating systems on OVMF that had guest drivers only for VMW
> SVGA.
> 
> (4) The QEMU device model now -- since commit 104bd1dc70 -- falls back
> to stdvga (that is, Bochs) in response to QemuVideoDxe's actions.
> 
> (5) Your proposal is to set up the Bochs interface in QemuVideoDxe, *in
> addition* to the -- now dysfunctional! -- VMW SVGA interface.
> 
> Is my understanding correct?

I understand things the same way.

> So, what do you think of the following approach, instead of your
> currently proposed patch:
> 
> - revert commit c137d9508169 ("OvmfPkg/QemuVideoDxe: VMWare SVGA device
>   support", 2017-04-07)
> 
> - revert commit 05a537945872 ("OvmfPkg/QemuVideoDxe: Helper functions
>   for unaligned port I/O.", 2017-04-07)
> 
> - given that QEMU provides the Bochs interface anyway, with the VMW SVGA
>   device model, simply recognize the "QEMU VMWare SVGA" card, in the
>   "gQemuVideoCardList" array, as the QEMU_VIDEO_BOCHS_MMIO variant.

Makes sense to me.

Alternatively write a full-blown vmsvga driver which works simliar to
the virtio-gpu driver.  I have my doubts this is worth the effort
though.

> Before QEMU commit 104bd1dc70, was it really *required* to use the (now
> dead) QemuVideoDxe code for VMW SVGA, or would it always have been
> possible to simply use the Bochs interface, to drive the VMW SVGA
> device?

I think bochs interface works works with all vmsvga version (in qemu).
Didn't test though.

cheers,
  Gerd

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 0/4] Add QemuRamfbDxe driver

[Gerd Hoffmann]

  Hi,

> >> - What happens if you locate the parent handle (with the VenHw node)
> >> and/or the child handle (with the GOP on it), and try to disconnect them?
> > 
> > How can I do that?
> 
> Run "dh -d -v -p GraphicsOutput". The listing will include all handles
> (represented by hex identifiers) that carry a GOP. Each handle will also
> have its device path protocol instance displayed, in textual
> representation, so if there are multiple GOPs, you'll be able to locate
> the one produced by QemuRamfbDxe. The listing should also reference the
> parent controller handle.
> 
> Knowing the hex identifiers for parent and child, experiment with the
> "disconnect" command. (See "help disconnect" for syntax.)

Shell> dh -p GraphicsOutput
Handle dump by protocol 'GraphicsOutput'
44: ConsoleOut SimpleTextOut GraphicsOutput(GraphicsOutput) 
DevicePath(..C08C457)/AcpiAdr(0x80010300)) 
6D: GraphicsOutput(GraphicsOutput) SimpleTextOut 
Shell> disconnect 6d
Disconnect - (6D,3E643560,3E5C3A03) Result Success.
Shell> disconnect 44
Disconnect - (44,3E643560,3E5C3A03) Result Success.
Shell> 

The second disconnect makes ovmf stop using ramfb as console (serial continues
to work).

cheers,
  Gerd

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v3 3/4] OvmfPkg: add QemuRamfb to platform console

[Gerd Hoffmann]

Add QemuRamfbDxe device path to the list of platform console devices,
so ConSplitter will pick up the device even though it isn't a PCI GPU.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Gerd Hoffmann 
Reviewed-by: Laszlo Ersek 
---
 .../Library/PlatformBootManagerLib/PlatformData.c  | 51 ++
 1 file changed, 51 insertions(+)

diff --git a/OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c 
b/OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c
index a50cd7bcaf..1250a6d351 100644
--- a/OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c
+++ b/OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c
@@ -14,6 +14,7 @@
 **/
 
 #include "BdsPlatform.h"
+#include 
 
 //
 // Debug Agent UART Device Path structure
@@ -37,6 +38,17 @@ typedef struct {
 } USB_KEYBOARD_DEVICE_PATH;
 #pragma pack ()
 
+//
+// QemuRamfb Device Path structure
+//
+#pragma pack (1)
+typedef struct {
+  VENDOR_DEVICE_PATHVendor;
+  ACPI_ADR_DEVICE_PATH  AcpiAdr;
+  EFI_DEVICE_PATH_PROTOCOL  End;
+} VENDOR_RAMFB_DEVICE_PATH;
+#pragma pack ()
+
 ACPI_HID_DEVICE_PATH   gPnpPs2KeyboardDeviceNode  = gPnpPs2Keyboard;
 ACPI_HID_DEVICE_PATH   gPnp16550ComPortDeviceNode = gPnp16550ComPort;
 UART_DEVICE_PATH   gUartDeviceNode= gUart;
@@ -100,6 +112,41 @@ STATIC USB_KEYBOARD_DEVICE_PATH gUsbKeyboardDevicePath = {
   gEndEntire
 };
 
+STATIC VENDOR_RAMFB_DEVICE_PATH gQemuRamfbDevicePath = {
+  {
+{
+  HARDWARE_DEVICE_PATH,
+  HW_VENDOR_DP,
+  {
+(UINT8) (sizeof (VENDOR_DEVICE_PATH)),
+(UINT8) ((sizeof (VENDOR_DEVICE_PATH)) >> 8)
+  }
+},
+QEMU_RAMFB_GUID,
+  },
+  {
+{
+  ACPI_DEVICE_PATH,
+  ACPI_ADR_DP,
+  {
+(UINT8) (sizeof (ACPI_ADR_DEVICE_PATH)),
+(UINT8) ((sizeof (ACPI_ADR_DEVICE_PATH)) >> 8)
+  }
+},
+ACPI_DISPLAY_ADR (
+  1,   // DeviceIdScheme
+  0,   // HeadId
+  0,   // NonVgaOutput
+  1,   // BiosCanDetect
+  0,   // VendorInfo
+  ACPI_ADR_DISPLAY_TYPE_EXTERNAL_DIGITAL,  // Type
+  0,   // Port
+  0// Index
+  ),
+  },
+  gEndEntire
+};
+
 //
 // Predefined platform default console device path
 //
@@ -113,6 +160,10 @@ PLATFORM_CONSOLE_CONNECT_ENTRY   gPlatformConsole[] = {
 CONSOLE_IN
   },
   {
+(EFI_DEVICE_PATH_PROTOCOL *),
+CONSOLE_OUT
+  },
+  {
 NULL,
 0
   }
-- 
2.9.3

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v3 4/4] ArmVirtPkg: add QemuRamfbDxe

[Gerd Hoffmann]

Add QemuRamfbDxe to dsc and fdf files for ArmVirt package.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Gerd Hoffmann 
Reviewed-by: Laszlo Ersek 
---
 ArmVirtPkg/ArmVirtQemu.dsc   | 2 ++
 ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc | 1 +
 ArmVirtPkg/ArmVirtQemuKernel.dsc | 2 ++
 3 files changed, 5 insertions(+)

diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
index d74feb709c..744d127a10 100644
--- a/ArmVirtPkg/ArmVirtQemu.dsc
+++ b/ArmVirtPkg/ArmVirtQemu.dsc
@@ -57,6 +57,7 @@
   BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf
   
PlatformBootManagerLib|ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
   
CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
+  
FrameBufferBltLib|MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf
   QemuBootOrderLib|OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
   FileExplorerLib|MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf
   
PciPcdProducerLib|ArmVirtPkg/Library/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
@@ -391,6 +392,7 @@
   #
   # Video support
   #
+  OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf
   OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
   OvmfPkg/PlatformDxe/Platform.inf
 
diff --git a/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc 
b/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
index 89f95b2d99..63a202c788 100644
--- a/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
+++ b/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
@@ -175,6 +175,7 @@ READ_LOCK_STATUS   = TRUE
   #
   # Video support
   #
+  INF OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf
   INF OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
   INF OvmfPkg/PlatformDxe/Platform.inf
 
diff --git a/ArmVirtPkg/ArmVirtQemuKernel.dsc b/ArmVirtPkg/ArmVirtQemuKernel.dsc
index 1e823aeab7..e59f53b728 100644
--- a/ArmVirtPkg/ArmVirtQemuKernel.dsc
+++ b/ArmVirtPkg/ArmVirtQemuKernel.dsc
@@ -57,6 +57,7 @@
   BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf
   
PlatformBootManagerLib|ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
   
CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
+  
FrameBufferBltLib|MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf
   QemuBootOrderLib|OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
   FileExplorerLib|MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf
   
PciPcdProducerLib|ArmVirtPkg/Library/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
@@ -380,6 +381,7 @@
   #
   # Video support
   #
+  OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf
   OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
   OvmfPkg/PlatformDxe/Platform.inf
 
-- 
2.9.3

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v3 0/4] Add QemuRamfbDxe driver

[Gerd Hoffmann]

  Hi,

This is the efi driver for qemu ramfb, a simple boot framebuffer.  Qemu
patches just have been posted to qemu-devel.

v3: fix leftovers from v2.
v2: tons of codestyle fixes, some control flow tweaks.

cheers,
  Gerd

Gerd Hoffmann (4):
  OvmfPkg: add QEMU_RAMFB_GUID
  OvmfPkg: add QemuRamfbDxe
  OvmfPkg: add QemuRamfb to platform console
  ArmVirtPkg: add QemuRamfbDxe

 OvmfPkg/Include/Guid/QemuRamfb.h   |  25 ++
 .../Library/PlatformBootManagerLib/PlatformData.c  |  51 +++
 OvmfPkg/QemuRamfbDxe/QemuRamfb.c   | 399 +
 ArmVirtPkg/ArmVirtQemu.dsc |   2 +
 ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc   |   1 +
 ArmVirtPkg/ArmVirtQemuKernel.dsc   |   2 +
 OvmfPkg/OvmfPkg.dec|   1 +
 OvmfPkg/OvmfPkgIa32.dsc|   1 +
 OvmfPkg/OvmfPkgIa32.fdf|   1 +
 OvmfPkg/OvmfPkgIa32X64.dsc |   1 +
 OvmfPkg/OvmfPkgIa32X64.fdf |   1 +
 OvmfPkg/OvmfPkgX64.dsc |   1 +
 OvmfPkg/OvmfPkgX64.fdf |   1 +
 OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf  |  52 +++
 14 files changed, 539 insertions(+)
 create mode 100644 OvmfPkg/Include/Guid/QemuRamfb.h
 create mode 100644 OvmfPkg/QemuRamfbDxe/QemuRamfb.c
 create mode 100644 OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf

-- 
2.9.3

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v3 2/4] OvmfPkg: add QemuRamfbDxe

[Gerd Hoffmann]

Add a driver for the qemu ramfb display device.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Gerd Hoffmann 
---
 OvmfPkg/QemuRamfbDxe/QemuRamfb.c  | 399 ++
 OvmfPkg/OvmfPkgIa32.dsc   |   1 +
 OvmfPkg/OvmfPkgIa32.fdf   |   1 +
 OvmfPkg/OvmfPkgIa32X64.dsc|   1 +
 OvmfPkg/OvmfPkgIa32X64.fdf|   1 +
 OvmfPkg/OvmfPkgX64.dsc|   1 +
 OvmfPkg/OvmfPkgX64.fdf|   1 +
 OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf |  52 +
 8 files changed, 457 insertions(+)
 create mode 100644 OvmfPkg/QemuRamfbDxe/QemuRamfb.c
 create mode 100644 OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf

diff --git a/OvmfPkg/QemuRamfbDxe/QemuRamfb.c b/OvmfPkg/QemuRamfbDxe/QemuRamfb.c
new file mode 100644
index 00..d5025a1cee
--- /dev/null
+++ b/OvmfPkg/QemuRamfbDxe/QemuRamfb.c
@@ -0,0 +1,399 @@
+/** @file
+  This driver is a implementation of the Graphics Output Protocol
+  for the QEMU ramfb device.
+
+  Copyright (c) 2018, Red Hat Inc.
+
+  This program and the accompanying materials are licensed and made
+  available under the terms and conditions of the BSD License which
+  accompanies this distribution. The full text of the license may be
+  found at http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
+  BASIS, WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
+  EXPRESS OR IMPLIED.
+
+**/
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define RAMFB_FORMAT  0x34325258 /* DRM_FORMAT_XRGB */
+#define RAMFB_BPP 4
+
+#pragma pack (1)
+typedef struct RAMFB_CONFIG {
+  UINT64 Address;
+  UINT32 FourCC;
+  UINT32 Flags;
+  UINT32 Width;
+  UINT32 Height;
+  UINT32 Stride;
+} RAMFB_CONFIG;
+#pragma pack ()
+
+STATIC EFI_HANDLEmRamfbHandle;
+STATIC EFI_HANDLEmGopHandle;
+STATIC FRAME_BUFFER_CONFIGURE*mQemuRamfbFrameBufferBltConfigure;
+STATIC UINTN mQemuRamfbFrameBufferBltConfigureSize;
+STATIC FIRMWARE_CONFIG_ITEM  mRamfbFwCfgItem;
+
+STATIC EFI_GRAPHICS_OUTPUT_MODE_INFORMATION mQemuRamfbModeInfo[] = {
+  {
+0,// Version
+640,  // HorizontalResolution
+480,  // VerticalResolution
+  },{
+0,// Version
+800,  // HorizontalResolution
+600,  // VerticalResolution
+  },{
+0,// Version
+1024, // HorizontalResolution
+768,  // VerticalResolution
+  }
+};
+
+STATIC EFI_GRAPHICS_OUTPUT_PROTOCOL_MODE mQemuRamfbMode = {
+  ARRAY_SIZE (mQemuRamfbModeInfo),// MaxMode
+  0,  // Mode
+  mQemuRamfbModeInfo, // Info
+  sizeof (EFI_GRAPHICS_OUTPUT_MODE_INFORMATION),  // SizeOfInfo
+};
+
+STATIC
+EFI_STATUS
+EFIAPI
+QemuRamfbGraphicsOutputQueryMode (
+  IN  EFI_GRAPHICS_OUTPUT_PROTOCOL  *This,
+  IN  UINT32ModeNumber,
+  OUT UINTN *SizeOfInfo,
+  OUT EFI_GRAPHICS_OUTPUT_MODE_INFORMATION  **Info
+  )
+{
+  EFI_GRAPHICS_OUTPUT_MODE_INFORMATION  *ModeInfo;
+
+  if (Info == NULL || SizeOfInfo == NULL ||
+  ModeNumber >= mQemuRamfbMode.MaxMode) {
+return EFI_INVALID_PARAMETER;
+  }
+  ModeInfo = [ModeNumber];
+
+  *Info = AllocateCopyPool (sizeof (EFI_GRAPHICS_OUTPUT_MODE_INFORMATION),
+ModeInfo);
+  if (*Info == NULL) {
+return EFI_OUT_OF_RESOURCES;
+  }
+  *SizeOfInfo = sizeof (EFI_GRAPHICS_OUTPUT_MODE_INFORMATION);
+
+  return EFI_SUCCESS;
+}
+
+STATIC
+EFI_STATUS
+EFIAPI
+QemuRamfbGraphicsOutputSetMode (
+  IN  EFI_GRAPHICS_OUTPUT_PROTOCOL *This,
+  IN  UINT32   ModeNumber
+  )
+{
+  EFI_GRAPHICS_OUTPUT_MODE_INFORMATION  *ModeInfo;
+  RAMFB_CONFIG  Config;
+  EFI_GRAPHICS_OUTPUT_BLT_PIXEL Black;
+  RETURN_STATUS Status;
+
+  if (ModeNumber >= mQemuRamfbMode.MaxMode) {
+return EFI_UNSUPPORTED;
+  }
+  ModeInfo = [ModeNumber];
+
+  DEBUG ((DEBUG_INFO, "Ramfb: SetMode %u (%ux%u)\n", ModeNumber,
+ModeInfo->HorizontalResolution, ModeInfo->VerticalResolution));
+
+  Config.Address = SwapBytes64 (mQemuRamfbMode.FrameBufferBase);
+  Config.FourCC  = SwapBytes32 (RAMFB_FORMAT);
+  Config.Flags   = SwapBytes32 (0);
+  Config.Width   = SwapBytes32 (ModeInfo->HorizontalResolution);
+  Config.Height  = SwapBytes32 (ModeInfo->VerticalResolution);
+  Config.Stride  = SwapBytes32 (ModeInfo->HorizontalResolution * RAMFB_BPP);
+
+  Status = FrameBufferBltConfigure (
+ (VOID*)(UINTN)mQemuRamfbMode.FrameBufferBase,
+ ModeInfo,
+ mQemuRamfbFrameBufferBltConfigure,
+ 
+ );
+
+  if (Status == RETURN_BUFFER_TOO_SMALL) {
+if (mQemuRamfbFrameBufferBltConfigure != NULL) {
+  Fr

[edk2] [PATCH v3 1/4] OvmfPkg: add QEMU_RAMFB_GUID

[Gerd Hoffmann]

Add GUID header file for the QemuRamfbDxe driver.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Gerd Hoffmann 
Reviewed-by: Laszlo Ersek 
---
 OvmfPkg/Include/Guid/QemuRamfb.h | 25 +
 OvmfPkg/OvmfPkg.dec  |  1 +
 2 files changed, 26 insertions(+)
 create mode 100644 OvmfPkg/Include/Guid/QemuRamfb.h

diff --git a/OvmfPkg/Include/Guid/QemuRamfb.h b/OvmfPkg/Include/Guid/QemuRamfb.h
new file mode 100644
index 00..5c9dffb1f0
--- /dev/null
+++ b/OvmfPkg/Include/Guid/QemuRamfb.h
@@ -0,0 +1,25 @@
+/** @file
+  Recommended GUID to be used in the Vendor Hardware device path nodes that
+  identify qemu ramfb devices.
+
+  Copyright (C) 2018, Red Hat, Inc.
+
+  This program and the accompanying materials are licensed and made available
+  under the terms and conditions of the BSD License that accompanies this
+  distribution. The full text of the license may be found at
+  http://opensource.org/licenses/bsd-license.php.
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, WITHOUT
+  WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#ifndef __QEMU_RAMFB_H__
+#define __QEMU_RAMFB_H__
+
+#define QEMU_RAMFB_GUID \
+{0x557423a1, 0x63ab, 0x406c, {0xbe, 0x7e, 0x91, 0xcd, 0xbc, 0x08, 0xc4, 0x57}}
+
+extern EFI_GUID gQemuRamfbGuid;
+
+#endif
diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index dc5597db41..7666297cf8 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -75,6 +75,7 @@
   gEfiXenInfoGuid = {0xd3b46f3b, 0xd441, 0x1244, {0x9a, 
0x12, 0x0, 0x12, 0x27, 0x3f, 0xc1, 0x4d}}
   gOvmfPlatformConfigGuid = {0x7235c51c, 0x0c80, 0x4cab, {0x87, 
0xac, 0x3b, 0x08, 0x4a, 0x63, 0x04, 0xb1}}
   gVirtioMmioTransportGuid= {0x837dca9e, 0xe874, 0x4d82, {0xb2, 
0x9a, 0x23, 0xfe, 0x0e, 0x23, 0xd1, 0xe2}}
+  gQemuRamfbGuid  = {0x557423a1, 0x63ab, 0x406c, {0xbe, 
0x7e, 0x91, 0xcd, 0xbc, 0x08, 0xc4, 0x57}}
   gXenBusRootDeviceGuid   = {0xa732241f, 0x383d, 0x4d9c, {0x8a, 
0xe1, 0x8e, 0x09, 0x83, 0x75, 0x89, 0xd7}}
   gRootBridgesConnectedEventGroupGuid = {0x24a2d66f, 0xeedd, 0x4086, {0x90, 
0x42, 0xf2, 0x6e, 0x47, 0x97, 0xee, 0x69}}
 
-- 
2.9.3

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v2 0/4] Add QemuRamfbDxe driver

[Gerd Hoffmann]

  Hi,

This is the efi driver for qemu ramfb, a simple boot framebuffer.  Qemu
patches just have been posted to qemu-devel.

v2: tons of codestyle fixes, some control flow tweaks.

cheers,
  Gerd

Gerd Hoffmann (4):
  OvmfPkg: add QEMU_RAMFB_GUID
  OvmfPkg: add QemuRamfbDxe
  OvmfPkg: add QemuRamfb to platform console
  ArmVirtPkg: add QemuRamfbDxe

 OvmfPkg/Include/Guid/QemuRamfb.h   |  25 ++
 .../Library/PlatformBootManagerLib/PlatformData.c  |  51 +++
 OvmfPkg/QemuRamfbDxe/QemuRamfb.c   | 396 +
 ArmVirtPkg/ArmVirtQemu.dsc |   2 +
 ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc   |   1 +
 ArmVirtPkg/ArmVirtQemuKernel.dsc   |   2 +
 OvmfPkg/OvmfPkg.dec|   1 +
 OvmfPkg/OvmfPkgIa32.dsc|   1 +
 OvmfPkg/OvmfPkgIa32.fdf|   1 +
 OvmfPkg/OvmfPkgIa32X64.dsc |   1 +
 OvmfPkg/OvmfPkgIa32X64.fdf |   1 +
 OvmfPkg/OvmfPkgX64.dsc |   1 +
 OvmfPkg/OvmfPkgX64.fdf |   1 +
 OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf  |  52 +++
 14 files changed, 536 insertions(+)
 create mode 100644 OvmfPkg/Include/Guid/QemuRamfb.h
 create mode 100644 OvmfPkg/QemuRamfbDxe/QemuRamfb.c
 create mode 100644 OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf

-- 
2.9.3

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v2 1/4] OvmfPkg: add QEMU_RAMFB_GUID

[Gerd Hoffmann]

Add GUID header file for the QemuRamfbDxe driver.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Gerd Hoffmann 
---
 OvmfPkg/Include/Guid/QemuRamfb.h | 25 +
 OvmfPkg/OvmfPkg.dec  |  1 +
 2 files changed, 26 insertions(+)
 create mode 100644 OvmfPkg/Include/Guid/QemuRamfb.h

diff --git a/OvmfPkg/Include/Guid/QemuRamfb.h b/OvmfPkg/Include/Guid/QemuRamfb.h
new file mode 100644
index 00..5c9dffb1f0
--- /dev/null
+++ b/OvmfPkg/Include/Guid/QemuRamfb.h
@@ -0,0 +1,25 @@
+/** @file
+  Recommended GUID to be used in the Vendor Hardware device path nodes that
+  identify qemu ramfb devices.
+
+  Copyright (C) 2018, Red Hat, Inc.
+
+  This program and the accompanying materials are licensed and made available
+  under the terms and conditions of the BSD License that accompanies this
+  distribution. The full text of the license may be found at
+  http://opensource.org/licenses/bsd-license.php.
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, WITHOUT
+  WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#ifndef __QEMU_RAMFB_H__
+#define __QEMU_RAMFB_H__
+
+#define QEMU_RAMFB_GUID \
+{0x557423a1, 0x63ab, 0x406c, {0xbe, 0x7e, 0x91, 0xcd, 0xbc, 0x08, 0xc4, 0x57}}
+
+extern EFI_GUID gQemuRamfbGuid;
+
+#endif
diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index dc5597db41..7666297cf8 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -75,6 +75,7 @@
   gEfiXenInfoGuid = {0xd3b46f3b, 0xd441, 0x1244, {0x9a, 
0x12, 0x0, 0x12, 0x27, 0x3f, 0xc1, 0x4d}}
   gOvmfPlatformConfigGuid = {0x7235c51c, 0x0c80, 0x4cab, {0x87, 
0xac, 0x3b, 0x08, 0x4a, 0x63, 0x04, 0xb1}}
   gVirtioMmioTransportGuid= {0x837dca9e, 0xe874, 0x4d82, {0xb2, 
0x9a, 0x23, 0xfe, 0x0e, 0x23, 0xd1, 0xe2}}
+  gQemuRamfbGuid  = {0x557423a1, 0x63ab, 0x406c, {0xbe, 
0x7e, 0x91, 0xcd, 0xbc, 0x08, 0xc4, 0x57}}
   gXenBusRootDeviceGuid   = {0xa732241f, 0x383d, 0x4d9c, {0x8a, 
0xe1, 0x8e, 0x09, 0x83, 0x75, 0x89, 0xd7}}
   gRootBridgesConnectedEventGroupGuid = {0x24a2d66f, 0xeedd, 0x4086, {0x90, 
0x42, 0xf2, 0x6e, 0x47, 0x97, 0xee, 0x69}}
 
-- 
2.9.3

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v2 2/4] OvmfPkg: add QemuRamfbDxe

[Gerd Hoffmann]

Add a driver for the qemu ramfb display device.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Gerd Hoffmann 
---
 OvmfPkg/QemuRamfbDxe/QemuRamfb.c  | 396 ++
 OvmfPkg/OvmfPkgIa32.dsc   |   1 +
 OvmfPkg/OvmfPkgIa32.fdf   |   1 +
 OvmfPkg/OvmfPkgIa32X64.dsc|   1 +
 OvmfPkg/OvmfPkgIa32X64.fdf|   1 +
 OvmfPkg/OvmfPkgX64.dsc|   1 +
 OvmfPkg/OvmfPkgX64.fdf|   1 +
 OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf |  52 +
 8 files changed, 454 insertions(+)
 create mode 100644 OvmfPkg/QemuRamfbDxe/QemuRamfb.c
 create mode 100644 OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf

diff --git a/OvmfPkg/QemuRamfbDxe/QemuRamfb.c b/OvmfPkg/QemuRamfbDxe/QemuRamfb.c
new file mode 100644
index 00..00a2875e99
--- /dev/null
+++ b/OvmfPkg/QemuRamfbDxe/QemuRamfb.c
@@ -0,0 +1,396 @@
+/** @file
+  This driver is a implementation of the Graphics Output Protocol
+  for the QEMU ramfb device.
+
+  Copyright (c) 2018, Red Hat Inc.
+
+  This program and the accompanying materials
+  are licensed and made available under the terms and conditions of the BSD 
License
+  which accompanies this distribution. The full text of the license may be 
found at
+  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define RAMFB_FORMAT  0x34325258 /* DRM_FORMAT_XRGB */
+#define RAMFB_BPP 4
+
+#pragma pack (1)
+typedef struct RAMFB_CONFIG {
+  UINT64 Address;
+  UINT32 FourCC;
+  UINT32 Flags;
+  UINT32 Width;
+  UINT32 Height;
+  UINT32 Stride;
+} RAMFB_CONFIG;
+#pragma pack ()
+
+static EFI_HANDLEmRamfbHandle;
+static EFI_HANDLEmGopHandle;
+static FRAME_BUFFER_CONFIGURE*mQemuRamfbFrameBufferBltConfigure;
+static UINTN mQemuRamfbFrameBufferBltConfigureSize;
+static FIRMWARE_CONFIG_ITEM  mRamFbFwCfgItem;
+
+static EFI_GRAPHICS_OUTPUT_MODE_INFORMATION mQemuRamfbModeInfo[] = {
+  {
+0,// Version
+640,  // HorizontalResolution
+480,  // VerticalResolution
+  },{
+0,// Version
+800,  // HorizontalResolution
+600,  // VerticalResolution
+  },{
+0,// Version
+1024, // HorizontalResolution
+768,  // VerticalResolution
+  }
+};
+#define mQemuRamfbModeCount ARRAY_SIZE(mQemuRamfbModeInfo)
+
+static EFI_GRAPHICS_OUTPUT_PROTOCOL_MODE mQemuRamfbMode = {
+  mQemuRamfbModeCount,// MaxMode
+  0,  // Mode
+  mQemuRamfbModeInfo, // Info
+  sizeof (EFI_GRAPHICS_OUTPUT_MODE_INFORMATION),  // SizeOfInfo
+};
+
+static
+EFI_STATUS
+EFIAPI
+QemuRamfbGraphicsOutputQueryMode (
+  IN  EFI_GRAPHICS_OUTPUT_PROTOCOL  *This,
+  IN  UINT32ModeNumber,
+  OUT UINTN *SizeOfInfo,
+  OUT EFI_GRAPHICS_OUTPUT_MODE_INFORMATION  **Info
+  )
+{
+  EFI_GRAPHICS_OUTPUT_MODE_INFORMATION  *ModeInfo;
+
+  if (Info == NULL || SizeOfInfo == NULL || ModeNumber >= 
mQemuRamfbMode.MaxMode) {
+return EFI_INVALID_PARAMETER;
+  }
+  ModeInfo = [ModeNumber];
+
+  *Info = AllocateCopyPool (sizeof (EFI_GRAPHICS_OUTPUT_MODE_INFORMATION),
+ModeInfo);
+  if (*Info == NULL) {
+return EFI_OUT_OF_RESOURCES;
+  }
+  *SizeOfInfo = sizeof (EFI_GRAPHICS_OUTPUT_MODE_INFORMATION);
+
+  return EFI_SUCCESS;
+}
+
+static
+EFI_STATUS
+EFIAPI
+QemuRamfbGraphicsOutputSetMode (
+  IN  EFI_GRAPHICS_OUTPUT_PROTOCOL *This,
+  IN  UINT32   ModeNumber
+  )
+{
+  EFI_GRAPHICS_OUTPUT_MODE_INFORMATION  *ModeInfo;
+  RAMFB_CONFIG  Config;
+  EFI_GRAPHICS_OUTPUT_BLT_PIXEL Black;
+  RETURN_STATUS Status;
+
+  if (ModeNumber >= mQemuRamfbMode.MaxMode) {
+return EFI_UNSUPPORTED;
+  }
+  ModeInfo = [ModeNumber];
+
+  DEBUG ((DEBUG_INFO, "Ramfb: SetMode %u (%ux%u)\n", ModeNumber,
+ModeInfo->HorizontalResolution, ModeInfo->VerticalResolution));
+
+  Config.Address = SwapBytes64 (mQemuRamfbMode.FrameBufferBase);
+  Config.FourCC  = SwapBytes32 (RAMFB_FORMAT);
+  Config.Flags   = SwapBytes32 (0);
+  Config.Width   = SwapBytes32 (ModeInfo->HorizontalResolution);
+  Config.Height  = SwapBytes32 (ModeInfo->VerticalResolution);
+  Config.Stride  = SwapBytes32 (ModeInfo->HorizontalResolution * RAMFB_BPP);
+
+  Status = FrameBufferBltConfigure (
+ (VOID*)(UINTN)mQemuRamfbMode.FrameBufferBase,
+ ModeInfo,
+ mQemuRamfbFrameBufferBltConfigure,
+ 
+ );
+
+  if (Status == RETURN_BUFFER_TOO_SMALL) {
+if (mQemuRamfbFrameBuff

[edk2] [PATCH v2 4/4] ArmVirtPkg: add QemuRamfbDxe

[Gerd Hoffmann]

Add QemuRamfbDxe to dsc and fdf files for ArmVirt package.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Gerd Hoffmann 
---
 ArmVirtPkg/ArmVirtQemu.dsc   | 2 ++
 ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc | 1 +
 ArmVirtPkg/ArmVirtQemuKernel.dsc | 2 ++
 3 files changed, 5 insertions(+)

diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
index d74feb709c..744d127a10 100644
--- a/ArmVirtPkg/ArmVirtQemu.dsc
+++ b/ArmVirtPkg/ArmVirtQemu.dsc
@@ -57,6 +57,7 @@
   BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf
   
PlatformBootManagerLib|ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
   
CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
+  
FrameBufferBltLib|MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf
   QemuBootOrderLib|OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
   FileExplorerLib|MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf
   
PciPcdProducerLib|ArmVirtPkg/Library/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
@@ -391,6 +392,7 @@
   #
   # Video support
   #
+  OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf
   OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
   OvmfPkg/PlatformDxe/Platform.inf
 
diff --git a/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc 
b/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
index 89f95b2d99..63a202c788 100644
--- a/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
+++ b/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
@@ -175,6 +175,7 @@ READ_LOCK_STATUS   = TRUE
   #
   # Video support
   #
+  INF OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf
   INF OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
   INF OvmfPkg/PlatformDxe/Platform.inf
 
diff --git a/ArmVirtPkg/ArmVirtQemuKernel.dsc b/ArmVirtPkg/ArmVirtQemuKernel.dsc
index 1e823aeab7..e59f53b728 100644
--- a/ArmVirtPkg/ArmVirtQemuKernel.dsc
+++ b/ArmVirtPkg/ArmVirtQemuKernel.dsc
@@ -57,6 +57,7 @@
   BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf
   
PlatformBootManagerLib|ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
   
CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
+  
FrameBufferBltLib|MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf
   QemuBootOrderLib|OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
   FileExplorerLib|MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf
   
PciPcdProducerLib|ArmVirtPkg/Library/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
@@ -380,6 +381,7 @@
   #
   # Video support
   #
+  OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf
   OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
   OvmfPkg/PlatformDxe/Platform.inf
 
-- 
2.9.3

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v2 3/4] OvmfPkg: add QemuRamfb to platform console

[Gerd Hoffmann]

Add QemuRamfbDxe device path to the list of platform console devices,
so ConSplitter will pick up the device even though it isn't a PCI GPU.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Gerd Hoffmann 
---
 .../Library/PlatformBootManagerLib/PlatformData.c  | 51 ++
 1 file changed, 51 insertions(+)

diff --git a/OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c 
b/OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c
index a50cd7bcaf..1250a6d351 100644
--- a/OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c
+++ b/OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c
@@ -14,6 +14,7 @@
 **/
 
 #include "BdsPlatform.h"
+#include 
 
 //
 // Debug Agent UART Device Path structure
@@ -37,6 +38,17 @@ typedef struct {
 } USB_KEYBOARD_DEVICE_PATH;
 #pragma pack ()
 
+//
+// QemuRamfb Device Path structure
+//
+#pragma pack (1)
+typedef struct {
+  VENDOR_DEVICE_PATHVendor;
+  ACPI_ADR_DEVICE_PATH  AcpiAdr;
+  EFI_DEVICE_PATH_PROTOCOL  End;
+} VENDOR_RAMFB_DEVICE_PATH;
+#pragma pack ()
+
 ACPI_HID_DEVICE_PATH   gPnpPs2KeyboardDeviceNode  = gPnpPs2Keyboard;
 ACPI_HID_DEVICE_PATH   gPnp16550ComPortDeviceNode = gPnp16550ComPort;
 UART_DEVICE_PATH   gUartDeviceNode= gUart;
@@ -100,6 +112,41 @@ STATIC USB_KEYBOARD_DEVICE_PATH gUsbKeyboardDevicePath = {
   gEndEntire
 };
 
+STATIC VENDOR_RAMFB_DEVICE_PATH gQemuRamfbDevicePath = {
+  {
+{
+  HARDWARE_DEVICE_PATH,
+  HW_VENDOR_DP,
+  {
+(UINT8) (sizeof (VENDOR_DEVICE_PATH)),
+(UINT8) ((sizeof (VENDOR_DEVICE_PATH)) >> 8)
+  }
+},
+QEMU_RAMFB_GUID,
+  },
+  {
+{
+  ACPI_DEVICE_PATH,
+  ACPI_ADR_DP,
+  {
+(UINT8) (sizeof (ACPI_ADR_DEVICE_PATH)),
+(UINT8) ((sizeof (ACPI_ADR_DEVICE_PATH)) >> 8)
+  }
+},
+ACPI_DISPLAY_ADR (
+  1,   // DeviceIdScheme
+  0,   // HeadId
+  0,   // NonVgaOutput
+  1,   // BiosCanDetect
+  0,   // VendorInfo
+  ACPI_ADR_DISPLAY_TYPE_EXTERNAL_DIGITAL,  // Type
+  0,   // Port
+  0// Index
+  ),
+  },
+  gEndEntire
+};
+
 //
 // Predefined platform default console device path
 //
@@ -113,6 +160,10 @@ PLATFORM_CONSOLE_CONNECT_ENTRY   gPlatformConsole[] = {
 CONSOLE_IN
   },
   {
+(EFI_DEVICE_PATH_PROTOCOL *),
+CONSOLE_OUT
+  },
+  {
 NULL,
 0
   }
-- 
2.9.3

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 0/4] Add QemuRamfbDxe driver

[Gerd Hoffmann]

  Hi,

> - What happens in the UEFI shell if you do recursive connect/disconnect
> cycles for all handles in the system? (Preferably initiated from serial.)

Seems to work fine (tried "disconnect -a" and "connect").

> - What happens if you locate the parent handle (with the VenHw node)
> and/or the child handle (with the GOP on it), and try to disconnect them?

How can I do that?

> - Have you tested mode changes with the MODE command?

Yes, works.

cheers,
  Gerd

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 2/4] OvmfPkg: add QemuRamfbDxe

[Gerd Hoffmann]

  Hi,

> > +  {
> > +.HorizontalResolution  = 640,
> > +.VerticalResolution= 480,
> > +  },{
> > +.HorizontalResolution  = 800,
> > +.VerticalResolution= 600,
> > +  },{
> > +.HorizontalResolution  = 1024,
> > +.VerticalResolution= 768,
> > +  }
> > +};
> 
> (10) In edk2 we cannot use designated initializers. I suggest (for
> example) assigning these values in the entry point function.

Really?  C99 is almost 20 years old now ...
Are there compilers left without C99 support which edk2 still supports?

> In general, in edk2 there are two accepted indentation styles for
> function calls that extend to multiple lines:
> 
> variant #1: all arguments (including the first one) on separate lines,
> with the closing paren also on a separate line:
> 
>   Status = StructPointer->Function (
> Arg1,
> Arg2,
> Arg3
> );

Hmm, pretty unusual, which is bad for editor auto-indent support.
Anyone knows tricks to teack emacs that style?

cheers,
  Gerd

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH 2/4] OvmfPkg: add QemuRamfbDxe

[Gerd Hoffmann]

Add a driver for the qemu ramfb display device.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Gerd Hoffmann 
---
 OvmfPkg/QemuRamfbDxe/QemuRamfb.c  | 308 ++
 OvmfPkg/OvmfPkgIa32.dsc   |   1 +
 OvmfPkg/OvmfPkgIa32.fdf   |   1 +
 OvmfPkg/OvmfPkgIa32X64.dsc|   1 +
 OvmfPkg/OvmfPkgIa32X64.fdf|   1 +
 OvmfPkg/OvmfPkgX64.dsc|   1 +
 OvmfPkg/OvmfPkgX64.fdf|   1 +
 OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf |  34 
 8 files changed, 348 insertions(+)
 create mode 100644 OvmfPkg/QemuRamfbDxe/QemuRamfb.c
 create mode 100644 OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf

diff --git a/OvmfPkg/QemuRamfbDxe/QemuRamfb.c b/OvmfPkg/QemuRamfbDxe/QemuRamfb.c
new file mode 100644
index 00..f04a314c24
--- /dev/null
+++ b/OvmfPkg/QemuRamfbDxe/QemuRamfb.c
@@ -0,0 +1,308 @@
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define RAMFB_FORMAT  0x34325258 /* DRM_FORMAT_XRGB */
+#define RAMFB_BPP 4
+
+EFI_GUID gQemuRamfbGuid = QEMU_RAMFB_GUID;
+
+typedef struct RAMFB_CONFIG {
+  UINT64 Address;
+  UINT32 FourCC;
+  UINT32 Flags;
+  UINT32 Width;
+  UINT32 Height;
+  UINT32 Stride;
+} RAMFB_CONFIG;
+
+EFI_HANDLERamfbHandle;
+EFI_HANDLEGopHandle;
+FRAME_BUFFER_CONFIGURE*QemuRamfbFrameBufferBltConfigure;
+UINTN QemuRamfbFrameBufferBltConfigureSize;
+
+EFI_GRAPHICS_OUTPUT_MODE_INFORMATION QemuRamfbModeInfo[] = {
+  {
+.HorizontalResolution  = 640,
+.VerticalResolution= 480,
+  },{
+.HorizontalResolution  = 800,
+.VerticalResolution= 600,
+  },{
+.HorizontalResolution  = 1024,
+.VerticalResolution= 768,
+  }
+};
+#define QemuRamfbModeCount 
(sizeof(QemuRamfbModeInfo)/sizeof(QemuRamfbModeInfo[0]))
+
+EFI_GRAPHICS_OUTPUT_PROTOCOL_MODE QemuRamfbMode = {
+  .MaxMode   = QemuRamfbModeCount,
+  .Mode  = 0,
+  .Info  = QemuRamfbModeInfo,
+  .SizeOfInfo= sizeof(EFI_GRAPHICS_OUTPUT_MODE_INFORMATION),
+};
+
+EFI_STATUS
+EFIAPI
+QemuRamfbGraphicsOutputQueryMode (
+  IN  EFI_GRAPHICS_OUTPUT_PROTOCOL  *This,
+  IN  UINT32ModeNumber,
+  OUT UINTN *SizeOfInfo,
+  OUT EFI_GRAPHICS_OUTPUT_MODE_INFORMATION  **Info
+  )
+{
+  EFI_GRAPHICS_OUTPUT_MODE_INFORMATION  *ModeInfo;
+
+  if (Info == NULL || SizeOfInfo == NULL || ModeNumber > 
QemuRamfbMode.MaxMode) {
+return EFI_INVALID_PARAMETER;
+  }
+  ModeInfo = [ModeNumber];
+
+  *Info = AllocateCopyPool (sizeof (EFI_GRAPHICS_OUTPUT_MODE_INFORMATION),
+ModeInfo);
+  if (*Info == NULL) {
+return EFI_OUT_OF_RESOURCES;
+  }
+  *SizeOfInfo = sizeof (EFI_GRAPHICS_OUTPUT_MODE_INFORMATION);
+
+  return EFI_SUCCESS;
+}
+
+EFI_STATUS
+EFIAPI
+QemuRamfbGraphicsOutputSetMode (
+  IN  EFI_GRAPHICS_OUTPUT_PROTOCOL *This,
+  IN  UINT32   ModeNumber
+  )
+{
+  EFI_GRAPHICS_OUTPUT_MODE_INFORMATION  *ModeInfo;
+  RAMFB_CONFIG  Config;
+  EFI_GRAPHICS_OUTPUT_BLT_PIXEL Black;
+  RETURN_STATUS Ret;
+  FIRMWARE_CONFIG_ITEM  Item;
+  UINTN Size;
+
+  if (ModeNumber > QemuRamfbMode.MaxMode) {
+return EFI_UNSUPPORTED;
+  }
+  ModeInfo = [ModeNumber];
+
+  DEBUG ((EFI_D_INFO, "Ramfb: SetMode %d (%dx%d)\n", ModeNumber,
+  ModeInfo->HorizontalResolution,
+  ModeInfo->VerticalResolution));
+
+  QemuRamfbMode.Mode = ModeNumber;
+  QemuRamfbMode.Info = ModeInfo;
+
+  Config.Address = SwapBytes64( QemuRamfbMode.FrameBufferBase );
+  Config.FourCC  = SwapBytes32( RAMFB_FORMAT );
+  Config.Flags   = SwapBytes32( 0 );
+  Config.Width   = SwapBytes32( ModeInfo->HorizontalResolution );
+  Config.Height  = SwapBytes32( ModeInfo->VerticalResolution );
+  Config.Stride  = SwapBytes32( ModeInfo->HorizontalResolution * RAMFB_BPP );
+
+  QemuFwCfgFindFile("etc/ramfb", , );
+  QemuFwCfgSelectItem(Item);
+  QemuFwCfgWriteBytes(sizeof(Config), );
+
+  Ret = FrameBufferBltConfigure (
+(VOID*)(UINTN)QemuRamfbMode.FrameBufferBase,
+ModeInfo,
+QemuRamfbFrameBufferBltConfigure,
+);
+
+  if (Ret == RETURN_BUFFER_TOO_SMALL) {
+if (QemuRamfbFrameBufferBltConfigure != NULL) {
+  FreePool(QemuRamfbFrameBufferBltConfigure);
+}
+QemuRamfbFrameBufferBltConfigure =
+  AllocatePool(QemuRamfbFrameBufferBltConfigureSize);
+
+Ret = FrameBufferBltConfigure (
+  (VOID*)(UINTN)QemuRamfbMode.FrameBufferBase,
+  ModeInfo,
+  QemuRamfbFrameBufferBltConfigure,
+  );
+  }
+
+  /* clear screen */
+  ZeroMem (, sizeof (Black));
+  Ret = FrameBufferBlt (
+QemuRamfbFrameBufferBltConfigure,
+,
+EfiBltVideo

[edk2] [PATCH 4/4] ArmVirtPkg: add QemuRamfbDxe

[Gerd Hoffmann]

Build wireup for ArmVirt.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Gerd Hoffmann 
---
 ArmVirtPkg/ArmVirtQemu.dsc   | 2 ++
 ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc | 1 +
 ArmVirtPkg/ArmVirtQemuKernel.dsc | 2 ++
 3 files changed, 5 insertions(+)

diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
index d74feb709c..744d127a10 100644
--- a/ArmVirtPkg/ArmVirtQemu.dsc
+++ b/ArmVirtPkg/ArmVirtQemu.dsc
@@ -57,6 +57,7 @@
   BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf
   
PlatformBootManagerLib|ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
   
CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
+  
FrameBufferBltLib|MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf
   QemuBootOrderLib|OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
   FileExplorerLib|MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf
   
PciPcdProducerLib|ArmVirtPkg/Library/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
@@ -391,6 +392,7 @@
   #
   # Video support
   #
+  OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf
   OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
   OvmfPkg/PlatformDxe/Platform.inf
 
diff --git a/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc 
b/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
index 89f95b2d99..63a202c788 100644
--- a/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
+++ b/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
@@ -175,6 +175,7 @@ READ_LOCK_STATUS   = TRUE
   #
   # Video support
   #
+  INF OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf
   INF OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
   INF OvmfPkg/PlatformDxe/Platform.inf
 
diff --git a/ArmVirtPkg/ArmVirtQemuKernel.dsc b/ArmVirtPkg/ArmVirtQemuKernel.dsc
index 1e823aeab7..e59f53b728 100644
--- a/ArmVirtPkg/ArmVirtQemuKernel.dsc
+++ b/ArmVirtPkg/ArmVirtQemuKernel.dsc
@@ -57,6 +57,7 @@
   BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf
   
PlatformBootManagerLib|ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
   
CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
+  
FrameBufferBltLib|MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf
   QemuBootOrderLib|OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
   FileExplorerLib|MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf
   
PciPcdProducerLib|ArmVirtPkg/Library/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
@@ -380,6 +381,7 @@
   #
   # Video support
   #
+  OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf
   OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
   OvmfPkg/PlatformDxe/Platform.inf
 
-- 
2.9.3

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH 3/4] OvmfPkg: add QemuRamfb to platform console

[Gerd Hoffmann]

Add QemuRamfbDxe device path to the list of platform console devices,
so ConSplitter will pick up the device even though it isn't a PCI GPU.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Gerd Hoffmann 
---
 .../Library/PlatformBootManagerLib/PlatformData.c  | 44 ++
 1 file changed, 44 insertions(+)

diff --git a/OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c 
b/OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c
index a50cd7bcaf..6202516971 100644
--- a/OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c
+++ b/OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c
@@ -14,6 +14,7 @@
 **/
 
 #include "BdsPlatform.h"
+#include 
 
 //
 // Debug Agent UART Device Path structure
@@ -37,6 +38,17 @@ typedef struct {
 } USB_KEYBOARD_DEVICE_PATH;
 #pragma pack ()
 
+//
+// QemuRamfb Device Path structure
+//
+#pragma pack(1)
+typedef struct {
+  VENDOR_DEVICE_PATHVendor;
+  ACPI_ADR_DEVICE_PATH  AcpiAdr;
+  EFI_DEVICE_PATH_PROTOCOL  End;
+} VENDOR_RAMFB_DEVICE_PATH;
+#pragma pack()
+
 ACPI_HID_DEVICE_PATH   gPnpPs2KeyboardDeviceNode  = gPnpPs2Keyboard;
 ACPI_HID_DEVICE_PATH   gPnp16550ComPortDeviceNode = gPnp16550ComPort;
 UART_DEVICE_PATH   gUartDeviceNode= gUart;
@@ -100,6 +112,34 @@ STATIC USB_KEYBOARD_DEVICE_PATH gUsbKeyboardDevicePath = {
   gEndEntire
 };
 
+STATIC VENDOR_RAMFB_DEVICE_PATH gQemuRamfbDevicePath = {
+  {
+{
+  HARDWARE_DEVICE_PATH,
+  HW_VENDOR_DP,
+  {
+(UINT8) (sizeof (VENDOR_DEVICE_PATH)),
+(UINT8) ((sizeof (VENDOR_DEVICE_PATH)) >> 8)
+  }
+},
+QEMU_RAMFB_GUID,
+  },
+  {
+{
+  ACPI_DEVICE_PATH,
+  ACPI_ADR_DP,
+  {
+(UINT8) (sizeof (ACPI_ADR_DEVICE_PATH)),
+(UINT8) ((sizeof (ACPI_ADR_DEVICE_PATH)) >> 8)
+  }
+},
+ACPI_DISPLAY_ADR (1, 0, 0, 1, 0,
+  ACPI_ADR_DISPLAY_TYPE_EXTERNAL_DIGITAL,
+  0, 0)
+  },
+  gEndEntire
+};
+
 //
 // Predefined platform default console device path
 //
@@ -113,6 +153,10 @@ PLATFORM_CONSOLE_CONNECT_ENTRY   gPlatformConsole[] = {
 CONSOLE_IN
   },
   {
+(EFI_DEVICE_PATH_PROTOCOL *),
+CONSOLE_OUT
+  },
+  {
 NULL,
 0
   }
-- 
2.9.3

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH 0/4] Add QemuRamfbDxe driver

[Gerd Hoffmann]

This is the efi driver for qemu ramfb, a simple boot framebuffer.
Qemu patches just have been posted to qemu-devel.

Gerd Hoffmann (4):
  OvmfPkg: add QEMU_RAMFB_GUID
  OvmfPkg: add QemuRamfbDxe
  OvmfPkg: add QemuRamfb to platform console
  ArmVirtPkg: add QemuRamfbDxe

 OvmfPkg/Include/Guid/QemuRamfb.h   |  25 ++
 .../Library/PlatformBootManagerLib/PlatformData.c  |  44 +++
 OvmfPkg/QemuRamfbDxe/QemuRamfb.c   | 308 +
 ArmVirtPkg/ArmVirtQemu.dsc |   2 +
 ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc   |   1 +
 ArmVirtPkg/ArmVirtQemuKernel.dsc   |   2 +
 OvmfPkg/OvmfPkg.dec|   1 +
 OvmfPkg/OvmfPkgIa32.dsc|   1 +
 OvmfPkg/OvmfPkgIa32.fdf|   1 +
 OvmfPkg/OvmfPkgIa32X64.dsc |   1 +
 OvmfPkg/OvmfPkgIa32X64.fdf |   1 +
 OvmfPkg/OvmfPkgX64.dsc |   1 +
 OvmfPkg/OvmfPkgX64.fdf |   1 +
 OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf  |  34 +++
 14 files changed, 423 insertions(+)
 create mode 100644 OvmfPkg/Include/Guid/QemuRamfb.h
 create mode 100644 OvmfPkg/QemuRamfbDxe/QemuRamfb.c
 create mode 100644 OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf

-- 
2.9.3

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH 1/4] OvmfPkg: add QEMU_RAMFB_GUID

[Gerd Hoffmann]

Add GUID header file for the QemuRamfbDxe driver.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Gerd Hoffmann 
---
 OvmfPkg/Include/Guid/QemuRamfb.h | 25 +
 OvmfPkg/OvmfPkg.dec  |  1 +
 2 files changed, 26 insertions(+)
 create mode 100644 OvmfPkg/Include/Guid/QemuRamfb.h

diff --git a/OvmfPkg/Include/Guid/QemuRamfb.h b/OvmfPkg/Include/Guid/QemuRamfb.h
new file mode 100644
index 00..878224599d
--- /dev/null
+++ b/OvmfPkg/Include/Guid/QemuRamfb.h
@@ -0,0 +1,25 @@
+/** @file
+  Recommended GUID to be used in the Vendor Hardware device path nodes that
+  identify qemu ramfb devices.
+
+  Copyright (C) 2018, Red Hat, Inc.
+
+  This program and the accompanying materials are licensed and made available
+  under the terms and conditions of the BSD License that accompanies this
+  distribution. The full text of the license may be found at
+  http://opensource.org/licenses/bsd-license.php.
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, WITHOUT
+  WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#ifndef __QEMU_RAMFB_H__
+#define __QEMU_RAMFB_H__
+
+#define QEMU_RAMFB_GUID \
+{0x837dca9e, 0xe874, 0x4d82, {0xb2, 0x9a, 0x23, 0xfe, 0x0e, 0x23, 0xd1, 0xe2}}
+
+extern EFI_GUID gQemuRamfbGuid;
+
+#endif
diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index dc5597db41..a16c22a289 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -75,6 +75,7 @@
   gEfiXenInfoGuid = {0xd3b46f3b, 0xd441, 0x1244, {0x9a, 
0x12, 0x0, 0x12, 0x27, 0x3f, 0xc1, 0x4d}}
   gOvmfPlatformConfigGuid = {0x7235c51c, 0x0c80, 0x4cab, {0x87, 
0xac, 0x3b, 0x08, 0x4a, 0x63, 0x04, 0xb1}}
   gVirtioMmioTransportGuid= {0x837dca9e, 0xe874, 0x4d82, {0xb2, 
0x9a, 0x23, 0xfe, 0x0e, 0x23, 0xd1, 0xe2}}
+  gQemuRamfbGuid  = {0x837dca9e, 0xe874, 0x4d82, {0xb2, 
0x9a, 0x23, 0xfe, 0x0e, 0x23, 0xd1, 0xe2}}
   gXenBusRootDeviceGuid   = {0xa732241f, 0x383d, 0x4d9c, {0x8a, 
0xe1, 0x8e, 0x09, 0x83, 0x75, 0x89, 0xd7}}
   gRootBridgesConnectedEventGroupGuid = {0x24a2d66f, 0xeedd, 0x4086, {0x90, 
0x42, 0xf2, 0x6e, 0x47, 0x97, 0xee, 0x69}}
 
-- 
2.9.3

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH 2/2] OvmfPkg/QemuVideoDxe: Enable DISPLAY_OTHER pci class for qemu stdvga

[Gerd Hoffmann]

This makes QemuVideo bind to the secondary-vga device.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Gerd Hoffmann <kra...@redhat.com>
---
 OvmfPkg/QemuVideoDxe/Driver.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/OvmfPkg/QemuVideoDxe/Driver.c b/OvmfPkg/QemuVideoDxe/Driver.c
index 2d7ad43cb3..73eb2cad05 100644
--- a/OvmfPkg/QemuVideoDxe/Driver.c
+++ b/OvmfPkg/QemuVideoDxe/Driver.c
@@ -54,6 +54,12 @@ QEMU_VIDEO_CARD gQemuVideoCardList[] = {
 QEMU_VIDEO_BOCHS_MMIO,
 L"QEMU Standard VGA"
 },{
+PCI_CLASS_DISPLAY_OTHER,
+0x1234,
+0x,
+QEMU_VIDEO_BOCHS_MMIO,
+L"QEMU Standard VGA (secondary)"
+},{
 PCI_CLASS_DISPLAY_VGA,
 0x1b36,
 0x0100,
-- 
2.9.3

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH 1/2] OvmfPkg/QemuVideoDxe: Add SubClass field to QEMU_VIDEO_CARD

[Gerd Hoffmann]

Then check for PCI_CLASS_DISPLAY_VGA using the new field.
This allows to enable/disable non-vga display classes per
card entry.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Gerd Hoffmann <kra...@redhat.com>
---
 OvmfPkg/QemuVideoDxe/Qemu.h   |  1 +
 OvmfPkg/QemuVideoDxe/Driver.c | 17 +
 2 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/OvmfPkg/QemuVideoDxe/Qemu.h b/OvmfPkg/QemuVideoDxe/Qemu.h
index 7fbb25b3ef..bc49f867a4 100644
--- a/OvmfPkg/QemuVideoDxe/Qemu.h
+++ b/OvmfPkg/QemuVideoDxe/Qemu.h
@@ -96,6 +96,7 @@ typedef enum {
 } QEMU_VIDEO_VARIANT;
 
 typedef struct {
+  UINT8 SubClass;
   UINT16VendorId;
   UINT16DeviceId;
   QEMU_VIDEO_VARIANTVariant;
diff --git a/OvmfPkg/QemuVideoDxe/Driver.c b/OvmfPkg/QemuVideoDxe/Driver.c
index 0dce80e59b..2d7ad43cb3 100644
--- a/OvmfPkg/QemuVideoDxe/Driver.c
+++ b/OvmfPkg/QemuVideoDxe/Driver.c
@@ -30,36 +30,43 @@ EFI_DRIVER_BINDING_PROTOCOL gQemuVideoDriverBinding = {
 
 QEMU_VIDEO_CARD gQemuVideoCardList[] = {
 {
+PCI_CLASS_DISPLAY_VGA,
 CIRRUS_LOGIC_VENDOR_ID,
 CIRRUS_LOGIC_5430_DEVICE_ID,
 QEMU_VIDEO_CIRRUS_5430,
 L"Cirrus 5430"
 },{
+PCI_CLASS_DISPLAY_VGA,
 CIRRUS_LOGIC_VENDOR_ID,
 CIRRUS_LOGIC_5430_ALTERNATE_DEVICE_ID,
 QEMU_VIDEO_CIRRUS_5430,
 L"Cirrus 5430"
 },{
+PCI_CLASS_DISPLAY_VGA,
 CIRRUS_LOGIC_VENDOR_ID,
 CIRRUS_LOGIC_5446_DEVICE_ID,
 QEMU_VIDEO_CIRRUS_5446,
 L"Cirrus 5446"
 },{
+PCI_CLASS_DISPLAY_VGA,
 0x1234,
 0x,
 QEMU_VIDEO_BOCHS_MMIO,
 L"QEMU Standard VGA"
 },{
+PCI_CLASS_DISPLAY_VGA,
 0x1b36,
 0x0100,
 QEMU_VIDEO_BOCHS,
 L"QEMU QXL VGA"
 },{
+PCI_CLASS_DISPLAY_VGA,
 0x1af4,
 0x1050,
 QEMU_VIDEO_BOCHS_MMIO,
 L"QEMU VirtIO VGA"
 },{
+PCI_CLASS_DISPLAY_VGA,
 VMWARE_PCI_VENDOR_ID_VMWARE,
 VMWARE_PCI_DEVICE_ID_VMWARE_SVGA2,
 QEMU_VIDEO_VMWARE_SVGA,
@@ -71,6 +78,7 @@ QEMU_VIDEO_CARD gQemuVideoCardList[] = {
 
 static QEMU_VIDEO_CARD*
 QemuVideoDetect(
+  IN UINT8 SubClass,
   IN UINT16 VendorId,
   IN UINT16 DeviceId
   )
@@ -78,7 +86,8 @@ QemuVideoDetect(
   UINTN Index = 0;
 
   while (gQemuVideoCardList[Index].VendorId != 0) {
-if (gQemuVideoCardList[Index].VendorId == VendorId &&
+if (gQemuVideoCardList[Index].SubClass == SubClass &&
+gQemuVideoCardList[Index].VendorId == VendorId &&
 gQemuVideoCardList[Index].DeviceId == DeviceId) {
   return gQemuVideoCardList + Index;
 }
@@ -141,10 +150,10 @@ QemuVideoControllerDriverSupported (
   }
 
   Status = EFI_UNSUPPORTED;
-  if (!IS_PCI_VGA ()) {
+  if (!IS_PCI_DISPLAY ()) {
 goto Done;
   }
-  Card = QemuVideoDetect(Pci.Hdr.VendorId, Pci.Hdr.DeviceId);
+  Card = QemuVideoDetect(Pci.Hdr.ClassCode[1], Pci.Hdr.VendorId, 
Pci.Hdr.DeviceId);
   if (Card != NULL) {
 DEBUG ((EFI_D_INFO, "QemuVideo: %s detected\n", Card->Name));
 Status = EFI_SUCCESS;
@@ -243,7 +252,7 @@ QemuVideoControllerDriverStart (
   //
   // Determine card variant.
   //
-  Card = QemuVideoDetect(Pci.Hdr.VendorId, Pci.Hdr.DeviceId);
+  Card = QemuVideoDetect(Pci.Hdr.ClassCode[1], Pci.Hdr.VendorId, 
Pci.Hdr.DeviceId);
   if (Card == NULL) {
 Status = EFI_DEVICE_ERROR;
 goto ClosePciIo;
-- 
2.9.3

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v2] OvmfPkg/QemuVideoDxe: round up FrameBufferSize to full page

[Gerd Hoffmann]

Guests do the same, because the framebuffer is mapped somewhere, which
obviously works with page granularity only.

When not rounding up to full page size we get messages like this one
(linux kernel):

efifb: framebuffer at 0x8000, using 1876k, total 1875k
^^
Also sysfb is confused and throws an error:

sysfb: VRAM smaller than advertised

Cc: Phil Dennis-Jordan <p...@philjordan.eu>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Gerd Hoffmann <kra...@redhat.com>
---
 OvmfPkg/QemuVideoDxe/Gop.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/OvmfPkg/QemuVideoDxe/Gop.c b/OvmfPkg/QemuVideoDxe/Gop.c
index d51efc2a83..88142bf376 100644
--- a/OvmfPkg/QemuVideoDxe/Gop.c
+++ b/OvmfPkg/QemuVideoDxe/Gop.c
@@ -69,6 +69,7 @@ QemuVideoCompleteModeData (
   Mode->FrameBufferBase = FrameBufDesc->AddrRangeMin;
   Mode->FrameBufferSize = Info->HorizontalResolution * 
Info->VerticalResolution;
   Mode->FrameBufferSize = Mode->FrameBufferSize * ((ModeData->ColorDepth + 7) 
/ 8);
+  Mode->FrameBufferSize = 
EFI_PAGES_TO_SIZE(EFI_SIZE_TO_PAGES(Mode->FrameBufferSize));
   DEBUG ((EFI_D_INFO, "FrameBufferBase: 0x%Lx, FrameBufferSize: 0x%Lx\n",
 Mode->FrameBufferBase, (UINT64)Mode->FrameBufferSize));
 
@@ -107,6 +108,7 @@ QemuVideoVmwareSvgaCompleteModeData (
 
   Mode->FrameBufferBase = FrameBufDesc->AddrRangeMin + FbOffset;
   Mode->FrameBufferSize = BytesPerLine * Info->VerticalResolution;
+  Mode->FrameBufferSize = 
EFI_PAGES_TO_SIZE(EFI_SIZE_TO_PAGES(Mode->FrameBufferSize));
 
   FreePool (FrameBufDesc);
   return Status;
-- 
2.9.3

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] Add QemuIGDHelperDxe

[Gerd Hoffmann]

Little driver to setup the OpRegion for Intel vgpu devices.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Gerd Hoffmann <kra...@redhat.com>
---
 OvmfPkg/QemuIGDHelperDxe/QemuIGDHelper.c  | 262 ++
 OvmfPkg/OvmfPkgIa32.dsc   |   1 +
 OvmfPkg/OvmfPkgIa32.fdf   |   1 +
 OvmfPkg/OvmfPkgIa32X64.dsc|   1 +
 OvmfPkg/OvmfPkgIa32X64.fdf|   1 +
 OvmfPkg/OvmfPkgX64.dsc|   1 +
 OvmfPkg/OvmfPkgX64.fdf|   1 +
 OvmfPkg/QemuIGDHelperDxe/QemuIGDHelperDxe.inf |  32 
 8 files changed, 300 insertions(+)
 create mode 100644 OvmfPkg/QemuIGDHelperDxe/QemuIGDHelper.c
 create mode 100644 OvmfPkg/QemuIGDHelperDxe/QemuIGDHelperDxe.inf

diff --git a/OvmfPkg/QemuIGDHelperDxe/QemuIGDHelper.c 
b/OvmfPkg/QemuIGDHelperDxe/QemuIGDHelper.c
new file mode 100644
index 00..f314049bb4
--- /dev/null
+++ b/OvmfPkg/QemuIGDHelperDxe/QemuIGDHelper.c
@@ -0,0 +1,262 @@
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+VOID *QemuIGDHelperOpRegion;
+
+EFI_STATUS
+EFIAPI
+QemuIGDHelperControllerDriverSupported (
+  IN EFI_DRIVER_BINDING_PROTOCOL*This,
+  IN EFI_HANDLE Controller,
+  IN EFI_DEVICE_PATH_PROTOCOL   *RemainingDevicePath
+  )
+{
+  EFI_STATUS  Status;
+  EFI_PCI_IO_PROTOCOL *PciIo;
+  PCI_TYPE00  Pci;
+  UINT32  OpRegion;
+
+  Status = gBS->OpenProtocol (
+  Controller,
+  ,
+  (VOID **) ,
+  This->DriverBindingHandle,
+  Controller,
+  EFI_OPEN_PROTOCOL_BY_DRIVER
+  );
+  if (EFI_ERROR (Status)) {
+return Status;
+  }
+
+  Status = PciIo->Pci.Read (
+PciIo,
+EfiPciIoWidthUint32,
+0,
+sizeof (Pci) / sizeof (UINT32),
+
+);
+  if (EFI_ERROR (Status)) {
+goto Done;
+  }
+
+  Status = EFI_UNSUPPORTED;
+  if (!IS_PCI_VGA ()) {
+goto Done;
+  }
+  if (Pci.Hdr.VendorId != 0x8086 /* Intel */) {
+goto Done;
+  }
+
+  DEBUG ((EFI_D_INFO, "IGDHelper: intel gfx %x:%x found\n",
+  Pci.Hdr.VendorId, Pci.Hdr.DeviceId));
+  OpRegion = (UINTN)QemuIGDHelperOpRegion;
+  Status = PciIo->Pci.Write (
+PciIo,
+EfiPciIoWidthUint32,
+0xFC,
+1,
+
+);
+  if (EFI_ERROR (Status)) {
+DEBUG ((EFI_D_INFO, "IGDHelper: write error: %d\n", Status));
+  } else {
+DEBUG ((EFI_D_INFO, "IGDHelper: opregion setup OK\n"));
+  }
+
+Done:
+  gBS->CloseProtocol (
+Controller,
+,
+This->DriverBindingHandle,
+Controller
+);
+
+  return Status;
+}
+
+EFI_STATUS
+EFIAPI
+QemuIGDHelperControllerDriverStart (
+  IN EFI_DRIVER_BINDING_PROTOCOL*This,
+  IN EFI_HANDLE Controller,
+  IN EFI_DEVICE_PATH_PROTOCOL   *RemainingDevicePath
+  )
+{
+  DEBUG ((EFI_D_INFO, "QemuIGDHelperControllerDriverStart\n"));
+  return EFI_SUCCESS;
+}
+
+EFI_STATUS
+EFIAPI
+QemuIGDHelperControllerDriverStop (
+  IN EFI_DRIVER_BINDING_PROTOCOL*This,
+  IN EFI_HANDLE Controller,
+  IN UINTN  NumberOfChildren,
+  IN EFI_HANDLE *ChildHandleBuffer
+  )
+{
+  DEBUG ((EFI_D_INFO, "QemuIGDHelperControllerDriverStop\n"));
+  return EFI_SUCCESS;
+}
+
+EFI_DRIVER_BINDING_PROTOCOL gQemuIGDHelperDriverBinding = {
+  QemuIGDHelperControllerDriverSupported,
+  QemuIGDHelperControllerDriverStart,
+  QemuIGDHelperControllerDriverStop,
+  0x10,
+  NULL,
+  NULL
+};
+
+EFI_STATUS
+EFIAPI
+QemuIGDHelperComponentNameGetDriverName (
+  IN  EFI_COMPONENT_NAME_PROTOCOL  *This,
+  IN  CHAR8*Language,
+  OUT CHAR16   **DriverName
+  );
+
+EFI_STATUS
+EFIAPI
+QemuIGDHelperComponentNameGetControllerName (
+  IN  EFI_COMPONENT_NAME_PROTOCOL *This,
+  IN  EFI_HANDLE  ControllerHandle,
+  IN  EFI_HANDLE  ChildHandle
OPTIONAL,
+  IN  CHAR8   *Language,
+  OUT CHAR16  **ControllerName
+  );
+
+EFI_UNICODE_STRING_TABLE mQemuIGDHelperDriverNameTable[] = {
+  { "eng;en", L"QEMU IGD Helper" },
+  { NULL , NULL }
+};
+
+EFI_UNICODE_STRING_TABLE mQemuIGDHelperControllerNameTable[] = {
+  { "eng;en", L"IGD" },
+  { NULL , NULL }
+};
+
+EFI_COMPONENT_NAME_PROTOCOL  gQemuIGDHelperCom

[edk2] [PATCH] QemuVideoDxe: round up FrameBufferSize to full page

[Gerd Hoffmann]

Guests do the same, because the framebuffer is mapped somewhere, which
obviously works with page granularity only.

When not rounding up to full page size we get messages like this one
(linux kernel):

efifb: framebuffer at 0x8000, using 1876k, total 1875k
^^
Also sysfb is confused and throws an error:

sysfb: VRAM smaller than advertised

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Gerd Hoffmann <kra...@redhat.com>
---
 OvmfPkg/QemuVideoDxe/Gop.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/OvmfPkg/QemuVideoDxe/Gop.c b/OvmfPkg/QemuVideoDxe/Gop.c
index d51efc2a83..2bd905efea 100644
--- a/OvmfPkg/QemuVideoDxe/Gop.c
+++ b/OvmfPkg/QemuVideoDxe/Gop.c
@@ -69,6 +69,8 @@ QemuVideoCompleteModeData (
   Mode->FrameBufferBase = FrameBufDesc->AddrRangeMin;
   Mode->FrameBufferSize = Info->HorizontalResolution * 
Info->VerticalResolution;
   Mode->FrameBufferSize = Mode->FrameBufferSize * ((ModeData->ColorDepth + 7) 
/ 8);
+  Mode->FrameBufferSize =
+(Mode->FrameBufferSize + EFI_PAGE_SIZE - 1) & ~EFI_PAGE_MASK;
   DEBUG ((EFI_D_INFO, "FrameBufferBase: 0x%Lx, FrameBufferSize: 0x%Lx\n",
 Mode->FrameBufferBase, (UINT64)Mode->FrameBufferSize));
 
-- 
2.9.3

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [MdeModulePkg/TerminalDxe] Why do we delay 2s for ESC being pressed?

[Gerd Hoffmann]

On Wed, Nov 08, 2017 at 04:44:37PM +0800, Heyi Guo wrote:
> 
> 
> 在 11/8/2017 4:34 PM, Ni, Ruiyu 写道:
> > No.
> > Even a terminal tool can recognize F10, it still needs to translate it into 
> > "ESC [ V"
> > and send the three bytes to firmware.
> Got it. But the 2 seconds timeout is not for this situation, right? If
> terminal tool could translate and send the key sequence, I think it can
> complete 3 bytes transfer in a very short time, isn't it? E.g. 9600 baud / 8
> = 1200 Bytes/s (ignore control bits).
> 
> So 2 seconds timeout is still for user to enter the sequence "ESC [ V"
> manually?

No.  Alot of software has this kind of delay because it is recommended
in some classic unix documentation to avoid mis-interpreting incomplete
terminal control sequences coming from slow terminals.

Where a "slow terminal" which actually would need such a long delay is a
physical terminal from the 70ies of the last century, or a virtual
terminal hooked up over a *really* slow network connection.

Reducing the delay from 2 seconds to roughly 0.2 seconds should be
pretty safe, things are not that slow any more these days :)

HTH,
  Gerd

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC v1 0/3] Add VIRTIO_F_IOMMU_PLATFORM support

[Gerd Hoffmann]

  Hi,

> > I see that OVMF has the following virtio drivers, we need to update
> > them
> > all:
> > 
> > VirtioBlkDxe
> > VirtioGpuDxe
> > VirtioNetDxe
> > VirtioRngDxe
> > VirtioScsiDxe
> > 
> > I will wait for Laszlo and Jordan's initial feedback before
> > changing
> > other drivers.
> 
> I'm not sure about the GPU. Cc relevant maintainers -
> can virtio GPU work from behind an IOMMU?

GPU uses main memory as backing storage for framebuffers, and this is
passed as guest physical address (scatterlist of addresses to be exact)
to the host.

So, I think no, this isn't going to work with the current code.

Should be possible to fix though.  We need to define what "guest
physical address" should be with VIRTIO_F_IOMMU_PLATFORM enabled
(probably guest pci bus address) and add support for proper iommu
lookups.

cheers,
  Gerd

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC PATCH] OvmfPkg/AcpiPlatformDxe: lift 4 GB alloc limit for modern ACPI systems

[Gerd Hoffmann]

  Hi,

> The reason is that old firmware is allowed to fail on new QEMU
> (regardless of machine type). Example: the WRITE_POINTER command,
> originally introduced for VMGENID. If you run a SeaBIOS binary
> without
> WRITE_POINTER support, in a QEMU VM with "-device vmgenid", the
> device
> will not work.

Old seabios will work just fine on new qemu as long as you don't use
the vmgenid device.

Only when using new features (which require firmware support) new
seabios is needed, and usually we update seabios for that reason.  We
want the new features be usable of course.  But in general there are no
lockstep updates for qemu and seabios (any more).

> And this patch is actually that case, because the new fw would
> allocate
> blobs with such 8-byte addresses that might not fit into 32-bit blob
> fields.

I think ovmf simply checking whenever the pointer fields are 32bit or
64bit, then doing allocations accordingly (as Igor suggested) would be
the best.  Why ask qemu for a hint when ovmf can figure on its own? 
That adds a new interface and new config knobs for IMO no good reason.

cheers,
  Gerd
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] SMRAM sizes on large hosts

[Gerd Hoffmann]

  Hi,

> If we invent such a new register, it should be in a location that is
> either read-only, or zeroed-on-reset, in current QEMU. Otherwise, new
> firmware running on old QEMU could be misled by a guest OS that writes
> to this register, and then either reboots or enters S3.

Good point, we need to be quite careful here to not open security holes.
Current state is that pretty much all pci config space is writable and
not cleared on reset.  So no easy way out.

> ... With this in mind, I don't oppose "having to write somewhere to read
> back the result", but then let's please make that write access as well
> to the same new qemu-specific register, and not to MCH_ESMRAMC.

That should work, yes.  Write '1' to the register, then read back.  If
it is still '1' -> no big tseg support.  Otherwise it returns the tseg
size in some form, and "11b" in ESMRAMC can be used to pick that.

cheers,
  Gerd

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] SMRAM sizes on large hosts

[Gerd Hoffmann]

  Hi,

> There is another thing to consider here, when vm is migrated to newer
> qemu(with newer firmware version) then it might not boot on the next
> restart due to hitting old set limit.

Firmware is part of the migration data, so you have the same version on
both ends.

cheers,
  Gerd

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] SMRAM sizes on large hosts

[Gerd Hoffmann]

  Hi,

> > The problem with this is that I need the TSEG size in another module as
> > well, namely PlatformPei. The dispatch order between PlatformPei and
> > SmmAccessPei is unspecified (they have both TRUE for DEPEX). If
> > PlatformPei gets dispatched second, I really wouldn't want to write to
> > MCH_ESMRAMC again, just to query MCH_TSEGMB. (I couldn't just read
> > MCH_TSEGMB because if PlatformPei were dispatched first, then MCH_TSEGMB
> > would still be unset).
> > 
> > In other words, I wouldn't like to write a register just to receive the
> > information; I need the information in two places whose relative
> > ordering is unspecified, and one of those already writes the register in
> > question, genuinely. I guess I could hack it around with another dynamic
> > PCD, but that's kind of ugly.

Hmm, this unspecified ordering works nicely today because tseg size is a
compile time constant.  If we make this dynamic we either need a pcd or
must probe tseg size twice (no matter whenever this is some pci cfg
space register or fw_cfg file), which is kind of ugly too ...

> > If we invented a read-only, side-effect-free PCI config space register
> > that gave me this value plain and simple (similarly to how a new fw_cfg
> > file would do), that would be a lot cleaner for me.

That makes the "probe twice" thing easier indeed.

> > I think this would
> > match your earlier alternative where you wrote "Alternatively we could
> > add some qemu-specific register".

Yes.

cheers,
  Gerd


___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] SMRAM sizes on large hosts

[Gerd Hoffmann]

  Hi,

> I propose the following: add a new fw_cfg file which communicates how
> much memory (how many megabytes) the "11b" value in the tseg size
> register will configure.

I'd prefer to keep fw_cfg out of the picture, and I think we can do it
without too much problems.

We have a TSEGMB (tseg memory base) register.  qemu doesn't implement it
(but I think you can write to it and read back what you've written).

We could make qemu update that register in case "11b" is written to the
tseg size.  The firmware then can read TSEGMB and figure whenever a
large tseg is supported and if so how big it is.

cheers,
  Gerd



___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] SMRAM sizes on large hosts

[Gerd Hoffmann]

On Di, 2017-05-02 at 20:49 +, Kinney, Michael D wrote:
> Laszlo,
> 
> Is it possible to add more TSEG sizes to the Q35 board?

qemu implements what physical q35 support.  The extended smram register
has two bits for the tseg size, three out of the four values are used
(for 1, 2, 8 MB sizes).  "11" is reserved in the specs.  We could use
"11" to implement a bigger tseg.  Current code sets the tseg size to
zero for "11".  Alternatively we could add some qemu-specific register.

When implementing this in qemu we will have to do it runtime-switchable,
for backward compatibility with older qemu versions.  So ideally
firmware would detect somehow whenever qemu supports a bigger tseg or
not and adapt at runtime.  If edk2 can't do this we would need two edk2
builds ...

cheers,
  Gerd

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 00/11] OvmfPkg, ArmVirtPkg: GOP driver for the VirtIo GPU (virtio-gpu-pci)

[Gerd Hoffmann]

  Hi,

> Is there no chance that ARM KVM might someday also be able to support
> a framebuffer?

Problem on arm is that you can't expose something as pci memory to the
guest which in reality isn't pci memory but normal ram (like the
emulated vga memory pci bar).

Storing a framebuffer in normal ram is (as far I know) no problem.  But
updates are a problem then, you have to:

  (a) notify the host about updates (which is what virtio-gpu does), or
  (b) turn on dirty tracking for *all* guest ram so you can detect
  display updates automatically (lot of overhead, vga needs dirty
  tracking only for the 16M pci bar), or
  (c) update whole framebuffer unconditionally in regular intervals
  (doesn't look great too).

cheers,
  Gerd

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] iPXE invalidates the OVMF network device options

[Gerd Hoffmann]

  Hi,

> ... Hm, actually, I have one suspect. In your report, you said the
> boot option called "UEFI PXEv4" worked fine. "EFI Network" didn't, and
> it was higher up in the boot order.
> 
> I think "EFI Network" could be a left-over boot option (from the old
> IntelFrameworkModulePkg BDS) that doesn't work any longer.

Could very well be.  Those virtual machines exist for a while already.

> And, due to how the boot option ("bootorder" fw_cfg) matching works in
> OVMF, both "EFI Network" and "UEFI PXEv4" may have device paths
> associated with them that match the QEMU boot order specification.
> Since "EFI Network" is already in your varstore, at the top of the
> boot order, that one is tried. (I think "UEFI PXEv4" is even dropped
> by OVMF's filtering, it's just that when you enter the UI application
> in OVMF, a bunch of boot options are regenerated at the end of the
> list again).

Very plausible.  /me goes delete the old varstore.  Trying again ...

Yep, "EFI Network" is gone now.  "UEFI PXEv4" is first in the list.
Everything working fine.

> edk2 sometimes undergoes non-compatible changes where manual massaging
> of the varstore is required. Recently there was another example when
> even the UEFI spec changed incompatibily; see
> 
> https://github.com/tianocore/edk2/commit/d5aee61bfaaa
> https://github.com/tianocore/edk2/commit/1da761664949
> 
> I don't have a good automated solution for this kind of change, unfortunately.

Hmm.  How is this handled on physical hardware?

I suspect it'll be to not release that kind of firmware update in the
first place.  Or a paragraph in the release notes.

cheers,
  Gerd


___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] iPXE invalidates the OVMF network device options

[Gerd Hoffmann]

  Hi,

> > bootindex not working is still there, with both old and new ipxe rom
> > builds.
> 
> Hrmph. That is strange. Can you please give me a bit more info?
> 
> I'm asking because I tested the following configuration last night:
> - I350-T2V2 virtual function assigned to the Q35 guest
> - assigned device decorated with bootindex=1 (through libvirt domain
>   XML)
> - SNP driver provided by the UEFI + CONFIG=qemu build of iPXE's "igbvf"
>   driver (combined oprom)
> - used iPXE master at commit 04186319181298083ef28695a8309028b26fe83c
> - OVMF built from fresh edk2 master also
> 
> A small QEMU cmdline reproducer would be appreciated.

Attached is my libvirt config.

ovmf is latest package from kraxel.org (which is a few days old due to
the gcc6 update build failures).

/home/kraxel/projects/qemu is a qemu checkout.  Doesn't matter whenever
I use master (old ipxe) or updated ipxe branch[1], issue is present in
both cases.

cheers,
  Gerd

[1] https://www.kraxel.org/cgit/qemu/log/?h=work/ipxe

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] iPXE invalidates the OVMF network device options

[Gerd Hoffmann]

On Di, 2016-06-28 at 14:31 +0200, Laszlo Ersek wrote:
> On 06/24/16 10:41, Gerd Hoffmann wrote:
> >   Hi,
> > 
> >> Thanks, I guess we can remove these if building with
> >> DEBUG=virtio-net:2 was intentional and it interferes with other
> >> output. But then again, if you build for example with DEBUG=tcp:2,
> >> you'll see a debug message for each transmitted or received packet
> >> also.
> > 
> > Sorry for the trouble.  Everything is fine.  My test configuration was
> > broken, romfile= didn't point to the file I intended to test with.
> 
> Does "everything is fine" cover the other symptoms you described in your
> email, such as "-device $nic,bootindex=1" not working?

No, only the "virtio-net floods the display with debug messages" part.

bootindex not working is still there, with both old and new ipxe rom
builds.

cheers,
  Gerd

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] iPXE invalidates the OVMF network device options

[Gerd Hoffmann]

  Hi,

> Thanks, I guess we can remove these if building with
> DEBUG=virtio-net:2 was intentional and it interferes with other
> output. But then again, if you build for example with DEBUG=tcp:2,
> you'll see a debug message for each transmitted or received packet
> also.

Sorry for the trouble.  Everything is fine.  My test configuration was
broken, romfile= didn't point to the file I intended to test with.

cheers,
  Gerd
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] iPXE invalidates the OVMF network device options

[Gerd Hoffmann]

  Hi,

> > First thing I've noticed is that the virtio-net driver floods the
> > terminal with debug messages for each and every package.  That is
> > clearly a nonstarter and must be fixed.
> 
> All the more verbose virtio-net messages require log level 2, and
> logging every packet at level 2 seems to be in line with the rest of
> the iPXE networking stack. What debug messages are you seeing?

VIRTIO-NET 0x3e9ba378 rx complete iobuf 0x3e9c85f8 len 52
VIRTIO-NET 0x3e9ba378 enqueuing iobuf 0x3e9c7df8 on vq 0
vring_add_buf: 0x3e9be022 14 - 12 10  8  6  4
VIRTIO-NET 0x3e9ba378 rx complete iobuf 0x3e9c8df8 len 52
VIRTIO-NET 0x3e9ba378 enqueuing iobuf 0x3e9c85f8 on vq 0
vring_add_buf: 0x3e9be024  0 - 14 12 10  8  6
VIRTIO-NET 0x3e9ba378 rx complete iobuf 0x3e9c4df8 len 52
VIRTIO-NET 0x3e9ba378 enqueuing iobuf 0x3e9c8df8 on vq 0
vring_add_buf: 0x3e9be026  2 -  0 14 12 10  8
VIRTIO-NET 0x3e9ba378 rx complete iobuf 0x3e9c55f8 len 52
VIRTIO-NET 0x3e9ba378 enqueuing iobuf 0x3e9c4df8 on vq 0
vring_add_buf: 0x3e9be028  4 -  2  0 14 12 10
VIRTIO-NET 0x3e9ba378 rx complete iobuf 0x3e9c5df8 len 52
VIRTIO-NET 0x3e9ba378 enqueuing iobuf 0x3e9c55f8 on vq 0
vring_add_buf: 0x3e9be02a  6 -  4  2  0 14 12
VIRTIO-NET 0x3e9ba378 rx complete iobuf 0x3e9c65f8 len 52
VIRTIO-NET 0x3e9ba378 enqueuing iobuf 0x3e9c5df8 on vq 0
vring_add_buf: 0x3e9be02c  8 -  6  4  2  0 14
VIRTIO-NET 0x3e9ba378 rx complete iobuf 0x3e9c6df8 len 52
VIRTIO-NET 0x3e9ba378 enqueuing iobuf 0x3e9c65f8 on vq 0
vring_add_buf: 0x3e9be02e 10 -  8  6  4  2  0

When booting e1000 or rtl8139 I don't see any messages.

cheers,
  Gerd

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] iPXE invalidates the OVMF network device options

[Gerd Hoffmann]

  Hi,

> > Assuming you can sneak an iPXE rebuild into the QEMU soft freeze, I
> > think it makes sense to wait a bit longer -- let's hope I can come up
> > with something sensible for that error too...
> 
> can you please retest with a fresh build of the current iPXE master (at
> 04186319181298083ef28695a8309028b26fe83c presently)? I can no longer
> reproduce the ASSERT -- the iPXE form can be entered just fine.
> 
> I don't know what changed. o_O
> 
> Michael committed an improved version of my patch, but I fail to see how
> that change could have been relevant for this... Michael's patch copies
> 6 bytes (rather than 20) into the target array, but I thought bytes in
> that source array past offset 5 were zeroed anyway.
> 
> Anyway, if it looks all good to you as well, then I think we can call
> this solved, and Gerd could go ahead with the rebuild.

Built updates today and ran a bunch of tests.

First thing I've noticed is that the virtio-net driver floods the
terminal with debug messages for each and every package.  That is
clearly a nonstarter and must be fixed.

Second thing I've noticed is that automatic network boot doesn't work
with ipxe (i.e. -device $nic,bootindex=1).  When going into the boot
menu in ovmf I find three entries now:  "EFI Network", ranked first,
doesn't work.  Returns to the boot menu instantly, without any network
activity.  Then "UEFI PXEv4" and "UEFI HTTPv4" at the bottom of the
list.  Selecting the "UEFI PXEv4" works as expected.  Selecting "UEFI
HTTPv4" has no visible effect, but at least I see dhcp requests on the
wire so I guess with the correct server side configuration this one
would work too.  That happens with both old and new ipxe, so it is
probably related to the recent network boot updates in edk2.

cheers,
  Gerd

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] iPXE invalidates the OVMF network device options

[Gerd Hoffmann]

On Mi, 2016-06-22 at 17:14 +0200, Laszlo Ersek wrote:
> On 06/22/16 10:34, Michael Brown wrote:
> > On 22/06/16 05:48, Laszlo Ersek wrote:
> >> In other words, the memcpy() quoted at the top copies 32 bytes into a
> >> 32-byte buffer, from a 20-byte buffer. It is the *source* buffer that is
> >> overflowed.
> >>
> >> As a result, bytes 20..31 of MacAddress (inclusive) are filled with
> >> garbage.
> > 
> > Awesome debugging; thank you!  I've pushed a fix at
> > 
> >   http://git.ipxe.org/ipxe.git/commitdiff/632e57f
> 
> Thanks!
> 
> Gerd, do you think you can rebuild the iPXE binaries bundled with QEMU
> during the 2.7 soft/hard freeze ?

I intend to update ipxe before softfreeze (and if it doesn't work out
for some reason surely before hardfreeze), to pick up this fix and
virtio 1.0 support.

What is the state of this?  IIRC there was some other issue beside this
ipxe bugfix.  Is this root-caused meanwhile?  edk2 issue?  ipxe issue? 

Should I wait for more ipxe fixes or can I go ahead with the update?

cheers,
  Gerd


___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] EDK2 Staging Repository

[Gerd Hoffmann]

On Mi, 2016-03-09 at 16:57 -0700, Bruce Cran wrote:
> On 3/9/16 2:59 PM, Jordan Justen wrote:
> 
> > So far I have a setup that can test building BaseTools and OVMF on
> > Linux. The Windows setup is a little more complicated, but I don't
> > think it should be too difficult.
> 
> I guess that's Linux x86_64? Any solution we come up with should also be 
> extendable to AARCH64.

I do have jenkins running, doing the builds for
https://www.kraxel.org/repos/, including aarch64 and arm builds (using a
cross compiler).

If there is interest I configure jenkins to send build failures to the
list too.  There are some drawbacks though:

  (1) There are false positives now and then for various reasons:
  * Now and then manual invention is needed to keep things going
(for example on openssl updates).
  * The rpm package has patches which need a rebase now and then.
  * Occasionally infrastructure hickups.
  (2) Sometimes it takes me a few days to deal with those issues,
  jenkins will keep on reporting the build failures until I did.
  (3) The system runs on a private network behind a NAT router, so you
  wouldn't be able to click on the links for build logs etc, all you
  get is the mail reporting the failure.
  (4) It's designed to provide rpms for the master branch, that it
  test-builds the master branch is more a side-effect.  I most
  likely wouldn't extend this to also build staging branches.

If you ever wondered how Laszlo notices quickly if someone breaks the
build, he gets the jenkins reports ;)

cheers,
  Gerd

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 2/5] OvmfPkg: PlatformPei: enable PCIEXBAR (aka MMCONFIG / ECAM) on Q35

[Gerd Hoffmann]

  Hi,

> Okay, my vote is 0x8000_ (2GB) then.
> 
> I will modify the patch as follows: simultaneously with programming the
> exbar at 2GB, I will lower the start of the 32-bit PCI aperture from the
> current 3GB (0xC000_) to (2GB+256MB == 0x9000_). Is that alright?

Yes, that should work fine.

cheers,
  Gerd

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 2/5] OvmfPkg: PlatformPei: enable PCIEXBAR (aka MMCONFIG / ECAM) on Q35

[Gerd Hoffmann]

  Hi,

>   PCI: MMCONFIG at [mem 0xb000-0xbfff] reserved in E820

Ok, I see you mimic seabios behavior here, resulting in a somewhat odd
memory layout (not your fault, of course).

Short history lesson:

Traditional i440fx memory layout (before we did gigabyte alignment) was
memory up to 0xe000, pci io space above that.  Which caused problems
now and then, because it isn't that much address space for pci.

So, when figuring how to do things on q35 I wanted more space.  Decided
to go down to 0xc000, giving additional 512m address space for pci.
But we also have to place the xbar somewhere.  The seabios code to do
pci bar placement is somewhat simple and can deal with a single (32bit)
I/O window only.  Decided to place the xbar @ 0xb000, so seabios has
a single region above 0xc000 for the I/O bars.

So, this is where the traditional q35 memory layout with memory up to
0xafff comes from.  These days it doesn't look that way any more
because we added gigabyte alignment meanwhile, so it's this now:

   low memory  0x -> 0x7fff.  
   free space  0x8000 -> 0xafff,
   mmcfg xbar  0xb000 -> 0xbfff,
   free space  0xc000 -> ioapic-base

i.e. the xbar splits the free space in a somewhat unclever way.

The good news is that xbar location is not fixed.  qemu is supposed to
check now the firmware programmed the q35 host bridge and fill the acpi
tables accordingly, so you should be able to move the xbar to another
location.

I think there are two reasonable choices: Either 0x8000 or
0xe000.

Using 0x8000 maintains a single I/O window. (above 0x9000).
Gives up backward compatibility to really old (pre gigabyte alignment)
q35 machines types.  But we are about to drop support for them in
upstream qemu anyway, so I'll probably switch seabios to do that.

Using 0xe000 still splits the I/O address space into two pieces, but
I don't think the edk2 resource management code has problems dealing
with that.   It places the xbar at the highest possible address, so we
get a big I/O window below the xbar (and a small one above).  The main
advantage over using 0xb000 is that you can better fit big bars
then, for example you can map even a 1G bar (at 0x800).

cheers,
  Gerd

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 00/17] Port OvmfPkg to MdeModulePkg/Bus/Pci/PciHostBridgeDxe

[Gerd Hoffmann]

  Hi,

> Once this is in, the next plan is to enable 64-bit MMIO -- first for
> emulated devices, then maybe for assigned devices. See
> . With the core driver,
> 64-bit MMIO should "only" take some fw_cfg-based configuration.

I strongly suggest to check out whenever we can get away *without* a
config knob for this.  Just turn on 64bit mmio unconditionally and see
how guests can deal with it.

With ovmf we can ignore alot of legacy cruft (at least for !csm builds).
Windows XP choking when it finds 64bit _CRS entries?  No problem here,
winxp doesn't run on efi anyway.

For reference:  seabios handles 64bit bars this way:  It first tries to
fit all pci bars into the 32bit I/O window, for the snake of legacy
guests which have trouble dealing with 64bit bars mapped above 4G.
In case there isn't enough space it moves the 64bit bars to the 64bit
window and tries assigning addresses to bars again.

cheers,
  Gerd

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] varstore compatibility between auth and non-auth

[Gerd Hoffmann]

  Hi,

> So, my question is: is this intended and supported behavior (that is,
> going from a Secure Boot-capable build to a Secure Boot-disabled build,
> while preserving the contents & functionality of the variables), or just
> a lucky coincidence that results from the design choices you made while
> unifying the variable drivers?

Related followup question: If the driver can dynamically switch formats
now, is there any reason to ever create new varstores in the old format?

thanks,
  Gerd

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2] MdeModulePkg: Update MNP driver to recycle TX buffer asynchronously.

[Gerd Hoffmann]

On Mi, 2016-01-13 at 13:43 +0100, Laszlo Ersek wrote:
> Gerd, can you please add -D HTTP_BOOT_ENABLE to the OVMF (IA32 / X64)
> build commands edk2.git.spec?

Done, build kicked.

cheers,
  Gerd
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel