Jordan,
You are correct that subsequent installations of this protocol will fail.
But I don't think locating this protocol before installing it is a good
implementation choice. This would make the code confusing.
Thanks,
Ray
-Original Message-
From: Justen, Jordan L
Sent: Friday, Febru
On 13 February 2015 at 05:18, Jordan Justen wrote:
> Do you have this in a public branch based on this tree?
> https://github.com/tianocore/edk2
>
The patches are available here
https://git.linaro.org/people/ard.biesheuvel/uefi-next.git/shortlog/refs/heads/linaro-topic-xen
I also have a version
Comments inline.
- DW
From: Andrew Fish [mailto:af...@apple.com]
Sent: Thursday, February 12, 2015 9:39 AM
To: Wei, Dong (HP Servers CT Office)
Cc: Stefano Stabellini; edk2-devel@lists.sourceforge.net; Michael Rothmam
Subject: Re: [edk2] MMIO regions in GetMemoryMap ()0
On Feb 12, 2015
Do you have this in a public branch based on this tree?
https://github.com/tianocore/edk2
On 2015-02-12 03:18:52, Ard Biesheuvel wrote:
> This series implements support for executing Tianocore inside a Xen
> guest domain on 64-bit ARM systems (AArch64)
>
> The first part addresses ARM platform sp
On 2015-02-11 17:23:26, Ni, Ruiyu wrote:
> Wei,
> No you cannot install gEfiPciEnumerationCompleteProtocolGuid in
> PciEnumeratorLight().
> For a real platform, PCI BUS is fully enumerated in PciEnumerator()
> and later if reconnect happens, it's light enumerated in
> PciEnumeratorLight(). The prot
I think gEfiPciEnumerationCompleteProtocolGuid should be installed by
MdeModulePkg/Bus/Pci/PciBusDxe, even when PcdPciDisableBusEnumeration
is set.
Ray's main feedback seemed to be that we need to make sure PciBusDxe
only installs the protocol once. (I'll also reply to the other related
patch thre
> On Feb 12, 2015, at 2:53 AM, Wei, Dong (HP Servers CT Office)
> wrote:
>
> Yes, Andrew,
>
> My understanding has always been that the UEFI GetMemoryMap would report the
> MMIO region for the system. ACPI device enumerations have a way to report the
> MMIO resource that a specific device ma
On Thu, Feb 12, 2015 at 01:33:50PM +0100, Laszlo Ersek wrote:
> On 02/12/15 13:29, Wei Liu wrote:
> > On Thu, Feb 12, 2015 at 01:16:07PM +0100, Laszlo Ersek wrote:
> >> SVN r16411 delayed ACPI table installation until PCI enumeration was
> >> complete, because on QEMU the ACPI-related fw_cfg files
On 02/12/15 13:29, Wei Liu wrote:
> On Thu, Feb 12, 2015 at 01:16:07PM +0100, Laszlo Ersek wrote:
>> SVN r16411 delayed ACPI table installation until PCI enumeration was
>> complete, because on QEMU the ACPI-related fw_cfg files should only be
>> downloaded after PCI enumeration.
>>
>> However, Ini
On Thu, Feb 12, 2015 at 01:16:07PM +0100, Laszlo Ersek wrote:
> SVN r16411 delayed ACPI table installation until PCI enumeration was
> complete, because on QEMU the ACPI-related fw_cfg files should only be
> downloaded after PCI enumeration.
>
> However, InitializeXen() in "OvmfPkg/PlatformPei/Xen
SVN r16411 delayed ACPI table installation until PCI enumeration was
complete, because on QEMU the ACPI-related fw_cfg files should only be
downloaded after PCI enumeration.
However, InitializeXen() in "OvmfPkg/PlatformPei/Xen.c" sets
PcdPciDisableBusEnumeration to TRUE. This causes
PciBusDriverBi
This patch adds an implementation of XenHypercallLib for both
AArch64 and AArch32 execution modes on ARM systems.
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Stefano Stabellini
Signed-off-by: Ard Biesheuvel
---
OvmfPkg/Include/IndustryStandard/Xen/arch-arm/xen.h| 43
This implements a dummy RealTimeClockLib for Xen, as there is no
guest interface to access the time kept by Xen that can be shared
between UEFI and the OS.
Contributed-under: TianoCore Contribution Agreement 1.0
Acked-by: Laszlo Ersek
Reviewed-By: Olivier Martin
Signed-off-by: Ard Biesheuvel
--
This adds the .dsc and .fdf descriptions to build a UEFI image that
is bootable by a Xen guest on 64-bit ARM (AArch64)
Contributed-under: TianoCore Contribution Agreement 1.0
Acked-by: Laszlo Ersek
Reviewed-by: Olivier Martin
Signed-off-by: Ard Biesheuvel
---
ArmPlatformPkg/ArmVirtualizationPk
This patchs adds support to VirtFdtDxe for the Xen DT node which
contains the base address of the Grant Table. This data is communicated
to XenBusDxe using a XENIO_PROTOCOL instance.
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Laszlo Ersek
Reviewed-by: Olivier Martin
Sig
Add a ArmPlatformLib instance that can deal with the self relocation
and truly dynamic discovery of system RAM base and size.
Contributed-under: TianoCore Contribution Agreement 1.0
Acked-by: Laszlo Ersek
Reviewed-by: Olivier Martin
Signed-off-by: Ard Biesheuvel
---
ArmPlatformPkg/ArmVirtuali
This implements a SerialPortLib instance that wires up to the
PV console ring used by domU guests. Also imports the required
upstream Xen io/console.h header.
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Stefano Stabellini
Acked-by: Laszlo Ersek
Signed-off-by: Ard Biesheu
This patch introduces a relocatable PrePi, which can execute
from arbitrary offsets in RAM. This is intendend to be run
from a boot loader which passes a description of the actual
platform in a device tree, for instance.
This module is based on the PrePi implementations residing under
ArmPlatformP
This adds a XenIoMmioLib declaration and implementation that can
be invoked to install the XENIO_PROTOCOL and a corresponding
grant table address on a EFI handle.
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Laszlo Ersek
Signed-off-by: Ard Biesheuvel
---
OvmfPkg/Include/
This introduces the abstract XENIO_PROTOCOL that will be used to
communicate the Xen grant table address to drivers supporting this
protocol. Primary purpose is allowing us to change the XenBusDxe
implementation so that it can support non-PCI Xen implementations
such as Xen on ARM.
Contributed-und
On non-PCI Xen guests (such as ARM), the XenBus root is not a PCI
device but an abstract 'platform' device. Add a dedicated Vendor
Hardware device path GUID to identify this node.
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Laszlo Ersek
Signed-off-by: Ard Biesheuvel
---
This moves all of the Xen hypercall code that was private to XenBusDxe
to a new library class XenHypercallLib. This will allow us to reimplement
it for ARM, and to export the Xen hypercall functionality to other parts
of the code, such as a Xen console SerialPortLib driver.
Contributed-under: Tian
This implements the following synchronization primitives for AArch64 (GCC)
and ARM (GCC & RVCT):
InternalSyncCompareExchange32
InternalSyncCompareExchange64
InternalSyncIncrement
InternalSyncDecrement
Note: these functions are implemented using the exclusive monitor,
which implies that they can o
While Xen on Intel uses a virtual PCI device to communicate the
base address of the grant table, the ARM implementation uses a DT
node, which is fundamentally incompatible with the way XenBusDxe is
implemented, i.e., as a UEFI Driver Model implementation for a PCI
device.
Contributed-under: TianoC
Our primary user QEMU/mach-virt presents us with a FDT blob padded
to 64 KB with plenty of room to set additional properties. However,
in the general case, we should only add properties after making sure
there is enough room available.
Contributed-under: TianoCore Contribution Agreement 1.0
Review
This refactors the Xen hypercall implementation that is part of the
XenBusDxe driver, in preparation of splitting it off entirely into
a XenHypercallLib library. This involves:
- removing the dependency on XENBUS_DEVICE* pointers in the XenHypercall()
prototypes
- moving the discovered hyperpage
Prepare for making XenBusDxe suitable for use with non-PCI devices
(such as the DT node exposed by Xen on ARM) by introducing a separate
DXE driver that binds to the Xen virtual PCI device and exposes the
abstract XENIO_PROTOCOL for XenBusDxe to bind against.
Contributed-under: TianoCore Contribut
This patch updates XenBusDxe to use the 16-bit compare and exchange
function that was introduced for this purpose to the
BaseSynchronizationLib. It also provides a new generic implementation
of TestAndClearBit () using the same 16-bit compare and exchange, making
this module fully architecture agno
This implements the function InterlockedCompareExchange16 () for all
architectures, using architecture and toolchain specific intrinsics
or primitive assembler instructions.
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Olivier Martin
Signed-off-by: Ard Biesheuvel
---
Mde
On ARM, xen_pfn_t is 64 bits but the size of a pointer is only
32 bits, so casting between them needs to go via (UINTN). Also
move the xen_pfn_t cast outside the shift so that we can avoid
shifting 64-bit quantities on 32-bit architectures, which may
require runtime library support.
Contributed-un
This is partially motivated by the desire to use PrePi in a virt
environment, and in that configuration, ArmPlatformInitializeSystemMemory()
is never called. But actually, this is a more suitable place anyway.
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Laszlo Ersek
Revie
Tiancore has its private copy of the Xen headers, and all drivers
that depend on it should use the same Xen interface version, so
let's move the #define to xen.h itself.
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Stefano Stabellini
Acked-by: Laszlo Ersek
Signed-off-by:
This implements a MemoryInitPeiLib instance that differs from the
stock ArmPlatformPkg version only in the fact that it does not remove
the memory used by the flash device (FD). The reason is that, when using
PrePi, the DXE core is started immediately and never returns so there is
no reason to pres
Allow the use of patchable PCDs for gArmTokenSpaceGuid.PcdFvBaseAddress
and gArmVirtualizationTokenSpaceGuid.PcdDeviceTreeInitialBaseAddress
by moving them from the [FixedPcd] to the [Pcd] section in the INF file of
PlatformPeiLib.
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-b
Instead of using a dynamic PCD, store the device tree address in a HOB
so that we can also run under a configuration that does not support
dynamic PCDs.
This also adds MemoryAllocationLib to the [LibraryClasses] section of
ArmVirtualizationPlatformLib/ArmVirtualizationPlatformLib.inf, as this
depe
This moves the reference to gArmTokenSpaceGuid.PcdFdBaseAddress
from the [FixedPcd] to the [Pcd] section in the INF file of
PrePiArmPlatformGlobalVariableLib so that its users may choose
to use a patchable PCD instead.
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Olivier Ma
In order to allow a runtime self relocating PrePi instance, change the
allowable PCD types for the following PCDs:
gArmTokenSpaceGuid.PcdSystemMemoryBase
gArmTokenSpaceGuid.PcdSystemMemorySize
gArmTokenSpaceGuid.PcdFdBaseAddress
gArmTokenSpaceGuid.PcdFvBaseAddress
to include PcdsPatchable
This adds support for detecting the presence of a GICv3 interrupt
controller from the device tree, and recording its distributor and
redistributor base addresses in their respective PCDs.
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Olivier Martin
Acked-by: Laszlo Ersek
S
The DT binding for the ARM generic timer describes the secure,
non-secure, virtual and hypervisor timer interrupts, respectively.
However, under virtualization, only the virtual timer is usable, and
the device tree may omit the hypervisor timer interrupt. (Other timer
interrupts cannot be omitted s
To allow a runtime self relocating PrePi instance to discover the base
address of the device tree at runtime, allow the use of a patchable PCD
for gArmVirtualizationTokenSpaceGuid.PcdDeviceTreeInitialBaseAddress.
We will not be using the build time patch tool in this case, but using
a patchable PCD
This series implements support for executing Tianocore inside a Xen
guest domain on 64-bit ARM systems (AArch64)
The first part addresses ARM platform specifics, primarily to allow a
Tianocore binary image to be runtime relocatable, and execute from DRAM.
The second part refactors the XenBus supp
On 02/12/15 01:56, Edward Chicopee wrote:
> I put a DebugPrint(0x, "Hi from SMM\n")) into PiSmmCore.c
> SmmEntryPoint() just to see how often it fires during boot. I didn't see
> it ever fire, even with a debug build. Does QEMU/OVMF not bother doing SMM?
edk2 has SMM support, but OVMF does
On Thu, Feb 12, 2015 at 11:46:04AM +0100, Laszlo Ersek wrote:
> On 02/11/15 21:23, Wei Liu wrote:
> > I had an issue when trying to boot Xen HVM guest with latest OVMF
> > master. Guest crashed with memory violation, and the bisection pointed
> > to 66b280df2 ("OvmfPkg: AcpiPlatformDxe: make depend
Yes, Andrew,
My understanding has always been that the UEFI GetMemoryMap would report the
MMIO region for the system. ACPI device enumerations have a way to report the
MMIO resource that a specific device may use. In addition, OS use the PCI BARs
to find out the MMIO resources that a PCI device
On 02/11/15 21:23, Wei Liu wrote:
> I had an issue when trying to boot Xen HVM guest with latest OVMF
> master. Guest crashed with memory violation, and the bisection pointed
> to 66b280df2 ("OvmfPkg: AcpiPlatformDxe: make dependency on PCI
> enumeration explicit"). That commit made AcpiPlatformDxe
On 12 February 2015 at 15:22, Olivier Martin wrote:
> This patchset ensures the ARM GICv3 driver does not rely on the
> GICv2 legacy mode.
> When using GICv3 without legacy mode, it is required to have
> support for GICv3 in the trusted firmware to declare the Non-Secure
> interrupts as part of th
On 12 February 2015 at 15:22, Olivier Martin wrote:
> From: Ard Biesheuvel
>
> The GICv3 driver must use native mode to drive a GICv3 due to
> the fact that v2 compatibility is optional in the v3 spec.
> However, if v2 compatibility is implemented, it is the default
> and needs to be disabled fir
On Thu, Feb 12, 2015 at 01:23:26AM +, Ni, Ruiyu wrote:
> Wei,
> No you cannot install gEfiPciEnumerationCompleteProtocolGuid in
> PciEnumeratorLight().
>
> For a real platform, PCI BUS is fully enumerated in PciEnumerator()
> and later if reconnect happens, it's light enumerated in
> PciEnumer
The patchset is also available here:
https://github.com/ARM-software/edk2/tree/gicv3-no-legacy
From: Olivier Martin [olivier.mar...@arm.com]
Sent: 12 February 2015 07:22
To: edk2-devel@lists.sourceforge.net
Cc: ard.biesheu...@linaro.org; Olivier Martin
Subj
49 matches
Mail list logo
