audk/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetect.c

72 lines
2.0 KiB
C
Raw Normal View History

/** @file
OvmfPkg: save on I/O port accesses when the debug port is not in use When SEV is enabled, every debug message printed by OVMF to the QEMU debug port traps from the guest to QEMU character by character because "REP OUTSB" cannot be used by IoWriteFifo8. Furthermore, when OVMF is built with the DEBUG_VERBOSE bit (value 0x00400000) enabled in "gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel", then the OvmfPkg/IoMmuDxe driver, and the OvmfPkg/Library/BaseMemEncryptSevLib library instance that is built into it, produce a huge amount of log messages. Therefore, in SEV guests, the boot time impact is huge (about 45 seconds _additional_ time spent writing to the debug port). While these messages are very useful for analyzing guest behavior, most of the time the user won't be capturing the OVMF debug log. In fact libvirt does not provide a method for configuring log capture; users that wish to do this (or are instructed to do this) have to resort to <qemu:arg>. The debug console device provides a handy detection mechanism; when read, it returns 0xE9 (which is very much unlike the 0xFF that is returned by an unused port). Use it to skip the possibly expensive OUT instructions when the debug I/O port isn't plugged anywhere. For SEC, the debug port has to be read before each full message. However: - if the debug port is available, then reading one byte before writing a full message isn't tragic, especially because SEC doesn't print many messages - if the debug port is not available, then reading one byte instead of writing a full message is still a win. Contributed-under: TianoCore Contribution Agreement 1.0 Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen (Intel address) <jordan.l.justen@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2017-11-16 21:31:00 +01:00
Detection code for QEMU debug port.
Non-SEC instance, caches the result of detection.
Copyright (c) 2017, Red Hat, Inc.<BR>
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 <Base.h>
OvmfPkg: save on I/O port accesses when the debug port is not in use When SEV is enabled, every debug message printed by OVMF to the QEMU debug port traps from the guest to QEMU character by character because "REP OUTSB" cannot be used by IoWriteFifo8. Furthermore, when OVMF is built with the DEBUG_VERBOSE bit (value 0x00400000) enabled in "gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel", then the OvmfPkg/IoMmuDxe driver, and the OvmfPkg/Library/BaseMemEncryptSevLib library instance that is built into it, produce a huge amount of log messages. Therefore, in SEV guests, the boot time impact is huge (about 45 seconds _additional_ time spent writing to the debug port). While these messages are very useful for analyzing guest behavior, most of the time the user won't be capturing the OVMF debug log. In fact libvirt does not provide a method for configuring log capture; users that wish to do this (or are instructed to do this) have to resort to <qemu:arg>. The debug console device provides a handy detection mechanism; when read, it returns 0xE9 (which is very much unlike the 0xFF that is returned by an unused port). Use it to skip the possibly expensive OUT instructions when the debug I/O port isn't plugged anywhere. For SEC, the debug port has to be read before each full message. However: - if the debug port is available, then reading one byte before writing a full message isn't tragic, especially because SEC doesn't print many messages - if the debug port is not available, then reading one byte instead of writing a full message is still a win. Contributed-under: TianoCore Contribution Agreement 1.0 Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen (Intel address) <jordan.l.justen@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2017-11-16 21:31:00 +01:00
#include "DebugLibDetect.h"
OvmfPkg/PlatformDebugLibIoPort: fix port detection for use in the DXE Core The DXE Core is one of those modules that call ProcessLibraryConstructorList() manually. Before DxeMain() [MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c] calls ProcessLibraryConstructorList(), and through it, our PlatformDebugLibIoPortConstructor() function, DxeMain() invokes the DEBUG() macro multiple times. That macro lands in our PlatformDebugLibIoPortFound() function -- which currently relies on the "mDebugIoPortFound" global variable that has (not yet) been set by the constructor. As a result, early debug messages from the DXE Core are lost. Move the device detection into PlatformDebugLibIoPortFound(), also caching the fact (not just the result) of the device detection. (We could introduce a separate DebugLib instance just for the DXE Core, but the above approach works for all modules that currently consume the PlatformDebugLibIoPort instance (which means "everything but SEC").) This restores messages such as: > CoreInitializeMemoryServices: > BaseAddress - 0x7AF21000 Length - 0x3CDE000 MinimalMemorySizeNeeded - 0x10F4000 Keep the empty constructor function -- OVMF's DebugLib instances have always had constructors; we had better not upset constructor dependency ordering by making our instance(s) constructor-less. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Fixes: c09d9571300a089c35f5df2773b70edc25050d0d Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com> [lersek@redhat.com: sanitize blank lines around "mDebugIoPortChecked"]
2018-08-03 01:29:13 +02:00
//
// Set to TRUE if the debug I/O port has been checked
//
STATIC BOOLEAN mDebugIoPortChecked = FALSE;
OvmfPkg: save on I/O port accesses when the debug port is not in use When SEV is enabled, every debug message printed by OVMF to the QEMU debug port traps from the guest to QEMU character by character because "REP OUTSB" cannot be used by IoWriteFifo8. Furthermore, when OVMF is built with the DEBUG_VERBOSE bit (value 0x00400000) enabled in "gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel", then the OvmfPkg/IoMmuDxe driver, and the OvmfPkg/Library/BaseMemEncryptSevLib library instance that is built into it, produce a huge amount of log messages. Therefore, in SEV guests, the boot time impact is huge (about 45 seconds _additional_ time spent writing to the debug port). While these messages are very useful for analyzing guest behavior, most of the time the user won't be capturing the OVMF debug log. In fact libvirt does not provide a method for configuring log capture; users that wish to do this (or are instructed to do this) have to resort to <qemu:arg>. The debug console device provides a handy detection mechanism; when read, it returns 0xE9 (which is very much unlike the 0xFF that is returned by an unused port). Use it to skip the possibly expensive OUT instructions when the debug I/O port isn't plugged anywhere. For SEC, the debug port has to be read before each full message. However: - if the debug port is available, then reading one byte before writing a full message isn't tragic, especially because SEC doesn't print many messages - if the debug port is not available, then reading one byte instead of writing a full message is still a win. Contributed-under: TianoCore Contribution Agreement 1.0 Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen (Intel address) <jordan.l.justen@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2017-11-16 21:31:00 +01:00
//
// Set to TRUE if the debug I/O port is enabled
//
STATIC BOOLEAN mDebugIoPortFound = FALSE;
/**
OvmfPkg/PlatformDebugLibIoPort: fix port detection for use in the DXE Core The DXE Core is one of those modules that call ProcessLibraryConstructorList() manually. Before DxeMain() [MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c] calls ProcessLibraryConstructorList(), and through it, our PlatformDebugLibIoPortConstructor() function, DxeMain() invokes the DEBUG() macro multiple times. That macro lands in our PlatformDebugLibIoPortFound() function -- which currently relies on the "mDebugIoPortFound" global variable that has (not yet) been set by the constructor. As a result, early debug messages from the DXE Core are lost. Move the device detection into PlatformDebugLibIoPortFound(), also caching the fact (not just the result) of the device detection. (We could introduce a separate DebugLib instance just for the DXE Core, but the above approach works for all modules that currently consume the PlatformDebugLibIoPort instance (which means "everything but SEC").) This restores messages such as: > CoreInitializeMemoryServices: > BaseAddress - 0x7AF21000 Length - 0x3CDE000 MinimalMemorySizeNeeded - 0x10F4000 Keep the empty constructor function -- OVMF's DebugLib instances have always had constructors; we had better not upset constructor dependency ordering by making our instance(s) constructor-less. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Fixes: c09d9571300a089c35f5df2773b70edc25050d0d Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com> [lersek@redhat.com: sanitize blank lines around "mDebugIoPortChecked"]
2018-08-03 01:29:13 +02:00
This constructor function must not do anything.
Some modules consuming this library instance, such as the DXE Core, invoke
the DEBUG() macro before they explicitly call
ProcessLibraryConstructorList(). Therefore the auto-generated call from
ProcessLibraryConstructorList() to this constructor function may be preceded
by some calls to PlatformDebugLibIoPortFound() below. Hence
PlatformDebugLibIoPortFound() must not rely on anything this constructor
could set up.
@retval RETURN_SUCCESS The constructor always returns RETURN_SUCCESS.
**/
RETURN_STATUS
EFIAPI
PlatformDebugLibIoPortConstructor (
VOID
)
{
return RETURN_SUCCESS;
}
OvmfPkg: save on I/O port accesses when the debug port is not in use When SEV is enabled, every debug message printed by OVMF to the QEMU debug port traps from the guest to QEMU character by character because "REP OUTSB" cannot be used by IoWriteFifo8. Furthermore, when OVMF is built with the DEBUG_VERBOSE bit (value 0x00400000) enabled in "gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel", then the OvmfPkg/IoMmuDxe driver, and the OvmfPkg/Library/BaseMemEncryptSevLib library instance that is built into it, produce a huge amount of log messages. Therefore, in SEV guests, the boot time impact is huge (about 45 seconds _additional_ time spent writing to the debug port). While these messages are very useful for analyzing guest behavior, most of the time the user won't be capturing the OVMF debug log. In fact libvirt does not provide a method for configuring log capture; users that wish to do this (or are instructed to do this) have to resort to <qemu:arg>. The debug console device provides a handy detection mechanism; when read, it returns 0xE9 (which is very much unlike the 0xFF that is returned by an unused port). Use it to skip the possibly expensive OUT instructions when the debug I/O port isn't plugged anywhere. For SEC, the debug port has to be read before each full message. However: - if the debug port is available, then reading one byte before writing a full message isn't tragic, especially because SEC doesn't print many messages - if the debug port is not available, then reading one byte instead of writing a full message is still a win. Contributed-under: TianoCore Contribution Agreement 1.0 Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen (Intel address) <jordan.l.justen@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2017-11-16 21:31:00 +01:00
/**
OvmfPkg/PlatformDebugLibIoPort: fix port detection for use in the DXE Core The DXE Core is one of those modules that call ProcessLibraryConstructorList() manually. Before DxeMain() [MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c] calls ProcessLibraryConstructorList(), and through it, our PlatformDebugLibIoPortConstructor() function, DxeMain() invokes the DEBUG() macro multiple times. That macro lands in our PlatformDebugLibIoPortFound() function -- which currently relies on the "mDebugIoPortFound" global variable that has (not yet) been set by the constructor. As a result, early debug messages from the DXE Core are lost. Move the device detection into PlatformDebugLibIoPortFound(), also caching the fact (not just the result) of the device detection. (We could introduce a separate DebugLib instance just for the DXE Core, but the above approach works for all modules that currently consume the PlatformDebugLibIoPort instance (which means "everything but SEC").) This restores messages such as: > CoreInitializeMemoryServices: > BaseAddress - 0x7AF21000 Length - 0x3CDE000 MinimalMemorySizeNeeded - 0x10F4000 Keep the empty constructor function -- OVMF's DebugLib instances have always had constructors; we had better not upset constructor dependency ordering by making our instance(s) constructor-less. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Fixes: c09d9571300a089c35f5df2773b70edc25050d0d Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com> [lersek@redhat.com: sanitize blank lines around "mDebugIoPortChecked"]
2018-08-03 01:29:13 +02:00
At the first call, check if the debug I/O port device is present, and cache
the result for later use. At subsequent calls, return the cached result.
OvmfPkg: save on I/O port accesses when the debug port is not in use When SEV is enabled, every debug message printed by OVMF to the QEMU debug port traps from the guest to QEMU character by character because "REP OUTSB" cannot be used by IoWriteFifo8. Furthermore, when OVMF is built with the DEBUG_VERBOSE bit (value 0x00400000) enabled in "gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel", then the OvmfPkg/IoMmuDxe driver, and the OvmfPkg/Library/BaseMemEncryptSevLib library instance that is built into it, produce a huge amount of log messages. Therefore, in SEV guests, the boot time impact is huge (about 45 seconds _additional_ time spent writing to the debug port). While these messages are very useful for analyzing guest behavior, most of the time the user won't be capturing the OVMF debug log. In fact libvirt does not provide a method for configuring log capture; users that wish to do this (or are instructed to do this) have to resort to <qemu:arg>. The debug console device provides a handy detection mechanism; when read, it returns 0xE9 (which is very much unlike the 0xFF that is returned by an unused port). Use it to skip the possibly expensive OUT instructions when the debug I/O port isn't plugged anywhere. For SEC, the debug port has to be read before each full message. However: - if the debug port is available, then reading one byte before writing a full message isn't tragic, especially because SEC doesn't print many messages - if the debug port is not available, then reading one byte instead of writing a full message is still a win. Contributed-under: TianoCore Contribution Agreement 1.0 Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen (Intel address) <jordan.l.justen@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2017-11-16 21:31:00 +01:00
@retval TRUE if the debug I/O port device was detected.
@retval FALSE otherwise
**/
BOOLEAN
EFIAPI
PlatformDebugLibIoPortFound (
VOID
)
{
OvmfPkg/PlatformDebugLibIoPort: fix port detection for use in the DXE Core The DXE Core is one of those modules that call ProcessLibraryConstructorList() manually. Before DxeMain() [MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c] calls ProcessLibraryConstructorList(), and through it, our PlatformDebugLibIoPortConstructor() function, DxeMain() invokes the DEBUG() macro multiple times. That macro lands in our PlatformDebugLibIoPortFound() function -- which currently relies on the "mDebugIoPortFound" global variable that has (not yet) been set by the constructor. As a result, early debug messages from the DXE Core are lost. Move the device detection into PlatformDebugLibIoPortFound(), also caching the fact (not just the result) of the device detection. (We could introduce a separate DebugLib instance just for the DXE Core, but the above approach works for all modules that currently consume the PlatformDebugLibIoPort instance (which means "everything but SEC").) This restores messages such as: > CoreInitializeMemoryServices: > BaseAddress - 0x7AF21000 Length - 0x3CDE000 MinimalMemorySizeNeeded - 0x10F4000 Keep the empty constructor function -- OVMF's DebugLib instances have always had constructors; we had better not upset constructor dependency ordering by making our instance(s) constructor-less. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Fixes: c09d9571300a089c35f5df2773b70edc25050d0d Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com> [lersek@redhat.com: sanitize blank lines around "mDebugIoPortChecked"]
2018-08-03 01:29:13 +02:00
if (!mDebugIoPortChecked) {
mDebugIoPortFound = PlatformDebugLibIoPortDetect ();
mDebugIoPortChecked = TRUE;
}
OvmfPkg: save on I/O port accesses when the debug port is not in use When SEV is enabled, every debug message printed by OVMF to the QEMU debug port traps from the guest to QEMU character by character because "REP OUTSB" cannot be used by IoWriteFifo8. Furthermore, when OVMF is built with the DEBUG_VERBOSE bit (value 0x00400000) enabled in "gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel", then the OvmfPkg/IoMmuDxe driver, and the OvmfPkg/Library/BaseMemEncryptSevLib library instance that is built into it, produce a huge amount of log messages. Therefore, in SEV guests, the boot time impact is huge (about 45 seconds _additional_ time spent writing to the debug port). While these messages are very useful for analyzing guest behavior, most of the time the user won't be capturing the OVMF debug log. In fact libvirt does not provide a method for configuring log capture; users that wish to do this (or are instructed to do this) have to resort to <qemu:arg>. The debug console device provides a handy detection mechanism; when read, it returns 0xE9 (which is very much unlike the 0xFF that is returned by an unused port). Use it to skip the possibly expensive OUT instructions when the debug I/O port isn't plugged anywhere. For SEC, the debug port has to be read before each full message. However: - if the debug port is available, then reading one byte before writing a full message isn't tragic, especially because SEC doesn't print many messages - if the debug port is not available, then reading one byte instead of writing a full message is still a win. Contributed-under: TianoCore Contribution Agreement 1.0 Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen (Intel address) <jordan.l.justen@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2017-11-16 21:31:00 +01:00
return mDebugIoPortFound;
}