Re: [edk2-devel] Getting Synchronous Exception while run avocado-vt tests

[Laszlo Ersek]

On 08/22/19 11:24, Ard Biesheuvel wrote:
> On Thu, 22 Aug 2019 at 10:40, Zhanghailiang
>  wrote:
>>
>> Hi All,
>>
>>
>>
>> We caught an ‘Synchronous Exception’ error while booting VM with uefi 
>> firmware in the avocado-vt tests.
>>
>> The Edk2 version we used is edk2-stable201905. The qemu version is 
>> qemu-4.0.0 and kernel version is 4.19.0.
>>
>> Parts of the log we got from serial is bellow, you can get the full log from 
>> attachment.
>>
>> We can easily reproduce this issue with running avocado-vt tests. Actually, 
>> we tried the new edk2 from upstream,
>>
>> It is still can be reproduced.
>>
>>
>>
>> Reproduce command:
>>
>> # avocado run type_specific.io-github-autotest-qemu.qmp_event_notification 
>> --vt-type qemu --vt-guest-os Guest.Linux.Fedora.29
>>
>>
>>
>> Qemu command is :
>>
> ..
>>
>> It reports that this is a alignment fault from log, We analyzed the 
>> callstack from log:
>>
>> VirtioScsiPassThru-> 
>> VirtioFlush->virtio10SetQueueNotify->Virtio10Transfer->PciIoMemWrite-> 
>> CpuMemoryServiceWrite-> MmioWrite32 <- here, the address is not align.
>>
> 
> The faulting address ends in 0x16, so the access is to the QueueSelect
> field in VIRTIO_PCI_COMMON_CFG. This is a UINT16 field, so the access
> should be 16-bit not 32-bits wide.
> 
> Could you dump the instructions leading up to the first
> Virtio10Transfer() call in Virtio10SetQueueNotify()? (from
> Build/ArmVirtQemu-AARCH64/DEBUG_GCC49/AARCH64/OvmfPkg/Virtio10Dxe/Virtio10/DEBUG/Virtio10.dll)
> 
> 2280:   aa0103e5mov x5, x1
> 2284:   d2800044mov x4, #0x2// #2
> 2288:   d28002c3mov x3, #0x16   // #22
> 228c:   5282mov w2, #0x0// #0
> 2290:   aa0003e1mov x1, x0
> 2294:   aa0603e0mov x0, x6
> 2298:   97fffcf3bl  1664 
> 
> If the size is passed correctly here, we'll have to track down how the
> call gets routed to Mmio32Write instead of Mmio16Write(). Do you have
> any patches on top of edk2-stable-201905 ?

Right -- checking the "QueueSelect" (whole word) references in
Virtio10SetQueueNotify(), the "FieldSize" arguments passed to
Virtio10Transfer() are:

- sizeof SavedQueueSelect
- sizeof Index
- sizeof SavedQueueSelect

and both "SavedQueueSelect" and "Index" are of type UINT16.

Virtio10Transfer() maps (FieldSize==2) to "EfiPciIoWidthUint16".

PciIoMemWrite() can only decrease "Width" (provided
"PcdUnalignedPciIoEnable" is set to TRUE -- which is not the case in
ArmVirtPkg). So "Width" is passed to RootBridgeIoMemWrite() unchanged,
in "MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c".

The latter passes "Width" unchanged to CpuMemoryServiceWrite(), in
"ArmPkg/Drivers/ArmPciCpuIo2Dxe/ArmPciCpuIo2Dxe.c".

That function seems to set "OperationWidth" to "EfiCpuIoWidthUint16"
(value 1, unchanged), which should result in a call to MmioWrite16()...


I have a different question. We recently saw a bunch of Synchronous
Exceptions, but those were not deterministic. Whenever they fired (which
was not always), they popped up in different spots. It turned out to be
a KVM regression, apparently a problem with the vtimer. I believe it was
fixed by a backport of upstream commit 6bc210003dff ("KVM: arm/arm64:
Don't emulate virtual timers on userspace ioctls", 2019-04-25). I could
be totally off-target, of course.

(The RHBZ is , but
*of course* it has to be a private bug; it was reported for the kernel
after all! /s)

Thanks
Laszlo

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#46231): https://edk2.groups.io/g/devel/message/46231
Mute This Topic: https://groups.io/mt/32987799/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/1] UefiCpuPkg/PiSmmCpuDxeSmm: Add check for pointer Pml5Entry

[Laszlo Ersek]

On 07/31/19 07:56, Shenglei Zhang wrote:
> The pointer Pml5Entry, returned from call to function
> AllocatePageTableMemory, may be null.
> So add check for it.
> 
> Cc: Eric Dong 
> Cc: Ray Ni 
> Cc: Laszlo Ersek 
> Signed-off-by: Shenglei Zhang 
> ---
>  UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
> index a3b62f778741..d7af3b6d7941 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
> @@ -375,6 +375,7 @@ SmmInitPageTable (
>  // Fill PML5 entry
>  //
>  Pml5Entry = (UINT64*)AllocatePageTableMemory (1);
> +ASSERT (Pml5Entry != NULL);
>  *Pml5Entry = (UINTN) Pml4Entry | mAddressEncMask | PAGE_ATTRIBUTE_BITS;
>  ZeroMem (Pml5Entry + 1, EFI_PAGE_SIZE - sizeof (*Pml5Entry));
>  //
> 

I'm quite unhappy about this *pattern* in "PageTbl.c", but I must agree
that this patch at least makes the new 5-level paging code consistent
with the pattern.

Laszlo

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#44675): https://edk2.groups.io/g/devel/message/44675
Mute This Topic: https://groups.io/mt/32662314/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2] [RFC] Plan to delete ShellBinPkg from edk2/master

[Laszlo Ersek]

On 04/03/19 17:49, Kinney, Michael D wrote:
> Laszlo,
> 
> I think it makes sense to post validated shell binaries
> with the edk2-stable tag releases.  GitHub does support
> this when a release tag is made.
> 
> However, we would need to make it simple for a platform
> to use a binary from that location.  We may need some
> enhancements to pull in binary artifacts from different
> locations to support a platform build that uses one or
> more pre-built binaries.

Can PREBUILD scripts (written by platform owners) download the required
binaries?

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

Re: [edk2] [RFC PATCH v1 0/8] Duplicate 8259/8254 components in OvmfPkg

[Laszlo Ersek]

On 04/03/19 14:13, Laszlo Ersek wrote:
> On 04/03/19 14:10, Laszlo Ersek wrote:
>> On 04/03/19 09:00, Hao Wu wrote:
>>> This series is also available at:
>>> https://github.com/hwu25/edk2/tree/ovmf_8259_8254_rfcv1
>>>
>>>
>>> As a sub-task to remove the IntelFrameworkPkg (BZ-1604),
>>>
>>> 8259InterruptControllerDxe driver (PcAtChipsetPkg)
>>> Legacy8259 protocol (IntelFrameworkPkg)
>>> 8254TimerDxe driver (PcAtChipsetPkg)
>>>
>>> will be removed in the near future. Meanwhile, OVMF will still require
>>> those components (due to CSM support & HPET emulation stability concern).
>>>
>>> Thus, the series will copy the below 8259/8254 components:
>>>
>>> A. 8259InterruptControllerDxe driver (PcAtChipsetPkg)
>>> B. Two 8259 related PCDs (PcAtChipsetPkg)
>>> C. Legacy8259 protocol (IntelFrameworkPkg)
>>> D. 8254TimerDxe driver (PcAtChipsetPkg)
>>>
>>> in the OvmfPkg to address the above-mentioned issue.
>>>
>>>
>>> Tests done for the proposed series:
>>>
>>> A. OvmfPkg build pass for VS2015 & GCC5 tool chains;
>>> B. Boot to Shell with commands:
>>>   qemu-system-x86_64.exe -pflash \OVMF.fd -debugcon 
>>> file:boot.log -global isa-debugcon.iobase=0x402
>>>   qemu-system-x86_64.exe -machine q35 -pflash \OVMF.fd -debugcon 
>>> file:boot.log -global isa-debugcon.iobase=0x402
>>> C. 'stall X' command under Shell to verify the timer is working properly.
>>>
>>>
>>> (Please note that there will be a subsequent patch to remove the 8259/8254
>>> components after platforms dropping the dependencies on them.)
>>>
>>> Cc: Jordan Justen 
>>> Cc: Laszlo Ersek 
>>> Cc: Ard Biesheuvel 
>>> Cc: David Woodhouse 
>>> Cc: Ray Ni 
>>>
>>>
>>> Hao Wu (8):
>>>   OvmfPkg: Copy 8259InterruptControllerDxe driver from PcAtChipsetPkg
>>>   OvmfPkg: Copy Legacy8259 protocol definitions from IntelFrameworkPkg
>>>   OvmfPkg/OvmfPkg.dec: Add 8259-related PCDs in OVMF DEC file
>>>   OvmfPkg/8259InterruptControllerDxe: Update to make it build for OVMF
>>>   OvmfPkg/AcpiPlatformDxe: Consume the 8259 PCD defined in OvmfPkg
>>>   OvmfPkg: Copy 8254TimerDxe driver from PcAtChipsetPkg
>>>   OvmfPkg/8254TimerDxe: Update to make it build for OVMF
>>>   OvmfPkg: Update DSC/FDF files to consume 8259/8254 drivers in OvmfPkg
>>
>> While I'm reviewing the patches individually, let me make some general
>> comments:
>>
>> - please don't push the series before April 9th (i.e., before the end of
>> the file addition/removal freeze due to
>> <https://bugzilla.tianocore.org/show_bug.cgi?id=1373>)
>>
>> - if/when you push the series, please make sure that *all* files added
>> (copied) under OvmfPkg get the new license block format, i.e. the SPDX
>> license identifier only.
> 
> ... in fact, at that time, the license blocks under the *source*
> packages (PcAtChipsetPkg and IntelFrameworkPkg) will have been updated,
> so you will have to redo the copying steps anyway (and you can verify
> those on your end: "git show --find-copies-harder" should show now
> modifications as part of the copy operations).

Sigh. I meant

  "git show --find-copies-harder" should show *no* modifications as part
  of the copy operations

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

Re: [edk2] [RFC PATCH v1 8/8] OvmfPkg: Update DSC/FDF files to consume 8259/8254 drivers in OvmfPkg

[Laszlo Ersek]

On 04/03/19 09:00, Hao Wu wrote:
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1496
> 
> This commit updates the OVMF DSC/FDF files to consume the copied
> 8259InterruptControllerDxe and 8254TimerDxe drivers within OvmfPkg.
> 
> The unconsumed PCD:
> gPcAtChipsetPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel
> 
> is removed from DSC files as well.
> 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: David Woodhouse 
> Cc: Ray Ni 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Hao Wu 
> ---
>  OvmfPkg/OvmfPkgIa32.dsc| 3 ---
>  OvmfPkg/OvmfPkgIa32X64.dsc | 3 ---
>  OvmfPkg/OvmfPkgX64.dsc | 3 ---
>  OvmfPkg/OvmfPkgIa32.fdf| 4 ++--
>  OvmfPkg/OvmfPkgIa32X64.fdf | 4 ++--
>  OvmfPkg/OvmfPkgX64.fdf | 4 ++--
>  6 files changed, 6 insertions(+), 15 deletions(-)
> 
> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> index d88295f9fd..692da9584d 100644
> --- a/OvmfPkg/OvmfPkgIa32.dsc
> +++ b/OvmfPkg/OvmfPkgIa32.dsc
> @@ -516,7 +516,6 @@
>  !endif
>  
># IRQs 5, 9, 10, 11 are level-triggered
> -  gPcAtChipsetPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20
>gUefiOvmfPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20
>  
># Point to the MdeModulePkg/Application/UiApp/UiApp.inf
> @@ -669,11 +668,9 @@
>}
>  
>MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
> -  PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
>OvmfPkg/8259InterruptControllerDxe/8259.inf
>UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
>UefiCpuPkg/CpuDxe/CpuDxe.inf
> -  PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
>OvmfPkg/8254TimerDxe/8254Timer.inf
>OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
>OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
> index a83b6f448e..01b2530064 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
> @@ -522,7 +522,6 @@
>  !endif
>  
># IRQs 5, 9, 10, 11 are level-triggered
> -  gPcAtChipsetPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20
>gUefiOvmfPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20
>  
># Point to the MdeModulePkg/Application/UiApp/UiApp.inf
> @@ -678,11 +677,9 @@
>}
>  
>MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
> -  PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
>OvmfPkg/8259InterruptControllerDxe/8259.inf
>UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
>UefiCpuPkg/CpuDxe/CpuDxe.inf
> -  PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
>OvmfPkg/8254TimerDxe/8254Timer.inf
>OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
>OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
> index ad9816a165..444a00c87d 100644
> --- a/OvmfPkg/OvmfPkgX64.dsc
> +++ b/OvmfPkg/OvmfPkgX64.dsc
> @@ -521,7 +521,6 @@
>  !endif
>  
># IRQs 5, 9, 10, 11 are level-triggered
> -  gPcAtChipsetPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20
>gUefiOvmfPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20
>  
># Point to the MdeModulePkg/Application/UiApp/UiApp.inf
> @@ -676,11 +675,9 @@
>}
>  
>MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
> -  PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
>OvmfPkg/8259InterruptControllerDxe/8259.inf
>UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
>UefiCpuPkg/CpuDxe/CpuDxe.inf
> -  PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
>OvmfPkg/8254TimerDxe/8254Timer.inf
>OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
>OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
> diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
> index 006ea9a415..423984b4b9 100644
> --- a/OvmfPkg/OvmfPkgIa32.fdf
> +++ b/OvmfPkg/OvmfPkgIa32.fdf
> @@ -213,10 +213,10 @@ INF  MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
>  INF  MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
>  INF  MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
>  INF  MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
> -INF  PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
> +INF  OvmfPkg/8259InterruptControllerDxe/8259.inf
>  INF  UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
>  INF  UefiCpuPkg/CpuDxe/CpuDxe.inf
> -INF  PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
> +INF  OvmfPkg/8254TimerDxe/8254Timer.inf
>  INF  OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
>  INF  OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
>  INF  MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf
> diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
> index 6c40540202..45eb561e3f 100644
> --- a/OvmfPkg/OvmfPkgIa3

Re: [edk2] [RFC PATCH v1 7/8] OvmfPkg/8254TimerDxe: Update to make it build for OVMF

[Laszlo Ersek]

On 04/03/19 09:00, Hao Wu wrote:
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1496
> 
> This commit will remove the IntelFrameworkPkg DEC file dependency in the
> driver INF file.
> 
> A new GUID has been updated for the INF file.
> 
> Corresponding changes have been made in OVMF DSC files as well in order to
> verify the build.

(1) Please add the same hint that I asked for under v1 4/8.

With that:

Reviewed-by: Laszlo Ersek 

Thanks
Laszlo

> 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: David Woodhouse 
> Cc: Ray Ni 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Hao Wu 
> ---
>  OvmfPkg/OvmfPkgIa32.dsc| 1 +
>  OvmfPkg/OvmfPkgIa32X64.dsc | 1 +
>  OvmfPkg/OvmfPkgX64.dsc | 1 +
>  OvmfPkg/8254TimerDxe/8254Timer.inf | 6 +++---
>  4 files changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> index 47182f0cad..d88295f9fd 100644
> --- a/OvmfPkg/OvmfPkgIa32.dsc
> +++ b/OvmfPkg/OvmfPkgIa32.dsc
> @@ -674,6 +674,7 @@
>UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
>UefiCpuPkg/CpuDxe/CpuDxe.inf
>PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
> +  OvmfPkg/8254TimerDxe/8254Timer.inf
>OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
>OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
>MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf {
> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
> index d9603a7107..a83b6f448e 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
> @@ -683,6 +683,7 @@
>UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
>UefiCpuPkg/CpuDxe/CpuDxe.inf
>PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
> +  OvmfPkg/8254TimerDxe/8254Timer.inf
>OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
>OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
>MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf {
> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
> index 2cc39d54b0..ad9816a165 100644
> --- a/OvmfPkg/OvmfPkgX64.dsc
> +++ b/OvmfPkg/OvmfPkgX64.dsc
> @@ -681,6 +681,7 @@
>UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
>UefiCpuPkg/CpuDxe/CpuDxe.inf
>PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
> +  OvmfPkg/8254TimerDxe/8254Timer.inf
>OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
>OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
>MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf {
> diff --git a/OvmfPkg/8254TimerDxe/8254Timer.inf 
> b/OvmfPkg/8254TimerDxe/8254Timer.inf
> index 46cf01de39..93bee768ed 100644
> --- a/OvmfPkg/8254TimerDxe/8254Timer.inf
> +++ b/OvmfPkg/8254TimerDxe/8254Timer.inf
> @@ -1,7 +1,7 @@
>  ## @file
>  # 8254 timer driver that provides Timer Arch protocol.
>  #
> -# Copyright (c) 2005 - 2018, Intel Corporation. All rights reserved.
> +# Copyright (c) 2005 - 2019, Intel Corporation. All rights reserved.
>  # 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
> @@ -16,7 +16,7 @@
>INF_VERSION= 0x00010005
>BASE_NAME  = Timer
>MODULE_UNI_FILE= Timer.uni
> -  FILE_GUID  = f2765dec-6b41-11d5-8e71-00902707b35e
> +  FILE_GUID  = C190FE35-44AA-41A1-8AEA-4947BC60E09D
>MODULE_TYPE= DXE_DRIVER
>VERSION_STRING = 1.0
>  
> @@ -24,7 +24,7 @@
>  
>  [Packages]
>MdePkg/MdePkg.dec
> -  IntelFrameworkPkg/IntelFrameworkPkg.dec
> +  OvmfPkg/OvmfPkg.dec
>  
>  [LibraryClasses]
>UefiBootServicesTableLib
> 

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

Re: [edk2] [RFC PATCH v1 6/8] OvmfPkg: Copy 8254TimerDxe driver from PcAtChipsetPkg

[Laszlo Ersek]

On 04/03/19 09:00, Hao Wu wrote:
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1496
> 
> This commit copies the exact 8254TimerDxe driver from PcAtChipsetPkg to
> OvmfPkg.
> 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: David Woodhouse 
> Cc: Ray Ni 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Hao Wu 
> ---
>  OvmfPkg/8254TimerDxe/8254Timer.inf  |  48 +++
>  OvmfPkg/8254TimerDxe/Timer.h| 191 +
>  OvmfPkg/8254TimerDxe/Timer.c| 407 
>  OvmfPkg/8254TimerDxe/Timer.uni  |  22 ++
>  OvmfPkg/8254TimerDxe/TimerExtra.uni |  20 +
>  5 files changed, 688 insertions(+)

Reviewed-by: Laszlo Ersek 

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

Re: [edk2] [RFC PATCH v1 5/8] OvmfPkg/AcpiPlatformDxe: Consume the 8259 PCD defined in OvmfPkg

[Laszlo Ersek]

On 04/03/19 09:00, Hao Wu wrote:
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1496
> 
> Several updates have been made to the OvmfPkg/AcpiPlatformDxe driver to
> drop its dependency on PcAtChipsetPkg:
> 
> A) Consumes the PCD 'Pcd8259LegacyModeEdgeLevel' defined within OvmfPkg;
> B) Remove the PcAtChipsetPkg DEC file dependency in the driver INF file.
> 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: David Woodhouse 
> Cc: Ray Ni 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Hao Wu 
> ---
>  OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf 
> b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
> index 8440e7b343..24e2c0373f 100644
> --- a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
> +++ b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
> @@ -1,7 +1,7 @@
>  ## @file
>  #  OVMF ACPI Platform Driver
>  #
> -#  Copyright (c) 2008 - 2018, Intel Corporation. All rights reserved.
> +#  Copyright (c) 2008 - 2019, Intel Corporation. All rights reserved.
>  #  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
> @@ -42,7 +42,6 @@
>MdeModulePkg/MdeModulePkg.dec
>OvmfPkg/OvmfPkg.dec
>UefiCpuPkg/UefiCpuPkg.dec
> -  PcAtChipsetPkg/PcAtChipsetPkg.dec
>  
>  [LibraryClasses]
>UefiLib
> @@ -72,7 +71,7 @@
>gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiTableStorageFile
>gEfiMdeModulePkgTokenSpaceGuid.PcdPciDisableBusEnumeration
>gUefiCpuPkgTokenSpaceGuid.PcdCpuLocalApicBaseAddress
> -  gPcAtChipsetPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel
> +  gUefiOvmfPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFdBaseAddress
>  
>  [Depex]
> 

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

Re: [edk2] [RFC PATCH v1 4/8] OvmfPkg/8259InterruptControllerDxe: Update to make it build for OVMF

[Laszlo Ersek]

On 04/03/19 09:00, Hao Wu wrote:
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1496
> 
> Several updates have been made to the
> OvmfPkg/8259InterruptControllerDxe driver to make it build under OvmfPkg:
> 
> A) Update the driver INF file to consume PCDs defined within OvmfPkg;
> B) Remove the unnecessary dependency on the IntelFrameworkPkg header file
>'FrameworkDxe.h';
> C) Remove the IntelFrameworkPkg & PcAtChipsetPkg DEC files dependency in
>the driver INF file.
> 
> A new GUID has been updated for the INF file.
> 
> Corresponding changes have been made in OVMF DSC files as well in order to
> verify the build.

(1) This patch is really well done, but we need an extra hint here, in
the last paragraph of the commit message, namely that the DSC and FDF
files will get a final update (= removals) later in this series.

With that spelled out:

Reviewed-by: Laszlo Ersek 

Thanks
Laszlo

> 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: David Woodhouse 
> Cc: Ray Ni 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Hao Wu 
> ---
>  OvmfPkg/OvmfPkgIa32.dsc |  2 ++
>  OvmfPkg/OvmfPkgIa32X64.dsc  |  2 ++
>  OvmfPkg/OvmfPkgX64.dsc  |  2 ++
>  OvmfPkg/8259InterruptControllerDxe/8259.inf | 11 +--
>  OvmfPkg/8259InterruptControllerDxe/8259.h   |  4 +---
>  5 files changed, 12 insertions(+), 9 deletions(-)
> 
> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> index f55ab5a3d2..47182f0cad 100644
> --- a/OvmfPkg/OvmfPkgIa32.dsc
> +++ b/OvmfPkg/OvmfPkgIa32.dsc
> @@ -517,6 +517,7 @@
>  
># IRQs 5, 9, 10, 11 are level-triggered
>gPcAtChipsetPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20
> +  gUefiOvmfPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20
>  
># Point to the MdeModulePkg/Application/UiApp/UiApp.inf
>gEfiMdeModulePkgTokenSpaceGuid.PcdBootManagerMenuFile|{ 0x21, 0xaa, 0x2c, 
> 0x46, 0x14, 0x76, 0x03, 0x45, 0x83, 0x6e, 0x8a, 0xb6, 0xf4, 0x66, 0x23, 0x31 }
> @@ -669,6 +670,7 @@
>  
>MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
>PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
> +  OvmfPkg/8259InterruptControllerDxe/8259.inf
>UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
>UefiCpuPkg/CpuDxe/CpuDxe.inf
>PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
> index 5c9bdf034e..d9603a7107 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
> @@ -523,6 +523,7 @@
>  
># IRQs 5, 9, 10, 11 are level-triggered
>gPcAtChipsetPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20
> +  gUefiOvmfPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20
>  
># Point to the MdeModulePkg/Application/UiApp/UiApp.inf
>gEfiMdeModulePkgTokenSpaceGuid.PcdBootManagerMenuFile|{ 0x21, 0xaa, 0x2c, 
> 0x46, 0x14, 0x76, 0x03, 0x45, 0x83, 0x6e, 0x8a, 0xb6, 0xf4, 0x66, 0x23, 0x31 }
> @@ -678,6 +679,7 @@
>  
>MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
>PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
> +  OvmfPkg/8259InterruptControllerDxe/8259.inf
>UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
>UefiCpuPkg/CpuDxe/CpuDxe.inf
>PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
> index 2943e9e8af..2cc39d54b0 100644
> --- a/OvmfPkg/OvmfPkgX64.dsc
> +++ b/OvmfPkg/OvmfPkgX64.dsc
> @@ -522,6 +522,7 @@
>  
># IRQs 5, 9, 10, 11 are level-triggered
>gPcAtChipsetPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20
> +  gUefiOvmfPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20
>  
># Point to the MdeModulePkg/Application/UiApp/UiApp.inf
>gEfiMdeModulePkgTokenSpaceGuid.PcdBootManagerMenuFile|{ 0x21, 0xaa, 0x2c, 
> 0x46, 0x14, 0x76, 0x03, 0x45, 0x83, 0x6e, 0x8a, 0xb6, 0xf4, 0x66, 0x23, 0x31 }
> @@ -676,6 +677,7 @@
>  
>MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
>PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
> +  OvmfPkg/8259InterruptControllerDxe/8259.inf
>UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
>UefiCpuPkg/CpuDxe/CpuDxe.inf
>PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
> diff --git a/OvmfPkg/8259InterruptControllerDxe/8259.inf 
> b/OvmfPkg/8259InterruptControllerDxe/8259.inf
> index 1d9be675e3..c5a1385418 100644
> --- a/OvmfPkg/8259InterruptControllerDxe/8259.inf
> +++ b/OvmfPkg/8259InterruptControllerDxe/8259.inf
> @@ -1,7 +1,7 @@
>  ## @file
>  # 8259 Interrupt Controller driver that provides Legacy 8259 protocol.
>  #
> -# Copyright (c) 2005 - 2018, Intel Corporation. All rights reserved.
> +# Copyright (c) 2005 - 2019, Intel Corporation. All rights reserved.
>  # This program and the

Re: [edk2] [RFC PATCH v1 3/8] OvmfPkg/OvmfPkg.dec: Add 8259-related PCDs in OVMF DEC file

[Laszlo Ersek]

On 04/03/19 09:00, Hao Wu wrote:
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1496
> 
> According to the DEC file in PcAtChipsetPkg, this commit adds the two
> 8259-driver-related PCDs into the OvmfPkg DEC file.
> 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: David Woodhouse 
> Cc: Ray Ni 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Hao Wu 
> ---
>  OvmfPkg/OvmfPkg.dec | 26 
>  1 file changed, 26 insertions(+)
> 
> diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
> index fb89ebf3ad..cb838422aa 100644
> --- a/OvmfPkg/OvmfPkg.dec
> +++ b/OvmfPkg/OvmfPkg.dec
> @@ -128,6 +128,32 @@
>gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize|0x0|UINT32|0x1a
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDecompressionScratchEnd|0x0|UINT32|0x1f
>  
> +  ## Pcd8259LegacyModeMask defines the default mask value for platform. This
> +  #  value is determined.
> +  #  1) If platform only support pure UEFI, value should be set to 0x or
> +  # 0xFFFE; Because only clock interrupt is allowed in legacy mode in 
> pure
> +  # UEFI platform.
> +  #  2) If platform install CSM and use thunk module:
> +  # a) If thunk call provided by CSM binary requires some legacy 
> interrupt
> +  #support, the corresponding bit should be opened as 0.
> +  #For example, if keyboard interfaces provided CSM binary use legacy
> +  #keyboard interrupt in 8259 bit 1, then the value should be set to
> +  #0xFFFC.
> +  # b) If all thunk call provied by CSM binary do not require legacy
> +  #interrupt support, value should be set to 0x or 0xFFFE.
> +  #
> +  #  The default value of legacy mode mask could be changed by
> +  #  EFI_LEGACY_8259_PROTOCOL->SetMask(). But it is rarely need change it
> +  #  except some special cases such as when initializing the CSM binary, it
> +  #  should be set to 0x to mask all legacy interrupt. Please restore the
> +  #  original legacy mask value if changing is made for these special case.
> +  gUefiOvmfPkgTokenSpaceGuid.Pcd8259LegacyModeMask|0x|UINT16|0x28
> +
> +  ## Pcd8259LegacyModeEdgeLevel defines the default edge level for legacy
> +  #  mode's interrrupt controller.
> +  #  For the corresponding bits, 0 = Edge triggered and 1 = Level triggered.
> +  gUefiOvmfPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x|UINT16|0x29
> +
>  [PcdsDynamic, PcdsDynamicEx]
>gUefiOvmfPkgTokenSpaceGuid.PcdEmuVariableEvent|0|UINT64|2
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashVariablesEnable|FALSE|BOOLEAN|0x10
> 

Thank you for wrapping the comments so nicely!


(1) In PcAtChipsetPkg.dec, both PCDs are declared under:

[PcdsFixedAtBuild, PcdsDynamic, PcdsDynamicEx, PcdsPatchableInModule]

but in OvmfPkg, this patch introduces both PCDs under just

[PcdsFixedAtBuild]

I think that's fine for now, but please mention this change in the
commit message.


(2) OVMF's PCD token space seems to have some holes, namely at: 3
decimal, 5 decimal, and 0x17.

Can you introduce the new PCDs with tokens 3 and 5, just to decrease the
fragmentation?


With (1) and (2) addressed:

Reviewed-by: Laszlo Ersek 

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

Re: [edk2] [RFC PATCH v1 2/8] OvmfPkg: Copy Legacy8259 protocol definitions from IntelFrameworkPkg

[Laszlo Ersek]

On 04/03/19 09:00, Hao Wu wrote:
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1496
> 
> This commit copies the exact Legacy8259 protocol header file from
> IntelFrameworkPkg to OvmfPkg. Also, the protocol GUID definition is
> duplicated in the OvmfPkg DEC file.
> 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: David Woodhouse 
> Cc: Ray Ni 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Hao Wu 
> ---
>  OvmfPkg/OvmfPkg.dec   |   3 +-
>  OvmfPkg/Include/Protocol/Legacy8259.h | 297 
>  2 files changed, 299 insertions(+), 1 deletion(-)
> 
> diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
> index e50c6179a2..fb89ebf3ad 100644
> --- a/OvmfPkg/OvmfPkg.dec
> +++ b/OvmfPkg/OvmfPkg.dec
> @@ -1,7 +1,7 @@
>  ## @file
>  #  EFI/Framework Open Virtual Machine Firmware (OVMF) platform
>  #
> -#  Copyright (c) 2006 - 2013, Intel Corporation. All rights reserved.
> +#  Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
>  #
>  #  This program and the accompanying materials
>  #  are licensed and made available under the terms and conditions of the BSD 
> License
> @@ -89,6 +89,7 @@
>gXenBusProtocolGuid = {0x3d3ca290, 0xb9a5, 0x11e3, {0xb7, 
> 0x5d, 0xb8, 0xac, 0x6f, 0x7d, 0x65, 0xe6}}
>gXenIoProtocolGuid  = {0x6efac84f, 0x0ab0, 0x4747, {0x81, 
> 0xbe, 0x85, 0x55, 0x62, 0x59, 0x04, 0x49}}
>gIoMmuAbsentProtocolGuid= {0xf8775d50, 0x8abd, 0x4adf, {0x92, 
> 0xac, 0x85, 0x3e, 0x51, 0xf6, 0xc8, 0xdc}}
> +  gEfiLegacy8259ProtocolGuid  = {0x38321dba, 0x4fe0, 0x4e17, {0x8a, 
> 0xec, 0x41, 0x30, 0x55, 0xea, 0xed, 0xc1}}
>  
>  [PcdsFixedAtBuild]
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase|0x0|UINT32|0

(This comment is not about the patch, but your git setup.)

Please update your git config so that "git format-patch" and its friends
display the INI-style section, such as [Protocols], in the diff hunk
headers. The expected result is:

@@ -89,6 +89,7 @@ [Protocols]
  ^^^

You can find documentation at:

-
https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-guide-for-edk2-contributors-and-maintainers#contrib-05
(see the 'diff.ini.xfuncname' setting)

-
https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-guide-for-edk2-contributors-and-maintainers#contrib-09

For this patch:

Reviewed-by: Laszlo Ersek 

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

Re: [edk2] [RFC PATCH v1 0/8] Duplicate 8259/8254 components in OvmfPkg

[Laszlo Ersek]

On 04/03/19 14:10, Laszlo Ersek wrote:
> On 04/03/19 09:00, Hao Wu wrote:
>> This series is also available at:
>> https://github.com/hwu25/edk2/tree/ovmf_8259_8254_rfcv1
>>
>>
>> As a sub-task to remove the IntelFrameworkPkg (BZ-1604),
>>
>> 8259InterruptControllerDxe driver (PcAtChipsetPkg)
>> Legacy8259 protocol (IntelFrameworkPkg)
>> 8254TimerDxe driver (PcAtChipsetPkg)
>>
>> will be removed in the near future. Meanwhile, OVMF will still require
>> those components (due to CSM support & HPET emulation stability concern).
>>
>> Thus, the series will copy the below 8259/8254 components:
>>
>> A. 8259InterruptControllerDxe driver (PcAtChipsetPkg)
>> B. Two 8259 related PCDs (PcAtChipsetPkg)
>> C. Legacy8259 protocol (IntelFrameworkPkg)
>> D. 8254TimerDxe driver (PcAtChipsetPkg)
>>
>> in the OvmfPkg to address the above-mentioned issue.
>>
>>
>> Tests done for the proposed series:
>>
>> A. OvmfPkg build pass for VS2015 & GCC5 tool chains;
>> B. Boot to Shell with commands:
>>   qemu-system-x86_64.exe -pflash \OVMF.fd -debugcon file:boot.log 
>> -global isa-debugcon.iobase=0x402
>>   qemu-system-x86_64.exe -machine q35 -pflash \OVMF.fd -debugcon 
>> file:boot.log -global isa-debugcon.iobase=0x402
>> C. 'stall X' command under Shell to verify the timer is working properly.
>>
>>
>> (Please note that there will be a subsequent patch to remove the 8259/8254
>> components after platforms dropping the dependencies on them.)
>>
>> Cc: Jordan Justen 
>> Cc: Laszlo Ersek 
>> Cc: Ard Biesheuvel 
>> Cc: David Woodhouse 
>> Cc: Ray Ni 
>>
>>
>> Hao Wu (8):
>>   OvmfPkg: Copy 8259InterruptControllerDxe driver from PcAtChipsetPkg
>>   OvmfPkg: Copy Legacy8259 protocol definitions from IntelFrameworkPkg
>>   OvmfPkg/OvmfPkg.dec: Add 8259-related PCDs in OVMF DEC file
>>   OvmfPkg/8259InterruptControllerDxe: Update to make it build for OVMF
>>   OvmfPkg/AcpiPlatformDxe: Consume the 8259 PCD defined in OvmfPkg
>>   OvmfPkg: Copy 8254TimerDxe driver from PcAtChipsetPkg
>>   OvmfPkg/8254TimerDxe: Update to make it build for OVMF
>>   OvmfPkg: Update DSC/FDF files to consume 8259/8254 drivers in OvmfPkg
> 
> While I'm reviewing the patches individually, let me make some general
> comments:
> 
> - please don't push the series before April 9th (i.e., before the end of
> the file addition/removal freeze due to
> <https://bugzilla.tianocore.org/show_bug.cgi?id=1373>)
> 
> - if/when you push the series, please make sure that *all* files added
> (copied) under OvmfPkg get the new license block format, i.e. the SPDX
> license identifier only.

... in fact, at that time, the license blocks under the *source*
packages (PcAtChipsetPkg and IntelFrameworkPkg) will have been updated,
so you will have to redo the copying steps anyway (and you can verify
those on your end: "git show --find-copies-harder" should show now
modifications as part of the copy operations).

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

Re: [edk2] [RFC PATCH v1 0/8] Duplicate 8259/8254 components in OvmfPkg

[Laszlo Ersek]

On 04/03/19 09:00, Hao Wu wrote:
> This series is also available at:
> https://github.com/hwu25/edk2/tree/ovmf_8259_8254_rfcv1
> 
> 
> As a sub-task to remove the IntelFrameworkPkg (BZ-1604),
> 
> 8259InterruptControllerDxe driver (PcAtChipsetPkg)
> Legacy8259 protocol (IntelFrameworkPkg)
> 8254TimerDxe driver (PcAtChipsetPkg)
> 
> will be removed in the near future. Meanwhile, OVMF will still require
> those components (due to CSM support & HPET emulation stability concern).
> 
> Thus, the series will copy the below 8259/8254 components:
> 
> A. 8259InterruptControllerDxe driver (PcAtChipsetPkg)
> B. Two 8259 related PCDs (PcAtChipsetPkg)
> C. Legacy8259 protocol (IntelFrameworkPkg)
> D. 8254TimerDxe driver (PcAtChipsetPkg)
> 
> in the OvmfPkg to address the above-mentioned issue.
> 
> 
> Tests done for the proposed series:
> 
> A. OvmfPkg build pass for VS2015 & GCC5 tool chains;
> B. Boot to Shell with commands:
>   qemu-system-x86_64.exe -pflash \OVMF.fd -debugcon file:boot.log 
> -global isa-debugcon.iobase=0x402
>   qemu-system-x86_64.exe -machine q35 -pflash \OVMF.fd -debugcon 
> file:boot.log -global isa-debugcon.iobase=0x402
> C. 'stall X' command under Shell to verify the timer is working properly.
> 
> 
> (Please note that there will be a subsequent patch to remove the 8259/8254
> components after platforms dropping the dependencies on them.)
> 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: David Woodhouse 
> Cc: Ray Ni 
> 
> 
> Hao Wu (8):
>   OvmfPkg: Copy 8259InterruptControllerDxe driver from PcAtChipsetPkg
>   OvmfPkg: Copy Legacy8259 protocol definitions from IntelFrameworkPkg
>   OvmfPkg/OvmfPkg.dec: Add 8259-related PCDs in OVMF DEC file
>   OvmfPkg/8259InterruptControllerDxe: Update to make it build for OVMF
>   OvmfPkg/AcpiPlatformDxe: Consume the 8259 PCD defined in OvmfPkg
>   OvmfPkg: Copy 8254TimerDxe driver from PcAtChipsetPkg
>   OvmfPkg/8254TimerDxe: Update to make it build for OVMF
>   OvmfPkg: Update DSC/FDF files to consume 8259/8254 drivers in OvmfPkg

While I'm reviewing the patches individually, let me make some general
comments:

- please don't push the series before April 9th (i.e., before the end of
the file addition/removal freeze due to
<https://bugzilla.tianocore.org/show_bug.cgi?id=1373>)

- if/when you push the series, please make sure that *all* files added
(copied) under OvmfPkg get the new license block format, i.e. the SPDX
license identifier only.

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

Re: [edk2] [RFC PATCH v1 1/8] OvmfPkg: Copy 8259InterruptControllerDxe driver from PcAtChipsetPkg

[Laszlo Ersek]

On 04/03/19 09:00, Hao Wu wrote:
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1496
> 
> This commit copies the exact 8259InterruptControllerDxe driver from
> PcAtChipsetPkg to OvmfPkg.
> 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: David Woodhouse 
> Cc: Ray Ni 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Hao Wu 
> ---
>  OvmfPkg/8259InterruptControllerDxe/8259.inf|  52 ++
>  OvmfPkg/8259InterruptControllerDxe/8259.h  | 226 +++
>  OvmfPkg/8259InterruptControllerDxe/8259.c  | 628 
> 
>  OvmfPkg/8259InterruptControllerDxe/Legacy8259.uni  |  22 +
>  OvmfPkg/8259InterruptControllerDxe/Legacy8259Extra.uni |  20 +
>  5 files changed, 948 insertions(+)
> 
> diff --git a/OvmfPkg/8259InterruptControllerDxe/8259.inf 
> b/OvmfPkg/8259InterruptControllerDxe/8259.inf
> new file mode 100644
> index 00..1d9be675e3
> --- /dev/null
> +++ b/OvmfPkg/8259InterruptControllerDxe/8259.inf
> @@ -0,0 +1,52 @@
> +## @file
> +# 8259 Interrupt Controller driver that provides Legacy 8259 protocol.
> +#
> +# Copyright (c) 2005 - 2018, Intel Corporation. All rights reserved.
> +# 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.
> +#
> +##
> +
> +[Defines]
> +  INF_VERSION= 0x00010005
> +  BASE_NAME  = Legacy8259
> +  MODULE_UNI_FILE= Legacy8259.uni
> +  FILE_GUID  = 79CA4208-BBA1-4a9a-8456-E1E66A81484E

When creating customized copies, we usually like to generate new
FILE_GUIDs at once -- but in this case, I agree that the GUID should
remain unchanged, as ultimately this code copy will amount to a rename /
move.

I also verified this patch with "git show --find-copies-harder".

Reviewed-by: Laszlo Ersek 

Thanks,
Laszlo


> +  MODULE_TYPE= DXE_DRIVER
> +  VERSION_STRING = 1.0
> +  ENTRY_POINT= Install8259
> +
> +[Sources]
> +  8259.c
> +  8259.h
> +
> +[Packages]
> +  MdePkg/MdePkg.dec
> +  IntelFrameworkPkg/IntelFrameworkPkg.dec
> +  PcAtChipsetPkg/PcAtChipsetPkg.dec
> +
> +[LibraryClasses]
> +  UefiBootServicesTableLib
> +  DebugLib
> +  UefiDriverEntryPoint
> +  IoLib
> +  PcdLib
> +
> +[Protocols]
> +  gEfiLegacy8259ProtocolGuid## PRODUCES
> +  gEfiPciIoProtocolGuid ## SOMETIMES_CONSUMES
> +
> +[Pcd]
> +  gPcAtChipsetPkgTokenSpaceGuid.Pcd8259LegacyModeMask  ## CONSUMES
> +  gPcAtChipsetPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel ## CONSUMES
> +
> +[Depex]
> +  TRUE
> +
> +[UserExtensions.TianoCore."ExtraFiles"]
> +  Legacy8259Extra.uni
> diff --git a/OvmfPkg/8259InterruptControllerDxe/8259.h 
> b/OvmfPkg/8259InterruptControllerDxe/8259.h
> new file mode 100644
> index 00..0d4c1e8223
> --- /dev/null
> +++ b/OvmfPkg/8259InterruptControllerDxe/8259.h
> @@ -0,0 +1,226 @@
> +/** @file
> +  Driver implementing the Tiano Legacy 8259 Protocol
> +
> +Copyright (c) 2005 - 2009, Intel Corporation. All rights reserved.
> +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.
> +
> +**/
> +
> +#ifndef _8259_H__
> +#define _8259_H__
> +
> +#include 
> +
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +// 8259 Hardware definitions
> +
> +#define LEGACY_MODE_BASE_VECTOR_MASTER0x08
> +#define LEGACY_MODE_BASE_VECTOR_SLAVE 0x70
> +
> +#define PROTECTED_MODE_BASE_VECTOR_MASTER 0x68
> +#define PROTECTED_MODE_BASE_VECTOR_SLAVE  0x70
> +
> +#define LEGACY_8259_CONTROL_REGISTER_MASTER   0x20
> +#define LEGACY_8259_MASK_REGISTER_MASTER  0x21
> +#define LEGACY_8259_CO

Re: [edk2] [PATCH V2] Change EDK II to BSD+Patent License

[Laszlo Ersek]

Hi Mike,

On 03/23/19 03:25, Kinney, Michael D wrote:
> Hello,
>
> New in V2
> =
> * Remove Cc lines from commit messages
> * Remove branch reference from commit messages
> * Change license in 2 files missed in OvmfPkg
> * Update OvmfPkg/License.txt to BSD+Patent as the default license
> * Move the portions of Contributions.txt in the root of edk2 to
>   Readme.md in the root of edk2 that describe how to contribute
>   along with the commit message format.
> * Add to Readme.md in the root of edk2 that Signed-off-by means that
>   the contributor certifies compliance to the Developer's Certificate
>   of Origin 1.1.  https://developercertificate.org
> =
>
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1373
>
> This change is based on the following emails:
>   https://lists.01.org/pipermail/edk2-devel/2019-February/036260.html
>   https://lists.01.org/pipermail/edk2-devel/2018-October/030385.html
>
> RFCs with detailed process for the license change:
>   V3: https://lists.01.org/pipermail/edk2-devel/2019-March/038116.html
>   V2: https://lists.01.org/pipermail/edk2-devel/2019-March/037669.html
>   V1: https://lists.01.org/pipermail/edk2-devel/2019-March/037500.html
>
> I have posted the patch series for review on the following branch
> using edk2-stable201903 as the base for the patch series.
>
>   https://github.com/mdkinney/edk2/tree/Bug_1373_BsdPatentLicense_V2
>
> The commits in patch series can be viewed here:
>
>   https://github.com/mdkinney/edk2/commits/Bug_1373_BsdPatentLicense_V2
>
> The patch series has one patch per package along with a few patches
> to update the license information in the root of the edk2 repository
> as described in the RFC V3.
>
> Due to the size of the patch series, I prefer to not send the
> patch emails.  Instead, please perform code reviews using content
> from the branch.
>
> All EDK II package maintainers and package reviewers should provide
> review feedback for their packages.  The critical part of the review
> is:
> 1) Any changes that cause build breaks or logic changes.  These code
>changes are intended to only modify license contents in comment
>blocks.
> 2) Any file that has been changed to BSD+Patent, but should remain
>with the current license.
> 3) Any file that that has not changed to BSD+Patent, but should be
>changed to BSD+Patent.
>
> Feedback and Reviewed-by emails should identify the patch the feedback
> applies using the patch summary listed below.  The goal is to complete
> all reviews to support the commit of these patches on April 9, 2019.

Given that we've now entered the file addition/removal freeze:

  
E92EE9817A31E24EB0585FDF735412F5B9C772EE@ORSMSX112.amr.corp.intel.com">http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F5B9C772EE@ORSMSX112.amr.corp.intel.com

and that in that email you identify this (v2) series as "current", I'm
now reviewing v2.

Your v2 series was based on upstream commit 89910a39dcfd. The master
branch has since advanced to 7ed72121b753 however. Therefore, for this
review, I've rebased the three v2 patches listed below on top of commit
7ed72121b753 (i.e. on top the current master HEAD).


> f23540ea65 ArmVirtPkg: Replace BSD License with BSD+Patent License

I reviewed this patch most recently as part of your v1 series:

  f2a32071-868a-e4fa-dcca-41bf28ba93aa@redhat.com">http://mid.mail-archive.com/f2a32071-868a-e4fa-dcca-41bf28ba93aa@redhat.com

Content-wise, I'm in luck with the v2 review of this patch, because the
ArmVirtPkg directory tree is identical
- between your v1 patch set
- and your v2 patch set, rebased on top of current master.

Comparing the commit messages, I find:

- the RFC link list has been extended with the v3 RFC,
- the reference to your branch on github has been removed,
- the Cc: list in the commit message has been deleted.

Hence all my remarks have been observed. For this patch:

Reviewed-by: Laszlo Ersek 


> e39d07266d OvmfPkg: Replace BSD License with BSD+Patent License

(While rebasing this patch from your v2 to current master, I ran into a
conflict, but that was easy to resolve and it's going to be covered
below anyway.)

Relative to v1:

(1) RFC link list updated, OK

(2) "Branch for review" removed, OK (v1/1.2)

(3) Cc: list removed, OK (v1/1.1)

(4) The "create-release.py" hunk doesn't apply any longer, so please
remove it in v3. This conflict is due to us removing
"create-release.py" altogether, for
<https://bugzilla.tianocore.org/show_bug.cgi?id=1653>. (v1/2.1.1)

(5) At commit 7ed72121b753 (= current master HEAD), OvmfPkg contains the
following new files:

  OvmfPkg/SioBusDxe/ComponentName.c
  OvmfPkg/SioBusDxe/SioBusDxe.c
  OvmfPkg/SioBusDxe/SioBusDxe.h
  OvmfPkg/SioBusDxe

Re: [edk2] [RFC] Plan to delete ShellBinPkg from edk2/master

[Laszlo Ersek]

On 04/03/19 04:17, Ni, Ray wrote:
> 
> 
>> -Original Message-
>> From: edk2-devel  On Behalf Of Laszlo
>> Ersek
>> Sent: Tuesday, April 2, 2019 4:49 PM
>> To: Bi, Dandan ; edk2-devel@lists.01.org
>> Cc: Cetola, Stephano ; Kinney, Michael D
>> ; Gao, Liming ; Carsey,
>> Jaben 
>> Subject: Re: [edk2] [RFC] Plan to delete ShellBinPkg from edk2/master
>>
>> On 04/02/19 07:38, Bi, Dandan wrote:
>>> Hi All,
>>>
>>> ShellBinPkg is the remaining binary package in Edk2 repo.  We plan to
>> delete ShellBinPkg from edk2/master, and keep source ShellPkg only in edk2
>> repo.
>>> Before the deletion, I will update the existing consumers in Edk2 and
>> Edk2Platforms to use ShellPkg directly.
>>>
>>> If you have any concern please raise here before mid-April . If there is no
>> concern, I will create patches for this task after mid-April.
>>>
>>> Bugzilla for this task:
>>> https://bugzilla.tianocore.org/show_bug.cgi?id=1675
>>
>> (adding a few CC's)
>>
>> I think we should not remove ShellBinPkg without a replacement
>> *somehwere*.
>>
>> A shell binary that is built from a validated edk2 tree, with a set of 
>> library
>> resolutions and PCD settings that are known to keep platform dependencies
>> *out* of the shell binary, is extremely useful.
> 
> I understand the concern.
> Maybe a "Shell.dsc.inc" provided by ShellPkg which lists all library 
> resolutions
> , PCD settings and build options can be included by platform DSC to resolve 
> such
> dependency issue.
> 
>>
>> IIRC, Andrew suggested earlier that we should treat the shell even as an 
>> "OS",
>> with better compatibility standards than we currently maintain.
>>
>> I think we should only remove ShellBinPkg if we permanently offer a
>> separate download location instead, and we rebuild the shell binary from
>> "ShellPkg/ShellPkg.dsc" at every stable tag.
> 
> I do not quite understand. All other modules in edk2 repo are source-included 
> by
> OvmfPkg and daily commits directly generates new binaries for OvmfPkg.
> I do not think we should have a different "binary-generation" model for
> shell.

The standalone shell binary would not be offered for OVMF, but for all
possible UEFI platforms (physical and virtual alike).

People frequently turn to the UEFI shell for debugging UEFI issues on
their physical machines. Such users are generally not interested in
building the shell from source, just booting it as easily as possible.

Thanks,
Laszlo


>> In that case, removing ShellBinPkg would indeed improve the edk2 tree, in
>> my opinion.
>>
>> Thanks,
>> Laszlo
>> ___
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel

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

Re: [edk2] [RFC] Plan to delete ShellBinPkg from edk2/master

[Laszlo Ersek]

On 04/02/19 13:50, Ryszard Knop wrote:
> On Tue, 2019-04-02 at 13:45 +0200, Laszlo Ersek wrote:
>> On 04/02/19 13:29, Ryszard Knop wrote:
>>> On Tue, 2019-04-02 at 10:12 +0100, Leif Lindholm wrote:
>>>> Hi Laszlo,
>>>>
>>>> On Tue, Apr 02, 2019 at 10:49:16AM +0200, Laszlo Ersek wrote:
>>>>> On 04/02/19 07:38, Bi, Dandan wrote:
>>>>>> Hi All,
>>>>>>
>>>>>> ShellBinPkg is the remaining binary package in Edk2 repo.  We
>>>>>> plan
>>>>>> to delete ShellBinPkg from edk2/master, and keep source
>>>>>> ShellPkg
>>>>>> only in edk2 repo.
>>>>>> Before the deletion, I will update the existing consumers in
>>>>>> Edk2
>>>>>> and Edk2Platforms to use ShellPkg directly.
>>>>>>
>>>>>> If you have any concern please raise here before mid-April .
>>>>>> If
>>>>>> there is no concern, I will create patches for this task
>>>>>> after
>>>>>> mid-April.
>>>>>>
>>>>>> Bugzilla for this task:
>>>>>> https://bugzilla.tianocore.org/show_bug.cgi?id=1675
>>>>>
>>>>> (adding a few CC's)
>>>>>
>>>>> I think we should not remove ShellBinPkg without a replacement
>>>>> *somehwere*.
>>>>>
>>>>> A shell binary that is built from a validated edk2 tree, with a
>>>>> set
>>>>> of
>>>>> library resolutions and PCD settings that are known to keep
>>>>> platform
>>>>> dependencies *out* of the shell binary, is extremely useful.
>>>>
>>>> Agreed. However, I am not sure that accurately describes what we
>>>> have
>>>> today.
>>>>
>>>>> IIRC, Andrew suggested earlier that we should treat the shell
>>>>> even
>>>>> as an
>>>>> "OS", with better compatibility standards than we currently
>>>>> maintain.
>>>>>
>>>>> I think we should only remove ShellBinPkg if we permanently
>>>>> offer a
>>>>> separate download location instead, and we rebuild the shell
>>>>> binary
>>>>> from
>>>>> "ShellPkg/ShellPkg.dsc" at every stable tag.
>>>>
>>>> I think this sounds like an exellent improvement. When I saw the
>>>> patch, I did immediately think maybe I should start including
>>>> them in
>>>> my Linaro releases. But if we could automate a build of binaries
>>>> for
>>>> all supported architectures, and have a place to publish them,
>>>> that
>>>> would be much better.
>>>
>>> One place to put them might be next to the stable releases on
>>> GitHub.
>>> Sources are automatically packaged there, binaries can also be
>>> uploaded, also automatically via CI. (Maybe it could also be used
>>> to
>>> keep stable OVMF images? Would be nice for quick testing for people
>>> not
>>> involved in UEFI development and not having these binaries
>>> available in
>>> their OS repos, or having issues with 3rd party builds.)
>>
>> OVMF and ArmVirtQemu binaries are being bundled with upstream QEMU.
>> The
>> series should be merged into QEMU 4.1.
> 
> Right, but for people stuck on older QEMU versions it'd be useful to
> find everything conveniently in one place when googling "OVMF". And
> there are quite a few of these versions in the wild: 
> https://repology.org/project/qemu/versions

This doesn't seem to be a problem with the UEFI shell, but 'everything
conveniently in one place when googling "OVMF"' seems like a ship that
has sailed. To exaggerate a bit, when you google "Linux" or "QEMU", you
don't find everything in one place either. :)

For bleeding edge builds, people can (and do) already consume
<https://www.kraxel.org/repos/>. The point of bundling binaries, built
from the latest edk2-stableMM tag, with QEMU, is two-fold: (a)
following the tradition of bundling SeaBIOS, iPXE, and other
firmware(-level) binaries with QEMU, (b) allowing QEMU's own "make
check" to run UEFI helper apps in guests, without external dependencies
(both the platform firmware binaries and the UEFI app(s) are to be
tracked in the QEMU git tree).

NB purpose (a) is not universally accepted for QEMU either; there have
been ideas to move all of those firmwa

Re: [edk2] [RFC] Plan to delete ShellBinPkg from edk2/master

[Laszlo Ersek]

On 04/02/19 13:29, Ryszard Knop wrote:
> On Tue, 2019-04-02 at 10:12 +0100, Leif Lindholm wrote:
>> Hi Laszlo,
>>
>> On Tue, Apr 02, 2019 at 10:49:16AM +0200, Laszlo Ersek wrote:
>>> On 04/02/19 07:38, Bi, Dandan wrote:
>>>> Hi All,
>>>>
>>>> ShellBinPkg is the remaining binary package in Edk2 repo.  We
>>>> plan
>>>> to delete ShellBinPkg from edk2/master, and keep source ShellPkg
>>>> only in edk2 repo.
>>>> Before the deletion, I will update the existing consumers in Edk2
>>>> and Edk2Platforms to use ShellPkg directly.
>>>>
>>>> If you have any concern please raise here before mid-April . If
>>>> there is no concern, I will create patches for this task after
>>>> mid-April.
>>>>
>>>> Bugzilla for this task:
>>>> https://bugzilla.tianocore.org/show_bug.cgi?id=1675
>>>
>>> (adding a few CC's)
>>>
>>> I think we should not remove ShellBinPkg without a replacement
>>> *somehwere*.
>>>
>>> A shell binary that is built from a validated edk2 tree, with a set
>>> of
>>> library resolutions and PCD settings that are known to keep
>>> platform
>>> dependencies *out* of the shell binary, is extremely useful.
>>
>> Agreed. However, I am not sure that accurately describes what we have
>> today.
>>
>>> IIRC, Andrew suggested earlier that we should treat the shell even
>>> as an
>>> "OS", with better compatibility standards than we currently
>>> maintain.
>>>
>>> I think we should only remove ShellBinPkg if we permanently offer a
>>> separate download location instead, and we rebuild the shell binary
>>> from
>>> "ShellPkg/ShellPkg.dsc" at every stable tag.
>>
>> I think this sounds like an exellent improvement. When I saw the
>> patch, I did immediately think maybe I should start including them in
>> my Linaro releases. But if we could automate a build of binaries for
>> all supported architectures, and have a place to publish them, that
>> would be much better.
> 
> One place to put them might be next to the stable releases on GitHub.
> Sources are automatically packaged there, binaries can also be
> uploaded, also automatically via CI. (Maybe it could also be used to
> keep stable OVMF images? Would be nice for quick testing for people not
> involved in UEFI development and not having these binaries available in
> their OS repos, or having issues with 3rd party builds.)

OVMF and ArmVirtQemu binaries are being bundled with upstream QEMU. The
series should be merged into QEMU 4.1.

The plan is to refresh the firmware binaries for each edk2 stable tag.

(It's also possible that users could benefit from synching QEMU and edk2
releases to an extent, similarly to how SeaBIOS and QEMU tend to be in
sync. (IIRC SeaBIOS tends to cut a new release shortly before QEMU, so
that QEMU can pick up the most recent release while it's fresh.) Anyway
this sub-topic is for the future.)

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

Re: [edk2] [RFC] Plan to delete ShellBinPkg from edk2/master

[Laszlo Ersek]

On 04/02/19 07:38, Bi, Dandan wrote:
> Hi All,
> 
> ShellBinPkg is the remaining binary package in Edk2 repo.  We plan to delete 
> ShellBinPkg from edk2/master, and keep source ShellPkg only in edk2 repo.
> Before the deletion, I will update the existing consumers in Edk2 and 
> Edk2Platforms to use ShellPkg directly.
> 
> If you have any concern please raise here before mid-April . If there is no 
> concern, I will create patches for this task after mid-April.
> 
> Bugzilla for this task:
> https://bugzilla.tianocore.org/show_bug.cgi?id=1675

(adding a few CC's)

I think we should not remove ShellBinPkg without a replacement *somehwere*.

A shell binary that is built from a validated edk2 tree, with a set of
library resolutions and PCD settings that are known to keep platform
dependencies *out* of the shell binary, is extremely useful.

IIRC, Andrew suggested earlier that we should treat the shell even as an
"OS", with better compatibility standards than we currently maintain.

I think we should only remove ShellBinPkg if we permanently offer a
separate download location instead, and we rebuild the shell binary from
"ShellPkg/ShellPkg.dsc" at every stable tag.

In that case, removing ShellBinPkg would indeed improve the edk2 tree,
in my opinion.

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

Re: [edk2] [PATCH 0/2] Add event signal before and after ReadyToBoot

[Laszlo Ersek]

On 04/02/19 07:49, Zhichao Gao wrote:
> Add two event guids.
> And signal them immediately before and after the ReadyToBoot signal Event.
> 
> Bret Barkelew (2):
>   MdeModulePkg: Add event guids
>   MdeModulePkg/UefiBootManagerlib: Add two event signals
> 
>  .../Include/Guid/EventPostReadyToBoot.h   | 24 +++
>  .../Include/Guid/EventPreReadyToBoot.h| 24 +++
>  .../Library/UefiBootManagerLib/BmBoot.c   |  2 ++
>  .../Library/UefiBootManagerLib/InternalBm.h   |  4 +++-
>  .../UefiBootManagerLib/UefiBootManagerLib.inf |  5 +++-
>  MdeModulePkg/MdeModulePkg.dec |  6 +
>  6 files changed, 63 insertions(+), 2 deletions(-)
>  create mode 100644 MdeModulePkg/Include/Guid/EventPostReadyToBoot.h
>  create mode 100644 MdeModulePkg/Include/Guid/EventPreReadyToBoot.h
> 

(1) You forgot to include the CC's from the individual patches on the
cover letter. I'm fixing that now.


(2) This is my turn to ask whether the new event group GUIDs have been
standardized and released in a public spec.

If they haven't, I'll nack this series -- contributors should be held to
equal standards.

In particular, the variables are called "gEfiEventPostReadyToBootGuid"
and "gEfiEventPreReadyToBootGuid". The "Efi" infix suggests these are
standard event groups. However, in that case, I believe the changes
should go into "MdePkg/Include/Guid/EventGroup.h", and TianoCore#1676
should minimally indicate the Mantis ticket that introduces the GUIDs.

I've now searched "UEFI_Spec_2_8_final.pdf" (from the USWG member area,
SHA1 1adf5b81c566075574b3ad9e4091a42e9c9a80cb), and PI v1.7 too, for
"7b94c75c", and there are no hits.

In theory, it would be totally fine to introduce these event group GUIDs
as edk2 extensions. In theory. The last time I tried to do something
similar, I was forced to go through the spec process however.

No double standards, please. If UefiBootManagerLib & BdsDxe are now open
to edk2 extensions, and will no longer restrict themselves to specified
behavior, that's great, but I will want it in writing; the policy should
apply to everyone. (Adding Stephano.)

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

Re: [edk2] [PATCH 1/2] ArmVirtPkg: add runtime instance of FdtPL011SerialPortLib

[Laszlo Ersek]

On 04/02/19 03:45, Heyi Guo wrote:
> Hi Laszlo,
> 
> Thanks for your time of reviewing and sorry for code style issues. I
> accept most of comments, with some questions for below ones:
> 
> (7) coding style -- please use empty // lines before and after the
> comment line that you have right now.
> 
> I remember Ard said this rule conflicted some other rule; not sure if it
> is decided to use empty // lines around comments.

Interesting -- I remember seeing other "naked" // comments under
Arm*Pkg, but I'm unaware of any rule conflicts regarding comment lines.
Ard, can you clarify please?

> 
>> +
>> +  gInternalRT = SystemTable->RuntimeServices;
>> +
>> +  Status = InternalGetSystemConfigurationTable (
>> +  SystemTable,
>> +  ,
>> +  (VOID **) 
>> +  );
> 
> (13) coding style -- indentation is broken
> 
> It is true that I'm not clear about the indentation rule for
> multiple-line function call; shall I use 2 spaces indentation following
> the function name, just like below?
> 
> +  Status = InternalGetSystemConfigurationTable (
> + SystemTable,
> + ,
> + (VOID **) 
> + );

In ArmVirtPkg we accept two indentation styles for multi-line function
calls. One is the official edk2 style, which you show above -- two
spaces relative to the last word in the function designator, each
argument on a new line (including the first argument), closing paren on
a new line, closing paren indented similarly to the function call arguments.

  Status = PciIo->Pci.Read (
PciIo,
EfiPciIoWidthUint32,
0,// Offset
sizeof Pci / sizeof (UINT32),

);

The other style could be called "condensed" -- it uses the same
indentation, the only difference is that you need to insert a newline
character only when you must, in order not to exceed 80 characters per line:

  Status = PciIo->Pci.Read (PciIo, EfiPciIoWidthUint32, 0 /* Offset */,
sizeof Pci / sizeof (UINT32), );

Obviously it's preferred not to break individual arguments in the
middle, in this style.

> Shall we follow the coding style in this document:
> https://github.com/tianocore-docs/Docs/raw/master/Specifications/CCS_2_1_Draft.pdf?

The latest version seems to be 2.2:

https://edk2-docs.gitbooks.io/edk-ii-c-coding-standards-specification/content/

which includes the fix for
<https://bugzilla.tianocore.org/show_bug.cgi?id=425>; but yes, that's
the one.

(Funnily enough, TianoCore#425 was exactly about cleaning up the
multi-line function call rules in the official edk2 style. But, again,
in ArmVirtPkg and OvmfPkg, we accept the condensed style in addition to
the official edk2 style. You are free to pick whichever you like, and
you can even mix them in a single file -- for example, use the condensed
style as a basis, but switch to the more verbose official style if you
have several comments on the arguments of a large function call.)

Thanks,
Laszlo

> 
> On 2019/4/2 0:14, Laszlo Ersek wrote:
>> On 04/01/19 11:06, Heyi Guo wrote:
>>> Add a runtime instance of FdtPL011SerialPortLib to support runtime
>>> serial port debug for UEFI runtime services.
>>>
>>> The framework is based on below discussion:
>>> https://lists.01.org/pipermail/edk2-devel/2019-March/037986.html
>>>
>>> We have decided to use an individual firmware UART for UEFI runtime
>>> debug, however this depends on QEMU to provide this virtual device, so
>>> we still use the OS visible system UART at the moment, with the
>>> potential *risk* of conflicting OS serial port read/write.
>> (1) I'll defer to Ard on whether this is a good idea after all, even
>> just for debugging. I realize the feature is disabled by default, so
>> personally I wouldn't mind, I think.
>>
>>> Once QEMU implements individual firmware UART, we need rewrite
>>> PlatformGetRtSerialBase() to get the real runtime serial port base
>>> address.
>> (2) Assuming Ard is OK with this, please file a feature request in the
>> upstream QEMU bug tracker <https://bugs.launchpad.net/qemu/+bugs>, about
>> the new UART.
>>
>> In turn, this launchpad bug URL should be mentioned (a) in the FIXME
>> comment in patch #1 (below), (b) more importantly, near the default
>> RT_DEBUG setting (of FALSE) in the DSC file, in patch #2.
>>
>> People looking at the build flags should realize that RT_DEBUG=TRUE is
>> basically broken, and find a pointer to the missing QEMU feature.
>>
>>> Cc: Laszlo Ersek 
>>> Cc: Ard Biesheuvel 

Re: [edk2] [Patch] AdvancedFeaturePkg/AcpiDebug: Add new AcpiDebug modules.

[Laszlo Ersek]

On 04/01/19 05:16, Eric Dong wrote:
> Add new AcpiDebug modules which provide ACPI Debug feature.
> Detail about this feature see the readme.txt in the patch.
> 
> Change-Id: Ib977ece46f3494301574b04af32282b99045f673
> Cc: Hao Wu 
> Cc: Michael Kubacki 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Eric Dong 
> ---
>  .../AcpiDebug/AcpiDebug.asl   | 109 
>  .../AdvancedFeaturePkg/AcpiDebug/AcpiDebug.c  | 485 ++
>  .../AcpiDebug/AcpiDebugDxe.inf|  63 +++
>  .../AcpiDebug/AcpiDebugSmm.inf|  65 +++
>  .../AdvancedFeaturePkg/AcpiDebug/Readme.txt   |  47 ++
>  .../AdvancedFeaturePkg/AdvancedFeaturePkg.dec |   6 +
>  .../AdvancedFeaturePkg/AdvancedFeaturePkg.dsc |   2 +
>  7 files changed, 777 insertions(+)
>  create mode 100644 Platform/Intel/AdvancedFeaturePkg/AcpiDebug/AcpiDebug.asl
>  create mode 100644 Platform/Intel/AdvancedFeaturePkg/AcpiDebug/AcpiDebug.c
>  create mode 100644 
> Platform/Intel/AdvancedFeaturePkg/AcpiDebug/AcpiDebugDxe.inf
>  create mode 100644 
> Platform/Intel/AdvancedFeaturePkg/AcpiDebug/AcpiDebugSmm.inf
>  create mode 100644 Platform/Intel/AdvancedFeaturePkg/AcpiDebug/Readme.txt

What repository is this for? Is it for edk2-platforms? Such patches
should be posted with a subject prefix like [edk2-platforms PATCH], please.

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

Re: [edk2] [PATCH v9] UefiCpuPkg\CpuSmm: Save & restore CR2 on-demand paging in SMM

[Laszlo Ersek]

On 04/01/19 10:16, nkvangup wrote:
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1593
> 
> For every SMI occurrence, save and restore CR2 register only when SMM
> on-demand paging support is enabled in 64 bit operation mode.
> This is not a bug but to have better improvement of code.
> 
> Patch5 is updated with separate functions for Save and Restore of CR2
> based on review feedback.
> 
> Patch6 - Removed Global Cr2 instead used function parameter.
> 
> Patch7 - Removed checking Cr2 with 0 as per feedback.
> 
> Patch8 and 9 - Aligned with EDK2 Coding style.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Vanguput Narendra K 
> Cc: Eric Dong 
> Cc: Ray Ni 
> Cc: Laszlo Ersek 
> Cc: Yao Jiewen 
> ---
>  UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c   | 26 ++
>  UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c  |  9 ++---
>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h | 22 ++
>  UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c| 30 
> ++
>  4 files changed, 84 insertions(+), 3 deletions(-)
> 
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
> index b734a1ea8c..d1e146a70c 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
> @@ -316,3 +316,29 @@ SetPageTableAttributes (
>  
>return ;
>  }
> +
> +/**
> +  This function returns with no action for 32 bit.
> +
> +  @param[out]  *Cr2  Pointer to variable to hold CR2 register value.
> +**/
> +VOID
> +SaveCr2 (
> +  OUT UINTN  *Cr2
> +  )
> +{
> +  return ;
> +}
> +
> +/**
> +  This function returns with no action for 32 bit.
> +
> +  @param[in]  Cr2  Value to write into CR2 register.
> +**/
> +VOID
> +RestoreCr2 (
> +  IN UINTN  Cr2
> +  )
> +{
> +  return ;
> +}
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> index 3b0b3b52ac..ce70f77709 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> @@ -1112,9 +1112,11 @@ SmiRendezvous (
>ASSERT(CpuIndex < mMaxNumberOfCpus);
>  
>//
> -  // Save Cr2 because Page Fault exception in SMM may override its value
> +  // Save Cr2 because Page Fault exception in SMM may override its value,
> +  // when using on-demand paging for above 4G memory.
>//
> -  Cr2 = AsmReadCr2 ();
> +  Cr2 = 0;
> +  SaveCr2 ();
>  
>//
>// Perform CPU specific entry hooks
> @@ -1253,10 +1255,11 @@ SmiRendezvous (
>  
>  Exit:
>SmmCpuFeaturesRendezvousExit (CpuIndex);
> +
>//
>// Restore Cr2
>//
> -  AsmWriteCr2 (Cr2);
> +  RestoreCr2 (Cr2);
>  }
>  
>  /**
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h
> index 84efb22981..38f9104117 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h
> @@ -1243,4 +1243,26 @@ EFIAPI
>  PiSmmCpuSmiEntryFixupAddress (
>   );
>  
> +/**
> +  This function reads CR2 register when on-demand paging is enabled
> +  for 64 bit and no action for 32 bit.
> +
> +  @param[out]  *Cr2  Pointer to variable to hold CR2 register value.
> +**/
> +VOID
> +SaveCr2 (
> +  OUT UINTN  *Cr2
> +  );
> +
> +/**
> +  This function writes into CR2 register when on-demand paging is enabled
> +  for 64 bit and no action for 32 bit.
> +
> +  @param[in]  Cr2  Value to write into CR2 register.
> +**/
> +VOID
> +RestoreCr2 (
> +  IN UINTN  Cr2
> +  );
> +
>  #endif
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
> index 2c77cb47a4..95eaf0b016 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
> @@ -1053,3 +1053,33 @@ SetPageTableAttributes (
>  
>return ;
>  }
> +
> +/**
> +  This function reads CR2 register when on-demand paging is enabled.
> +
> +  @param[out]  *Cr2  Pointer to variable to hold CR2 register value.
> +**/
> +VOID
> +SaveCr2 (
> +  OUT UINTN  *Cr2
> +  )
> +{
> +  if (!mCpuSmmStaticPageTable) {
> +*Cr2 = AsmReadCr2 ();
> +  }
> +}
> +
> +/**
> +  This function restores CR2 register when on-demand paging is enabled.
> +
> +  @param[in]  Cr2  Value to write into CR2 register.
> +**/
> +VOID
> +RestoreCr2 (
> +  IN UINTN  Cr2
> +  )
> +{
> +  if (!mCpuSmmStaticPageTable) {
> +AsmWriteCr2 (Cr2);
> +  }
> +}
> 

I agree *how* this patch is implemented is correct, wrt. the IA32 / X64
s

Re: [edk2] [PATCH 2/2] ArmVirtQemu: enable runtime debug by build flag

[Laszlo Ersek]

On 04/01/19 11:06, Heyi Guo wrote:
> Introduce a build flag "RT_DEBUG" to enable runtime debug, so that we
> can have a handy method for UEFI runtime services debug.
> 
> This build flag only applies to DEBUG build; the reason for not
> enabling it for DEBUG build by default is that we are still using
> the same UART of OS and it may cause potential conflict.
> 
> User needs to specify "-D RT_DEBUG=TRUE"; "-D RT_DEBUG" is not enough
> for we use !if $(RT_DEBUG)==TRUE in the code.

(1) This looks like a bug / regression in basetools, or somewhere else.
We use a bunch of other similar flags, and "-D FLAG" works just fine.

See "HTTP_BOOT_ENABLE" for example -- set to FALSE by default in the
individual DSC files, and depended upon in the dsc.inc file as well.

> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: Julien Grall 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Heyi Guo 
> Signed-off-by: Heyi Guo 
> ---
>  ArmVirtPkg/ArmVirt.dsc.inc | 4 
>  ArmVirtPkg/ArmVirtQemu.dsc | 1 +
>  2 files changed, 5 insertions(+)

(2) I think whenever you modify ArmVirtQemu.dsc, you almost always have
to reflect it to ArmVirtQemuKernel.dsc as well.

> diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc
> index d172a08..5ace31b 100644
> --- a/ArmVirtPkg/ArmVirt.dsc.inc
> +++ b/ArmVirtPkg/ArmVirt.dsc.inc
> @@ -240,8 +240,12 @@
>
> MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
>CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf
>  !if $(TARGET) != RELEASE
> +!if $(RT_DEBUG) == TRUE
> +  
> SerialPortLib|ArmVirtPkg/Library/FdtPL011SerialPortLib/FdtPL011SerialPortLibRuntime.inf
> +!else
>
> DebugLib|MdePkg/Library/DxeRuntimeDebugLibSerialPort/DxeRuntimeDebugLibSerialPort.inf
>  !endif
> +!endif

(3) Unless you intend to bring this feature to Xen at some point, adding
the lib resolution to "ArmVirt.dsc.inc" seems wrong. IIRC, in such cases
we usually move (triplicate) the default lib resolution to the
individual DSC files, and then update only the QEMU ones separately (and
leave the Xen one alone).

>  !if $(SECURE_BOOT_ENABLE) == TRUE
>BaseCryptLib|CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf
> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
> index d703317..b279d7d 100644
> --- a/ArmVirtPkg/ArmVirtQemu.dsc
> +++ b/ArmVirtPkg/ArmVirtQemu.dsc
> @@ -37,6 +37,7 @@
>DEFINE SECURE_BOOT_ENABLE  = FALSE
>DEFINE NETWORK_IP6_ENABLE  = FALSE
>DEFINE HTTP_BOOT_ENABLE= FALSE
> +  DEFINE RT_DEBUG= FALSE
>  
>  !include ArmVirtPkg/ArmVirt.dsc.inc
>  
> 

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

Re: [edk2] [PATCH 1/2] ArmVirtPkg: add runtime instance of FdtPL011SerialPortLib

[Laszlo Ersek]

On 04/01/19 11:06, Heyi Guo wrote:
> Add a runtime instance of FdtPL011SerialPortLib to support runtime
> serial port debug for UEFI runtime services.
> 
> The framework is based on below discussion:
> https://lists.01.org/pipermail/edk2-devel/2019-March/037986.html
> 
> We have decided to use an individual firmware UART for UEFI runtime
> debug, however this depends on QEMU to provide this virtual device, so
> we still use the OS visible system UART at the moment, with the
> potential *risk* of conflicting OS serial port read/write.

(1) I'll defer to Ard on whether this is a good idea after all, even
just for debugging. I realize the feature is disabled by default, so
personally I wouldn't mind, I think.

> Once QEMU implements individual firmware UART, we need rewrite
> PlatformGetRtSerialBase() to get the real runtime serial port base
> address.

(2) Assuming Ard is OK with this, please file a feature request in the
upstream QEMU bug tracker <https://bugs.launchpad.net/qemu/+bugs>, about
the new UART.

In turn, this launchpad bug URL should be mentioned (a) in the FIXME
comment in patch #1 (below), (b) more importantly, near the default
RT_DEBUG setting (of FALSE) in the DSC file, in patch #2.

People looking at the build flags should realize that RT_DEBUG=TRUE is
basically broken, and find a pointer to the missing QEMU feature.

> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: Julien Grall 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Heyi Guo 
> Signed-off-by: Heyi Guo 

(3) This pair of signoffs looks strange, but maybe it is justified. Was
it your intent? (Applies to patch #2 as well.)

> ---
>  ArmVirtPkg/Library/FdtPL011SerialPortLib/FdtPL011SerialPortLib.c  |  
>  6 +-
>  ArmVirtPkg/Library/FdtPL011SerialPortLib/FdtPL011SerialPortLib.h  |  
> 32 
>  ArmVirtPkg/Library/FdtPL011SerialPortLib/FdtPL011SerialPortLibRuntime.c   | 
> 187 
>  ArmVirtPkg/Library/FdtPL011SerialPortLib/FdtPL011SerialPortLibRuntime.inf |  
> 59 ++
>  4 files changed, 282 insertions(+), 2 deletions(-)
> 
> diff --git a/ArmVirtPkg/Library/FdtPL011SerialPortLib/FdtPL011SerialPortLib.c 
> b/ArmVirtPkg/Library/FdtPL011SerialPortLib/FdtPL011SerialPortLib.c
> index 2f10fb7..017ca30 100644
> --- a/ArmVirtPkg/Library/FdtPL011SerialPortLib/FdtPL011SerialPortLib.c
> +++ b/ArmVirtPkg/Library/FdtPL011SerialPortLib/FdtPL011SerialPortLib.c
> @@ -3,9 +3,10 @@
>  
>Copyright (c) 2008 - 2010, Apple Inc. All rights reserved.
>Copyright (c) 2012 - 2013, ARM Ltd. All rights reserved.
> -  Copyright (c) 2014, Linaro Ltd. All rights reserved.
> +  Copyright (c) 2014 - 2019, Linaro Ltd. All rights reserved.
>Copyright (c) 2014, Red Hat, Inc.
>Copyright (c) 2015, Intel Corporation. All rights reserved.
> +  Copyright (c) 2019, Huawei Technologies Co., Ltd. All rights reserved.
>  
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the BSD 
> License
> @@ -28,8 +29,9 @@
>  #include 
>  #include 
>  #include 
> +#include "FdtPL011SerialPortLib.h"
>  
> -STATIC UINTN mSerialBaseAddress;
> +UINTN mSerialBaseAddress;
>  
>  RETURN_STATUS
>  EFIAPI
> diff --git a/ArmVirtPkg/Library/FdtPL011SerialPortLib/FdtPL011SerialPortLib.h 
> b/ArmVirtPkg/Library/FdtPL011SerialPortLib/FdtPL011SerialPortLib.h
> new file mode 100644
> index 000..32c0b9b
> --- /dev/null
> +++ b/ArmVirtPkg/Library/FdtPL011SerialPortLib/FdtPL011SerialPortLib.h
> @@ -0,0 +1,32 @@
> +/** @file
> +  Serial I/O Port library internal header
> +
> +  Copyright (c) 2008 - 2010, Apple Inc. All rights reserved.
> +  Copyright (c) 2012 - 2013, ARM Ltd. All rights reserved.
> +  Copyright (c) 2014 - 2019, Linaro Ltd. All rights reserved.
> +  Copyright (c) 2014, Red Hat, Inc.
> +  Copyright (c) 2015, Intel Corporation. All rights reserved.
> +  Copyright (c) 2019, Huawei Technologies Co., Ltd. All rights reserved.
> +
> +  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.
> +
> +**/

(4) From April 2nd through April 9th, the edk2 tree will be locked from
file additions / removals, due to a patch review period for
<https://bugzilla.tianocore.org/show_bug.cgi?id=1373>.

I think you will have to repost after that period, and then the license
blocks in all the new fil

Re: [edk2] [PATCH] UefiPayloadPkg: Enhance UEFI payload for coreboot and Slim Bootloader

[Laszlo Ersek]

(+David)

On 03/29/19 06:15, Ni, Ray wrote:
> 
> Guo,
> Just to double confirm: UefiPayloadPkg will not require Legacy8254 timer 
> support.
> The old packages Coreboot*Pkgs will be removed.
> Which means now only QEMU/OVMF needs the Legacy8254 support.
> 
> Laszlo,
> Now since QEMU/OVMF is the only consumer of the Legacy8254 driver, do you
> agree that the Legacy8254 is moved to OvmfPkg?
> Note: We agreed that Legacy8259 will be moved to OvmfPkg/Csm directory and
> that decision is not going to be changed by this new situation.

The last status (up to & including comment 12) in
 was that:

(1) 8254TimerDxe would remain a generic driver, with the minimal
interrupt controller programming that it needs flattened into it (no
dependency on gEfiLegacy8259ProtocolGuid)

(2) the 8259InterruptControllerDxe driver (producing
gEfiLegacy8259ProtocolGuid) would move under OvmfPkg/Csm.

Now, if 8254TimerDxe becomes specific to OvmfPkg, then I think it's not
necessary to modify it -- it can continue depending on
gEfiLegacy8259ProtocolGuid. Simply move both drivers from PcAtChipsetPkg
to OvmfPkg. (Note: *not* to OvmfPkg/Csm).

Hao: can you please update
 accordingly? (If
you agree, that is.)

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

Re: [edk2] [PATCH 1/4] OvmfPkg/PlatformBootManagerLib: Remove dependency on Mps.h

[Laszlo Ersek]

On 03/29/19 02:41, Shenglei Zhang wrote:
> Mps.h is included in BdsPlatform.h but not actually used.
> So remove it.
> 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Shenglei Zhang 
> ---
>  OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h 
> b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h
> index 4948ca6518..d6dfe1e697 100644
> --- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h
> +++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h
> @@ -63,7 +63,6 @@ Abstract:
>  
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> 

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

Re: [edk2] [PATCH v2 0/3] Ovmf: Stop using ISA drivers within IntelFrameworkModulePkg

[Laszlo Ersek]

On 03/27/19 01:20, Wu, Hao A wrote:
>> -Original Message-
>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>> Sent: Tuesday, March 26, 2019 11:15 PM
>> To: Wu, Hao A
>> Cc: Anthony PERARD; Justen, Jordan L; edk2-devel@lists.01.org; Julien Grall
>> Subject: Re: [edk2] [PATCH v2 0/3] Ovmf: Stop using ISA drivers within
>> IntelFrameworkModulePkg
>>
>> Hi Hao,
>>
>> On 03/26/19 16:01, Laszlo Ersek wrote:
>>> On 03/26/19 14:03, Anthony PERARD wrote:
>>>> On Mon, Mar 25, 2019 at 12:29:25PM +0100, Laszlo Ersek wrote:
>>>>> (4) Julien, Anthony: can you please fetch this series (github URL at the
>>>>> top) and see if the PS/2 keyboard, and the serial port, still work on
>>>>> Xen, to interact e.g. with the UEFI shell?
>>>>
>>>> Yes, I can still interact with the UEFI shell with this series applied,
>>>> both via the console and via VNC (which uses respectively the serial
>>>> port and PS/2 I think).
>>>
>>> Thank you -- can you please follow up with a Tested-by, or do you prefer
>>> if I push the set without it?
>>
>> ... actually, I just realize that you can push this series just fine,
>> after Anthony's answer -- so please excuse my confusing comment; I'll of
>> course let you push the series.
> 
> Hello Laszlo,
> 
> Sure, I will push the series.
> 
> But one thing to confirm, for patch 2/3, it only got a couple of 'Ack'
> tags and a 'Tested-by' tag. I am not sure if this meets the criteria for
> pushing.

Yes, if you get an Acked-by from at least one "M" person for the package
(and no open questions remain), that's sufficient. For edk2, my
interpretation of "Acked-by" is: "although I haven't reviewed in detail,
I agree/approve".

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

Re: [edk2] [PATCH v2 0/3] Ovmf: Stop using ISA drivers within IntelFrameworkModulePkg

[Laszlo Ersek]

Hi Hao,

On 03/26/19 16:01, Laszlo Ersek wrote:
> On 03/26/19 14:03, Anthony PERARD wrote:
>> On Mon, Mar 25, 2019 at 12:29:25PM +0100, Laszlo Ersek wrote:
>>> (4) Julien, Anthony: can you please fetch this series (github URL at the
>>> top) and see if the PS/2 keyboard, and the serial port, still work on
>>> Xen, to interact e.g. with the UEFI shell?
>>
>> Yes, I can still interact with the UEFI shell with this series applied,
>> both via the console and via VNC (which uses respectively the serial
>> port and PS/2 I think).
> 
> Thank you -- can you please follow up with a Tested-by, or do you prefer
> if I push the set without it?

... actually, I just realize that you can push this series just fine,
after Anthony's answer -- so please excuse my confusing comment; I'll of
course let you push the series.

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

Re: [edk2] [PATCH v2 0/3] Ovmf: Stop using ISA drivers within IntelFrameworkModulePkg

[Laszlo Ersek]

On 03/26/19 14:03, Anthony PERARD wrote:
> On Mon, Mar 25, 2019 at 12:29:25PM +0100, Laszlo Ersek wrote:
>> (4) Julien, Anthony: can you please fetch this series (github URL at the
>> top) and see if the PS/2 keyboard, and the serial port, still work on
>> Xen, to interact e.g. with the UEFI shell?
> 
> Yes, I can still interact with the UEFI shell with this series applied,
> both via the console and via VNC (which uses respectively the serial
> port and PS/2 I think).

Thank you -- can you please follow up with a Tested-by, or do you prefer
if I push the set without it?

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

Re: [edk2] [PATCH] OvmfPkg: retire "create-release.py"

[Laszlo Ersek]

On 03/25/19 14:24, Laszlo Ersek wrote:
> Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1653
> 
> "create-release.py" generates a 2-BSDL copyright block that will no longer
> apply once we fix <https://bugzilla.tianocore.org/show_bug.cgi?id=1373>.
> 
> Rather than update "create-release.py", remove it. We haven't used it in
> several years now, plus source releases of upstream edk2 are now covered
> by the edk2 stable tags
> <https://github.com/tianocore/tianocore.github.io/wiki/EDK-II#stable-tags>.
> 
> Regarding binary releases of upstream OVMF: OVMF and ArmVirtQemu binaries
> built at the edk2 stable tags are being bundled with upstream QEMU,
> similarly to other firmware that runs on QEMU platforms:
> <https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg06148.html>.
> Furthermore, the Xen project has provided its own builds of OVMF and
> ArmVirtXen for a good while now.
> 
> Cc: Anthony Perard 
> Cc: Ard Biesheuvel 
> Cc: Jordan Justen 
> Cc: Julien Grall 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Laszlo Ersek 
> ---
> 
> Notes:
> Repo:   https://github.com/lersek/edk2.git
> Branch: retire_create_release
> 
>  OvmfPkg/create-release.py | 208 
>  1 file changed, 208 deletions(-)

Pushed as commit cf85ba23d58c.

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

Re: [edk2] [edk2-announce] Mailing List Move Day Set: April 4th

[Laszlo Ersek]

On 03/25/19 23:21, Rebecca Cran via edk2-devel wrote:
> On 3/25/19 10:21 AM, stephano wrote:
>>
>> This is a good point and shows the level of detail that is preserved
>> by the mailing list if maintained properly. I would assume this is
>> part of the reason that the Linux kernel has continued to use mailing
>> lists for patch review as this level of detail is highly desired in
>> their case.
> 
> 
> Talking of such things, I noticed a couple weeks ago that the Gmane link
> at https://lists.01.org/mailman/listinfo/edk2-devel doesn't work .

Indeed, we should now replace that link with:

- https://www.mail-archive.com/edk2-devel@lists.01.org/info.html
- https://www.mail-archive.com/edk2-devel@lists.01.org/

as the "alternative archive".

(OTOH, it may be simpler to just wait until we move to gropus.io).

> From https://en.wikipedia.org/wiki/Gmane :
> 
> "In July 2016, Ingebrigtsen announced that he was considering shutting
> Gmane down, and the web interface was taken offline.^[2]
>  ^[3]
>  In August 2016 Gmane
> was acquired by Yomura Holdings. Only the message spool was transferred,
> with the software behind the site having to be redeveloped.^[4]
>  ^[5]
>  On the 6 September
> 2016, it was announced that the Gmane web interface would be coming
> online again.^[6] 
> However, by February 2018 a LWN.net
>  article observed that the web
> interface did "never [...] return, breaking thousands of links across
> the net. The front page still says 'some things are very broken' and
> links to a blog page that was last updated in September 2016."^[7]
> "

The downfall of GMANE was nothing short of a catastrophe, for open source.

(It was also what taught me to capture Message-ID-based links to
archived messages. Message-IDs outlive websites.)

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

Re: [edk2] [PATCH v2 0/3] Ovmf: Stop using ISA drivers within IntelFrameworkModulePkg

[Laszlo Ersek]

On 03/26/19 11:09, Julien Grall wrote:
> Hi Laszlo,
> 
> On 3/25/19 11:29 AM, Laszlo Ersek wrote:
>> On 03/25/19 11:58, Laszlo Ersek wrote:
>>> On 03/25/19 06:28, Hao Wu wrote:
>> (4) Julien, Anthony: can you please fetch this series (github URL at the
>> top) and see if the PS/2 keyboard, and the serial port, still work on
>> Xen, to interact e.g. with the UEFI shell?
> 
> Just to confirm, should we test for x86 only? If so, I will leave that
> to Anthony.

Yes, this is x86 only.

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

Re: [edk2] [PATCH v2 0/3] Ovmf: Stop using ISA drivers within IntelFrameworkModulePkg

[Laszlo Ersek]

On 03/26/19 11:14, Laszlo Ersek wrote:
> On 03/26/19 03:49, Wu, Hao A wrote:
>>> -Original Message-
>>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>>> Sent: Monday, March 25, 2019 7:29 PM
>>> To: Wu, Hao A; edk2-devel@lists.01.org; Julien Grall; Anthony Perard
>>> Cc: Justen, Jordan L; Ard Biesheuvel; Ni, Ray
>>> Subject: Re: [PATCH v2 0/3] Ovmf: Stop using ISA drivers within
>>> IntelFrameworkModulePkg
>>>
>>> On 03/25/19 11:58, Laszlo Ersek wrote:
>>>> On 03/25/19 06:28, Hao Wu wrote:
>>>>> The series is also available at:
>>>>> https://github.com/hwu25/edk2/tree/ovmf_siobus_v2
>>>>>
>>>>> V2 changes:
>>>>> * Introduce a static build flag 'USE_LEGACY_ISA_STACK' in OVMF DSC files
>>>>>   for users to select between the ISA driver stacks.
>>>>> * V1 patch 2/2 is split into 2 patches in V2. The first one will add the
>>>>>   new OVMF SioBusDxe driver and list it in the DSC files. Then second one
>>>>>   will add the whole new ISA stack in DSC/FDF files.
>>>>>
>>>>>
>>>>> V1 history:
>>>>>
>>>>> This series will update the OVMF to stop using the ISA drivers within
>>>>> IntelFrameworkModulePkg.
>>>>>
>>>>> As the replacement, a new OVMF Super I/O bus driver has been add which
>>>>> will install the Super I/O protocol for ISA serial and PS2 keyboard
>>>>> devices. By doing so, these devices can be managed by:
>>>>>
>>>>>   MdeModulePkg/Bus/Pci/PciSioSerialDxe/PciSioSerialDxe.inf
>>>>>   MdeModulePkg/Bus/Isa/Ps2KeyboardDxe/Ps2KeyboardDxe.inf
>>>>>
>>>>> respectively.
>>>>>
>>>>>
>>>>> Tests done:
>>>>> A. GCC5 & VS2015x86 tool chains build pass
>>>>> B. Launch QEMU (2.4.50, Windows) with command:
>>>>>> qemu-system-x86_64.exe -pflash \OVMF.fd -serial
>>> file:1.txt -serial file:2.txt
>>>>>
>>>>>Able to see the ISA COM1/COM2 UART and PS2Keyboard devices under
>>> Shell
>>>>>using command 'devtree';
>>>>>
>>>>>Both the serials and PS2 keyboard are working fine;
>>>>
>>>> Can you please confirm the following:
>>>>
>>>> (1) In the PrepareLpcBridgeDevicePath() function, in file
>>>> "OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c", we add
>>>> IsaKeyboard to ConIn, and IsaSerial to ConOut, ConIn, ErrOut.
>>>>
>>>> This function takes the "LPC Bridge device" handle from its caller,
>>>> namely DetectAndPreparePlatformPciDevicePath(), and appends some
>>>> constant device path nodes, from "BdsPlatform.h" / "PlatformData.c".
>>>>
>>>> Can you please confirm that the existing Platform BDS code described
>>>> above is compatible with the new driver?
>>>>
>>>> In other words, do DetectAndPreparePlatformPciDevicePath() +
>>>> PrepareLpcBridgeDevicePath() still add the proper device paths to
>>>> ConIn/ConOut/ErrOut?
>>>>
>>>> (Note, they need not be identical to the previous device paths, but the
>>>> *logic* must continue to work -- i.e. *some* device paths have to be
>>>> added, and they should be correct.)
>>
>> Hello Laszlo,
>>
>> For (1), since I saw in function PrepareLpcBridgeDevicePath() there are
>> already some codes to print out the device path for COM1/COM2. So I just
>> add some logic to print the device path for the PS2 keyboard as well.
>>
>> I ran the qemu with command:
>> qemu-system-x86_64.exe -pflash \OVMF.fd -debugcon file:boot.log 
>> -global isa-debugcon.iobase=0x402
>>
>> For the new and origin ISA stack, their logs both show:
>> Found LPC Bridge device
>> BdsPlatform.c+585: PS2 Keyboard DevPath: 
>> PciRoot(0x0)/Pci(0x1,0x0)/Acpi(PNP0303,0x0)
>> BdsPlatform.c+615: COM1 DevPath: 
>> PciRoot(0x0)/Pci(0x1,0x0)/Serial(0x0)/Uart(115200,8,N,1)/VenMsg(E0C14753-F9BE-11D2-9A0C-0090273FC14D)
>> BdsPlatform.c+647: COM2 DevPath: 
>> PciRoot(0x0)/Pci(0x1,0x0)/Serial(0x1)/Uart(115200,8,N,1)/VenMsg(E0C14753-F9BE-11D2-9A0C-0090273FC14D)
>>
>> Thus, I think the Platform BDS code behavior remains the same.
>>
>>>>
>>>> (2) Can you please confirm if the new build survives repeated
>>>>
>>>&

Re: [edk2] [PATCH v2 2/3] OvmfPkg: Add an Super IO bus driver

[Laszlo Ersek]

On 03/25/19 21:02, Kinney, Michael D wrote:
> Hi Laszlo,
> 
> The review of the content based on the edk2-stable201903
> is intended to make sure there are no mistakes on that
> content so I can adjust for the final patch series.  A
> mistake would be applying new license to files that should
> not be updated, or not applying the license to a file that
> should have been updated.  You provided valuable feedback
> on those two points for OvmfPkg in V1.
> 
> I agree it will be simpler if we can guarantee no file
> add/remove commits occur in a window leading up to 
> April 9, 2019.  So it is not a freeze on all content.
> It would be a freeze on commits that add/remove files.

Good point.

> How does a ~1 week of no commits of file add/remove
> starting April 1 sound?  I can produce a V3 on April 2
> for final review by all package maintainers.

That sounds great. I'd be happy to iterate multiple times during that
freeze, if necessary (so v3 wouldn't have to be the final version even);
what matters is that the reviews should converge.

Thus, considering actions on my end regarding the v2 posting, I'll delay
reviewing v2 (or v3 if you post v3 meanwhile) until April 2.

I'm making a note in my calendar, but please do ping me on April 2 --
I'm the one requesting this freeze, so once it starts, I should be as
responsive as possible.

> I would of course rebase the patch series on April 9 and
> also verify that no files were added/removed.

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

Re: [edk2] [PATCH v2 0/3] Ovmf: Stop using ISA drivers within IntelFrameworkModulePkg

[Laszlo Ersek]

On 03/26/19 03:49, Wu, Hao A wrote:
>> -Original Message-
>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>> Sent: Monday, March 25, 2019 7:29 PM
>> To: Wu, Hao A; edk2-devel@lists.01.org; Julien Grall; Anthony Perard
>> Cc: Justen, Jordan L; Ard Biesheuvel; Ni, Ray
>> Subject: Re: [PATCH v2 0/3] Ovmf: Stop using ISA drivers within
>> IntelFrameworkModulePkg
>>
>> On 03/25/19 11:58, Laszlo Ersek wrote:
>>> On 03/25/19 06:28, Hao Wu wrote:
>>>> The series is also available at:
>>>> https://github.com/hwu25/edk2/tree/ovmf_siobus_v2
>>>>
>>>> V2 changes:
>>>> * Introduce a static build flag 'USE_LEGACY_ISA_STACK' in OVMF DSC files
>>>>   for users to select between the ISA driver stacks.
>>>> * V1 patch 2/2 is split into 2 patches in V2. The first one will add the
>>>>   new OVMF SioBusDxe driver and list it in the DSC files. Then second one
>>>>   will add the whole new ISA stack in DSC/FDF files.
>>>>
>>>>
>>>> V1 history:
>>>>
>>>> This series will update the OVMF to stop using the ISA drivers within
>>>> IntelFrameworkModulePkg.
>>>>
>>>> As the replacement, a new OVMF Super I/O bus driver has been add which
>>>> will install the Super I/O protocol for ISA serial and PS2 keyboard
>>>> devices. By doing so, these devices can be managed by:
>>>>
>>>>   MdeModulePkg/Bus/Pci/PciSioSerialDxe/PciSioSerialDxe.inf
>>>>   MdeModulePkg/Bus/Isa/Ps2KeyboardDxe/Ps2KeyboardDxe.inf
>>>>
>>>> respectively.
>>>>
>>>>
>>>> Tests done:
>>>> A. GCC5 & VS2015x86 tool chains build pass
>>>> B. Launch QEMU (2.4.50, Windows) with command:
>>>>> qemu-system-x86_64.exe -pflash \OVMF.fd -serial
>> file:1.txt -serial file:2.txt
>>>>
>>>>Able to see the ISA COM1/COM2 UART and PS2Keyboard devices under
>> Shell
>>>>using command 'devtree';
>>>>
>>>>Both the serials and PS2 keyboard are working fine;
>>>
>>> Can you please confirm the following:
>>>
>>> (1) In the PrepareLpcBridgeDevicePath() function, in file
>>> "OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c", we add
>>> IsaKeyboard to ConIn, and IsaSerial to ConOut, ConIn, ErrOut.
>>>
>>> This function takes the "LPC Bridge device" handle from its caller,
>>> namely DetectAndPreparePlatformPciDevicePath(), and appends some
>>> constant device path nodes, from "BdsPlatform.h" / "PlatformData.c".
>>>
>>> Can you please confirm that the existing Platform BDS code described
>>> above is compatible with the new driver?
>>>
>>> In other words, do DetectAndPreparePlatformPciDevicePath() +
>>> PrepareLpcBridgeDevicePath() still add the proper device paths to
>>> ConIn/ConOut/ErrOut?
>>>
>>> (Note, they need not be identical to the previous device paths, but the
>>> *logic* must continue to work -- i.e. *some* device paths have to be
>>> added, and they should be correct.)
> 
> Hello Laszlo,
> 
> For (1), since I saw in function PrepareLpcBridgeDevicePath() there are
> already some codes to print out the device path for COM1/COM2. So I just
> add some logic to print the device path for the PS2 keyboard as well.
> 
> I ran the qemu with command:
> qemu-system-x86_64.exe -pflash \OVMF.fd -debugcon file:boot.log 
> -global isa-debugcon.iobase=0x402
> 
> For the new and origin ISA stack, their logs both show:
> Found LPC Bridge device
> BdsPlatform.c+585: PS2 Keyboard DevPath: 
> PciRoot(0x0)/Pci(0x1,0x0)/Acpi(PNP0303,0x0)
> BdsPlatform.c+615: COM1 DevPath: 
> PciRoot(0x0)/Pci(0x1,0x0)/Serial(0x0)/Uart(115200,8,N,1)/VenMsg(E0C14753-F9BE-11D2-9A0C-0090273FC14D)
> BdsPlatform.c+647: COM2 DevPath: 
> PciRoot(0x0)/Pci(0x1,0x0)/Serial(0x1)/Uart(115200,8,N,1)/VenMsg(E0C14753-F9BE-11D2-9A0C-0090273FC14D)
> 
> Thus, I think the Platform BDS code behavior remains the same.
> 
>>>
>>> (2) Can you please confirm if the new build survives repeated
>>>
>>>   reconnect -r
>>>
>>> commands in the UEFI shell? Both the ISA keyboard and the serial console
>>> should resume working after "reconnect -r".
> 
> For (2), I also run the qemu with:
> qemu-system-x86_64.exe -pflash \OVMF.fd -debugcon file:boot.log 
> -global isa-debugcon.iobase=0x402
> 
> After running 'reconnect -r' under Shell, the PS2 keyboard 

Re: [edk2] [PATCH v2 2/3] OvmfPkg: Add an Super IO bus driver

[Laszlo Ersek]

On 03/25/19 18:30, Kinney, Michael D wrote:
> Hi Laszlo,
> 
> I do not think content added before April 9, 2019
> should use the new license type.  We need to let the
> 30-day review period complete and make sure all feedback
> is resolved.

Good point.

> We will handle files added between the edk2-stable201903
> and April 9, 2019 in a final patch series with an easy
> way for all maintainers to see what has changed between
> those two points.

Hm. From the reviewer side, this is not optimal. The patch set (and the
individual patches themselves) are pretty big, and doing incremental
reviews on them is taxing. Regardless of whether the incremental review
needs to target an updated "full" patch set, or just an incremental
patch set (for new files), the reviewer needs to re-evaluate whether
something is now missed, after the introduction of new files.

Instead, I'd prefer a "lock" period for OvmfPkg and ArmVirtPkg, between
(a) my next (hopefully, final) review for the license conversion
patches, and (b) the pushing of those patches. For that, I see two options:

- We could delay Hao's work (and all other patches that add files to
OvmfPkg and ArmVirtPkg files) until after April 9. We can of course
collaborate on feature / bugfix patches meanwhile, it's just that the
final versions of *those* should be reposted with updated license
blocks. Incrementally reviewing *those* changes feels a lot easier to me.

- Alternatively, I could delay my next (hopefully, final) review of the
license conversion patches until reasonably close to April 9, until
which "review point" new files could be added freely, to OvmfPkg and
ArmVirtPkg. (This wouldn't eliminate the "lock period", just make it
shorter for contributors.)

IOW, this is similar to the stabilization period / feature freezes, just
much more intrusive, because everything has to be switched at the same
moment.

I'd like to reach an understanding on our approach before I start
reviewing "[edk2] [PATCH V2] Change EDK II to BSD+Patent License".

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

Re: [edk2] [PATCH] Fix links in Maintainers.txt and remove slow outdated sourceforge git mirror

[Laszlo Ersek]

On 03/25/19 14:30, Rebecca Cran via edk2-devel wrote:
> On 3/25/19 5:49 AM, Laszlo Ersek wrote:
>>
>> Any particular reason for dropping the website URL update?
>> <http://www.tianocore.org/edk2/> still redirects to
>> <https://github.com/tianocore/tianocore.github.io/wiki/EDK-II>, and your
>> previous patch (correctly) included that new URL.
> 
> 
> Stephano recently posted a message with a link
> tohttps://www.tianocore.org/monthly-meeting/  which redirects to
> https://github.com/tianocore/tianocore.github.io/wiki/Monthly-Meeting,
> so I think it makes sense to keep the shorter/nicer URLs since there are
> redirects in place.
> 

Pushed as commit b669adebd01d, with Liming's R-b, and mine.

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

[edk2] [PATCH] OvmfPkg: retire "create-release.py"

[Laszlo Ersek]

Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1653

"create-release.py" generates a 2-BSDL copyright block that will no longer
apply once we fix <https://bugzilla.tianocore.org/show_bug.cgi?id=1373>.

Rather than update "create-release.py", remove it. We haven't used it in
several years now, plus source releases of upstream edk2 are now covered
by the edk2 stable tags
<https://github.com/tianocore/tianocore.github.io/wiki/EDK-II#stable-tags>.

Regarding binary releases of upstream OVMF: OVMF and ArmVirtQemu binaries
built at the edk2 stable tags are being bundled with upstream QEMU,
similarly to other firmware that runs on QEMU platforms:
<https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg06148.html>.
Furthermore, the Xen project has provided its own builds of OVMF and
ArmVirtXen for a good while now.

Cc: Anthony Perard 
Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Cc: Julien Grall 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek 
---

Notes:
Repo:   https://github.com/lersek/edk2.git
Branch: retire_create_release

 OvmfPkg/create-release.py | 208 
 1 file changed, 208 deletions(-)

diff --git a/OvmfPkg/create-release.py b/OvmfPkg/create-release.py
deleted file mode 100755
index 82d8e7b0a2b8..
--- a/OvmfPkg/create-release.py
+++ /dev/null
@@ -1,208 +0,0 @@
-#!/usr/bin/python
-#
-# Copyright (c) 2010 - 2013, Intel Corporation. All rights reserved.
-#
-# 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.
-#
-
-import os
-import re
-import StringIO
-import subprocess
-import sys
-import zipfile
-
-is_unix = not sys.platform.startswith('win')
-
-if not is_unix:
-print "This script currently only supports unix-like systems"
-sys.exit(-1)
-
-if os.path.exists('OvmfPkgX64.dsc'):
-os.chdir('..')
-
-if not os.path.exists(os.path.join('OvmfPkg', 'OvmfPkgX64.dsc')):
-print "OvmfPkg/OvmfPkgX64.dsc doesn't exist"
-sys.exit(-1)
-
-def run_and_capture_output(args, checkExitCode = True):
-p = subprocess.Popen(args=args, stdout=subprocess.PIPE)
-stdout = p.stdout.read()
-ret_code = p.wait()
-if checkExitCode:
-assert ret_code == 0
-return stdout
-
-gcc_version = run_and_capture_output(args=('gcc', '--version'))
-gcc_re = re.compile(r'\s*\S+\s+\([^\)]+?\)\s+(\d+(?:\.\d+)*)(?:\s+.*)?')
-mo = gcc_re.match(gcc_version)
-if not mo:
-print "Unable to find GCC version"
-sys.exit(-1)
-gcc_version = map(lambda n: int(n), mo.group(1).split('.'))
-
-if 'TOOLCHAIN' in os.environ:
-TOOLCHAIN = os.environ['TOOLCHAIN']
-else:
-assert(gcc_version[0] == 4)
-minor = max(4, min(7, gcc_version[1]))
-TOOLCHAIN = 'GCC4' + str(minor)
-
-def git_based_version():
-dir = os.getcwd()
-if not os.path.exists('.git'):
-os.chdir('OvmfPkg')
-stdout = run_and_capture_output(args=('git', 'log',
-  '-n', '1',
-  '--abbrev-commit'))
-regex = re.compile(r'^\s*git-svn-id:\s+\S+@(\d+)\s+[0-9a-f\-]+$',
-   re.MULTILINE)
-mo = regex.search(stdout)
-if mo:
-version = 'r' + mo.group(1)
-else:
-version = stdout.split(None, 3)[1]
-os.chdir(dir)
-return version
-
-def svn_info():
-dir = os.getcwd()
-os.chdir('OvmfPkg')
-stdout = run_and_capture_output(args=('svn', 'info'))
-os.chdir(dir)
-return stdout
-
-def svn_based_version():
-buf = svn_info()
-revision_re = re.compile('^Revision\:\s*([\da-f]+)$', re.MULTILINE)
-mo = revision_re.search(buf)
-assert(mo is not None)
-return 'r' + mo.group(1)
-
-def get_revision():
-if os.path.exists(os.path.join('OvmfPkg', '.svn')):
-return svn_based_version()
-else:
-return git_based_version()
-
-revision = get_revision()
-
-newline_re = re.compile(r'(\n|\r\n|\r(?!\n))', re.MULTILINE)
-def to_dos_text(str):
-return newline_re.sub('\r\n', str)
-
-def gen_build_info():
-distro = run_and_capture_output(args=('lsb_release', '-sd')).strip()
-
-machine = run_and_capture_output(args=('uname', '-m')).strip()
-
-gcc_version_str = '.'.join(map(lambda v: str(v), gcc_version))
-
-ld_version = run_and_capture_output(args=('ld', '--version'))
-ld_version = ld_version.split('\n')[0].split()[-1]
-
-iasl_version = run_and_capture_output(args=('iasl'), checkExitCode=False)
-iasl_version = filter(lambda s: s.find(' version ') >= 0, 
iasl_version.split('\n'))[0]
-iasl_v

Re: [edk2] [edk2-announce] Mailing List Move Day Set: April 4th

[Laszlo Ersek]

Hi Stephano,

On 03/23/19 01:41, stephano wrote:
> I will be moving our mailing list from 01.org over to Groups.io as of
> April 4th. I will send out another warning 1 week before, and a final
> warning 1 day before the move.
> 
> On April 4th the edk2-devel@lists.01.org will begin to bounce emails and
> I will begin uploading the archive to Groups.io. I do not have an
> estimate from Groups.io on how long that archive upload will take.
> 
> To summarize: after April 4th 2019 you can *no longer send patches to
> edk2-devel@lists.01.org*. Please send all patches to:
> 
> de...@edk2.groups.io

Can you please confirm that the current mailing list archive URLs will
continue working? For example:

https://lists.01.org/pipermail/edk2-devel/2019-March/038114.html

It's fine if the archive will not be extended with new messages in the
future, and also if the old messages get uploaded in the new list
archive. However, the old links should continue working as well,
indefinitely (it will not require additional storage, just a bit of
additional bandwidth, as old messages are looked up).

Personally, when I provide archive links (in discussions, BZs, commit
messages etc), I tend to make sure that I include two links: one into
the master archive, and another (to the same message) into the
mail-archive.com archive. From these, I make sure that the 2nd one is
always a Message-ID-based URL. The benefit is that, even if
mail-archive.com disappears, people can construct new URLs to old
messages, from the old message-IDs that are captured in the old URLs --
assuming a new archive service exposes the old messages by message-ID again.

*However*, that's just me. Most people include just one link, and that's
into the current master archive. Those links make no sense outside of
the specific archive service. And, I suffer *to this day* from the fact
that GMANE had gone down in summer 2016, and a huge amount of old
references (into the GMANE archive) are now completely useless.

In brief, please preseve the archive at
, albeit with locked down
content, indefinitely.

Thank you,
Laszlo

> 
> This new list requires 1 email approval before you can post, so please
> be patient as our moderators approve you all.
> 
> After April 4th, all announcements will come from:
> 
> annou...@edk2.groups.io
> 
> This list only allows moderators to post, so please contact me if you
> have announcements.
> 
> As always, I welcome your comments and questions. Thank you for your
> patience while we work to improve the quality of our community.
> 
> Cheers,
> Stephano
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

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

Re: [edk2] [PATCH V2] Change EDK II to BSD+Patent License

[Laszlo Ersek]

Hi Mike,

On 03/23/19 03:25, Kinney, Michael D wrote:
> Hello,
> 
> New in V2
> =
> * Remove Cc lines from commit messages
> * Remove branch reference from commit messages
> * Change license in 2 files missed in OvmfPkg
> * Update OvmfPkg/License.txt to BSD+Patent as the default license
> * Move the portions of Contributions.txt in the root of edk2 to
>   Readme.md in the root of edk2 that describe how to contribute
>   along with the commit message format.
> * Add to Readme.md in the root of edk2 that Signed-off-by means that
>   the contributor certifies compliance to the Developer's Certificate
>   of Origin 1.1.  https://developercertificate.org
> =

[...]

> The patch series has one patch per package along with a few patches
> to update the license information in the root of the edk2 repository
> as described in the RFC V3.

[...]

> f9d59ccdc5 OvmfPkg: Change License.txt from 2-Clause BSD to BSD+Patent

[...]

> e39d07266d OvmfPkg: Replace BSD License with BSD+Patent License

The series now has two patches for OvmfPkg. Did you intend to squash
these into one (to match the original intent quoted above, i.e. one
patch per pkg), or did you intend to keep both patches separate?

If you meant to squash them, can you please do that and push a v3?

If the patches should be separate, I'll review both patches as they are
(plus recheck ArmVirtPkg).

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

Re: [edk2] [PATCH v2 2/3] OvmfPkg: Add an Super IO bus driver

[Laszlo Ersek]

Hello Hao,

(+Mike)

my apologies that I seem unable to collect my thoughts in one go... So
here's another comment:

On 03/25/19 06:28, Hao Wu wrote:

> diff --git a/OvmfPkg/SioBusDxe/SioBusDxe.inf b/OvmfPkg/SioBusDxe/SioBusDxe.inf
> new file mode 100644
> index 00..5c462f1a8c
> --- /dev/null
> +++ b/OvmfPkg/SioBusDxe/SioBusDxe.inf
> @@ -0,0 +1,54 @@
> +## @file
> +#  The SioBusDxe driver is used to create child devices on the ISA bus and
> +#  installs the Super I/O protocols on them.
> +#
> +#  Copyright (c) 2019, Intel Corporation. All rights reserved.
> +#
> +#  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.
> +#
> +##

[...]

This patch adds 7 new instances of the 2-clause BSDL (in expanded form)
to the edk2 tree. In that it conflicts with Mike's work for
. Can you please
rework this patch so that the new files say

  SPDX-License-Identifier: BSD-2-Clause-Patent

instead?

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

Re: [edk2] [PATCH] Fix links in Maintainers.txt and remove slow outdated sourceforge git mirror

[Laszlo Ersek]

(+Liming)

OK, so the last comment on this patch was at:

6800a51b-fa21-f325-bbc1-d17e3c8b62e2@redhat.com">http://mid.mail-archive.com/6800a51b-fa21-f325-bbc1-d17e3c8b62e2@redhat.com

Let's see the changes:


On 03/24/19 03:00, Rebecca Cran via edk2-devel wrote:
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Rebecca Cran 

This looks good. (The contributed-under line will soon become
unnecessary, but for now it's still required & correct, AIUI.)

> ---
>  Maintainers.txt | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/Maintainers.txt b/Maintainers.txt
> index be77898ee2..4c9adf802b 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -40,10 +40,9 @@ Descriptions of section entries:
>  EDK II
>  --
>  W: http://www.tianocore.org/edk2/

Any particular reason for dropping the website URL update?
<http://www.tianocore.org/edk2/> still redirects to
<https://github.com/tianocore/tianocore.github.io/wiki/EDK-II>, and your
previous patch (correctly) included that new URL.

> -L: https://lists.sourceforge.net/lists/listinfo/edk2-devel
> +L: https://lists.01.org/mailman/listinfo/edk2-devel

This is the same as before, and it's good (we'll change this soon to
groups.io, I reckon, but for now it's good).

>  T: git - https://github.com/tianocore/edk2.git
>  T: git (mirror) - https://bitbucket.org/tianocore/edk2.git
> -T: git (mirror) - http://git.code.sf.net/p/tianocore/edk2

Same as before, and also good.

>  T: svn (read-only, deprecated) - 
> https://svn.code.sf.net/p/edk2/code/trunk/edk2
>  
>  Tianocore Stewards
> 

So, if you dropped the "W:" change intentionally, I don't mind. After
all, the original link still works, and the patch is still a pure
improvement.

Reviewed-by: Laszlo Ersek 

If Liming too is OK with this patch (and you don't intend to update it),
I can help push it.

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

Re: [edk2] [PATCH v2 0/3] Ovmf: Stop using ISA drivers within IntelFrameworkModulePkg

[Laszlo Ersek]

On 03/25/19 11:58, Laszlo Ersek wrote:
> On 03/25/19 06:28, Hao Wu wrote:
>> The series is also available at:
>> https://github.com/hwu25/edk2/tree/ovmf_siobus_v2
>>
>> V2 changes:
>> * Introduce a static build flag 'USE_LEGACY_ISA_STACK' in OVMF DSC files
>>   for users to select between the ISA driver stacks.
>> * V1 patch 2/2 is split into 2 patches in V2. The first one will add the
>>   new OVMF SioBusDxe driver and list it in the DSC files. Then second one
>>   will add the whole new ISA stack in DSC/FDF files.
>>
>>
>> V1 history:
>>
>> This series will update the OVMF to stop using the ISA drivers within
>> IntelFrameworkModulePkg.
>>
>> As the replacement, a new OVMF Super I/O bus driver has been add which
>> will install the Super I/O protocol for ISA serial and PS2 keyboard
>> devices. By doing so, these devices can be managed by:
>>
>>   MdeModulePkg/Bus/Pci/PciSioSerialDxe/PciSioSerialDxe.inf
>>   MdeModulePkg/Bus/Isa/Ps2KeyboardDxe/Ps2KeyboardDxe.inf
>>
>> respectively.
>>
>>
>> Tests done:
>> A. GCC5 & VS2015x86 tool chains build pass
>> B. Launch QEMU (2.4.50, Windows) with command:
>>> qemu-system-x86_64.exe -pflash \OVMF.fd -serial file:1.txt 
>> -serial file:2.txt
>>
>>Able to see the ISA COM1/COM2 UART and PS2Keyboard devices under Shell
>>using command 'devtree';
>>
>>Both the serials and PS2 keyboard are working fine;
> 
> Can you please confirm the following:
> 
> (1) In the PrepareLpcBridgeDevicePath() function, in file
> "OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c", we add
> IsaKeyboard to ConIn, and IsaSerial to ConOut, ConIn, ErrOut.
> 
> This function takes the "LPC Bridge device" handle from its caller,
> namely DetectAndPreparePlatformPciDevicePath(), and appends some
> constant device path nodes, from "BdsPlatform.h" / "PlatformData.c".
> 
> Can you please confirm that the existing Platform BDS code described
> above is compatible with the new driver?
> 
> In other words, do DetectAndPreparePlatformPciDevicePath() +
> PrepareLpcBridgeDevicePath() still add the proper device paths to
> ConIn/ConOut/ErrOut?
> 
> (Note, they need not be identical to the previous device paths, but the
> *logic* must continue to work -- i.e. *some* device paths have to be
> added, and they should be correct.)
> 
> (2) Can you please confirm if the new build survives repeated
> 
>   reconnect -r
> 
> commands in the UEFI shell? Both the ISA keyboard and the serial console
> should resume working after "reconnect -r".

(3) Hao, can you please verify the above steps on the "q35" machine type
as well?

(The QEMU command line that you mention selects the "i440fx" machine
type. QEMU provides an ICH9 ISA controller with the q35 board, and a
PIIX4 one with the i440fx board. I think we should regression-test this
work with both.)

(4) Julien, Anthony: can you please fetch this series (github URL at the
top) and see if the PS/2 keyboard, and the serial port, still work on
Xen, to interact e.g. with the UEFI shell?

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

Re: [edk2] [PATCH v2 2/3] OvmfPkg: Add an Super IO bus driver

[Laszlo Ersek]

On 03/25/19 06:28, Hao Wu wrote:
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1495
> 
> There is a plan to remove the IntelFrameworkModulePkg:
> https://bugzilla.tianocore.org/show_bug.cgi?id=1605
> 
> This patch will a new OVMF Super I/O bus driver which will create the
> below child devices:
> 
> * COM 1 UART
> * COM 2 UART
> * PS/2 Keyboard
> 
> and installs the Super I/O Protocol on them.
> 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: Ray Ni 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Hao Wu 
> ---
>  OvmfPkg/OvmfPkgIa32.dsc   |   1 +
>  OvmfPkg/OvmfPkgIa32X64.dsc|   1 +
>  OvmfPkg/OvmfPkgX64.dsc|   1 +
>  OvmfPkg/SioBusDxe/SioBusDxe.inf   |  54 ++
>  OvmfPkg/SioBusDxe/SioBusDxe.h | 332 +++
>  OvmfPkg/SioBusDxe/SioService.h| 221 +++
>  OvmfPkg/SioBusDxe/ComponentName.c | 167 ++
>  OvmfPkg/SioBusDxe/SioBusDxe.c | 622 
>  OvmfPkg/SioBusDxe/SioService.c| 405 +
>  OvmfPkg/SioBusDxe/SioBusDxe.uni   |  21 +
>  10 files changed, 1825 insertions(+)

Acked-by: Laszlo Ersek 

but please don't push the series before answering my questions under 0/3.

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

Re: [edk2] [PATCH v2 3/3] OvmfPkg: Add a build flag to select ISA driver stack

[Laszlo Ersek]

On 03/25/19 06:28, Hao Wu wrote:
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1495
> 
> This commit will add a static build flag 'USE_LEGACY_ISA_STACK' to select
> the ISA driver stack.
> 
> If the flag is set to TRUE, the below driver stack will be used:
>   PcAtChipsetPkg/IsaAcpiDxe/IsaAcpi.inf
>   IntelFrameworkModulePkg/Bus/Isa/IsaBusDxe/IsaBusDxe.inf
>   IntelFrameworkModulePkg/Bus/Isa/IsaSerialDxe/IsaSerialDxe.inf
>   IntelFrameworkModulePkg/Bus/Isa/Ps2KeyboardDxe/Ps2keyboardDxe.inf
> 
> If the flag is set to FALSE, the below driver stack will be used:
>   OvmfPkg/SioBusDxe/SioBusDxe.inf
>   MdeModulePkg/Bus/Pci/PciSioSerialDxe/PciSioSerialDxe.inf
>   MdeModulePkg/Bus/Isa/Ps2KeyboardDxe/Ps2KeyboardDxe.inf
> 
> The default value is set to FALSE in OVMF DSC files.
> 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: Ray Ni 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Hao Wu 
> ---
>  OvmfPkg/OvmfPkgIa32.dsc|  6 ++
>  OvmfPkg/OvmfPkgIa32X64.dsc |  6 ++
>  OvmfPkg/OvmfPkgX64.dsc |  6 ++
>  OvmfPkg/OvmfPkgIa32.fdf| 18 --
>  OvmfPkg/OvmfPkgIa32X64.fdf | 18 --
>  OvmfPkg/OvmfPkgX64.fdf | 18 --
>  6 files changed, 54 insertions(+), 18 deletions(-)
> 
> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> index 3be0314146..f55ab5a3d2 100644
> --- a/OvmfPkg/OvmfPkgIa32.dsc
> +++ b/OvmfPkg/OvmfPkgIa32.dsc
> @@ -41,6 +41,7 @@
>DEFINE TLS_ENABLE  = FALSE
>DEFINE TPM2_ENABLE = FALSE
>DEFINE TPM2_CONFIG_ENABLE  = FALSE
> +  DEFINE USE_LEGACY_ISA_STACK= FALSE
>  
>#
># Flash size selection. Setting FD_SIZE_IN_KB on the command line directly 
> to
> @@ -752,11 +753,16 @@
>#
># ISA Support
>#
> +!if $(USE_LEGACY_ISA_STACK) == FALSE
>OvmfPkg/SioBusDxe/SioBusDxe.inf
> +  MdeModulePkg/Bus/Pci/PciSioSerialDxe/PciSioSerialDxe.inf
> +  MdeModulePkg/Bus/Isa/Ps2KeyboardDxe/Ps2KeyboardDxe.inf
> +!else
>PcAtChipsetPkg/IsaAcpiDxe/IsaAcpi.inf
>IntelFrameworkModulePkg/Bus/Isa/IsaBusDxe/IsaBusDxe.inf
>IntelFrameworkModulePkg/Bus/Isa/IsaSerialDxe/IsaSerialDxe.inf
>IntelFrameworkModulePkg/Bus/Isa/Ps2KeyboardDxe/Ps2keyboardDxe.inf
> +!endif
>  
>#
># SMBIOS Support
> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
> index 3b85c2e6af..5c9bdf034e 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
> @@ -41,6 +41,7 @@
>DEFINE TLS_ENABLE  = FALSE
>DEFINE TPM2_ENABLE = FALSE
>DEFINE TPM2_CONFIG_ENABLE  = FALSE
> +  DEFINE USE_LEGACY_ISA_STACK= FALSE
>  
>#
># Flash size selection. Setting FD_SIZE_IN_KB on the command line directly 
> to
> @@ -761,11 +762,16 @@
>#
># ISA Support
>#
> +!if $(USE_LEGACY_ISA_STACK) == FALSE
>OvmfPkg/SioBusDxe/SioBusDxe.inf
> +  MdeModulePkg/Bus/Pci/PciSioSerialDxe/PciSioSerialDxe.inf
> +  MdeModulePkg/Bus/Isa/Ps2KeyboardDxe/Ps2KeyboardDxe.inf
> +!else
>PcAtChipsetPkg/IsaAcpiDxe/IsaAcpi.inf
>IntelFrameworkModulePkg/Bus/Isa/IsaBusDxe/IsaBusDxe.inf
>IntelFrameworkModulePkg/Bus/Isa/IsaSerialDxe/IsaSerialDxe.inf
>IntelFrameworkModulePkg/Bus/Isa/Ps2KeyboardDxe/Ps2keyboardDxe.inf
> +!endif
>  
>#
># SMBIOS Support
> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
> index 104b2e79a5..2943e9e8af 100644
> --- a/OvmfPkg/OvmfPkgX64.dsc
> +++ b/OvmfPkg/OvmfPkgX64.dsc
> @@ -41,6 +41,7 @@
>DEFINE TLS_ENABLE  = FALSE
>DEFINE TPM2_ENABLE = FALSE
>DEFINE TPM2_CONFIG_ENABLE  = FALSE
> +  DEFINE USE_LEGACY_ISA_STACK= FALSE
>  
>#
># Flash size selection. Setting FD_SIZE_IN_KB on the command line directly 
> to
> @@ -759,11 +760,16 @@
>#
># ISA Support
>#
> +!if $(USE_LEGACY_ISA_STACK) == FALSE
>OvmfPkg/SioBusDxe/SioBusDxe.inf
> +  MdeModulePkg/Bus/Pci/PciSioSerialDxe/PciSioSerialDxe.inf
> +  MdeModulePkg/Bus/Isa/Ps2KeyboardDxe/Ps2KeyboardDxe.inf
> +!else
>PcAtChipsetPkg/IsaAcpiDxe/IsaAcpi.inf
>IntelFrameworkModulePkg/Bus/Isa/IsaBusDxe/IsaBusDxe.inf
>IntelFrameworkModulePkg/Bus/Isa/IsaSerialDxe/IsaSerialDxe.inf
>IntelFrameworkModulePkg/Bus/Isa/Ps2KeyboardDxe/Ps2keyboardDxe.inf
> +!endif
>  
>#
># SMBIOS Support
> diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
> index 54d7f06a70..006ea9a415 100644
> --- a/OvmfPkg/OvmfPkgIa32.fdf
> +++ b/OvmfPkg/OvmfPkgIa32.fdf
> @@ -265,14 +265,20 @@ INF  
> MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
>  I

Re: [edk2] [PATCH v2 0/3] Ovmf: Stop using ISA drivers within IntelFrameworkModulePkg

[Laszlo Ersek]

On 03/25/19 06:28, Hao Wu wrote:
> The series is also available at:
> https://github.com/hwu25/edk2/tree/ovmf_siobus_v2
> 
> V2 changes:
> * Introduce a static build flag 'USE_LEGACY_ISA_STACK' in OVMF DSC files
>   for users to select between the ISA driver stacks.
> * V1 patch 2/2 is split into 2 patches in V2. The first one will add the
>   new OVMF SioBusDxe driver and list it in the DSC files. Then second one
>   will add the whole new ISA stack in DSC/FDF files.
> 
> 
> V1 history:
> 
> This series will update the OVMF to stop using the ISA drivers within
> IntelFrameworkModulePkg.
> 
> As the replacement, a new OVMF Super I/O bus driver has been add which
> will install the Super I/O protocol for ISA serial and PS2 keyboard
> devices. By doing so, these devices can be managed by:
> 
>   MdeModulePkg/Bus/Pci/PciSioSerialDxe/PciSioSerialDxe.inf
>   MdeModulePkg/Bus/Isa/Ps2KeyboardDxe/Ps2KeyboardDxe.inf
> 
> respectively.
> 
> 
> Tests done:
> A. GCC5 & VS2015x86 tool chains build pass
> B. Launch QEMU (2.4.50, Windows) with command:
>> qemu-system-x86_64.exe -pflash \OVMF.fd -serial file:1.txt 
> -serial file:2.txt
> 
>Able to see the ISA COM1/COM2 UART and PS2Keyboard devices under Shell
>using command 'devtree';
> 
>Both the serials and PS2 keyboard are working fine;

Can you please confirm the following:

(1) In the PrepareLpcBridgeDevicePath() function, in file
"OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c", we add
IsaKeyboard to ConIn, and IsaSerial to ConOut, ConIn, ErrOut.

This function takes the "LPC Bridge device" handle from its caller,
namely DetectAndPreparePlatformPciDevicePath(), and appends some
constant device path nodes, from "BdsPlatform.h" / "PlatformData.c".

Can you please confirm that the existing Platform BDS code described
above is compatible with the new driver?

In other words, do DetectAndPreparePlatformPciDevicePath() +
PrepareLpcBridgeDevicePath() still add the proper device paths to
ConIn/ConOut/ErrOut?

(Note, they need not be identical to the previous device paths, but the
*logic* must continue to work -- i.e. *some* device paths have to be
added, and they should be correct.)

(2) Can you please confirm if the new build survives repeated

  reconnect -r

commands in the UEFI shell? Both the ISA keyboard and the serial console
should resume working after "reconnect -r".

Thanks,
Laszlo






> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: Ray Ni 
> 
> 
> Hao Wu (3):
>   OvmfPkg: Drop the ISA Floppy device support
>   OvmfPkg: Add an Super IO bus driver
>   OvmfPkg: Add a build flag to select ISA driver stack
> 
>  OvmfPkg/OvmfPkgIa32.dsc   |  10 +-
>  OvmfPkg/OvmfPkgIa32X64.dsc|  10 +-
>  OvmfPkg/OvmfPkgX64.dsc|  10 +-
>  OvmfPkg/OvmfPkgIa32.fdf   |  21 +-
>  OvmfPkg/OvmfPkgIa32X64.fdf|  21 +-
>  OvmfPkg/OvmfPkgX64.fdf|  21 +-
>  OvmfPkg/SioBusDxe/SioBusDxe.inf   |  54 ++
>  OvmfPkg/SioBusDxe/SioBusDxe.h | 332 +++
>  OvmfPkg/SioBusDxe/SioService.h| 221 +++
>  OvmfPkg/SioBusDxe/ComponentName.c | 167 ++
>  OvmfPkg/SioBusDxe/SioBusDxe.c | 622 
>  OvmfPkg/SioBusDxe/SioService.c| 405 +
>  OvmfPkg/SioBusDxe/SioBusDxe.uni   |  21 +
>  13 files changed, 1885 insertions(+), 30 deletions(-)
>  create mode 100644 OvmfPkg/SioBusDxe/SioBusDxe.inf
>  create mode 100644 OvmfPkg/SioBusDxe/SioBusDxe.h
>  create mode 100644 OvmfPkg/SioBusDxe/SioService.h
>  create mode 100644 OvmfPkg/SioBusDxe/ComponentName.c
>  create mode 100644 OvmfPkg/SioBusDxe/SioBusDxe.c
>  create mode 100644 OvmfPkg/SioBusDxe/SioService.c
>  create mode 100644 OvmfPkg/SioBusDxe/SioBusDxe.uni
> 

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

Re: [edk2] [PATCH v2 1/3] OvmfPkg: Drop the ISA Floppy device support

[Laszlo Ersek]

On 03/25/19 06:28, Hao Wu wrote:
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1495
> 
> There is a plan to remove the IntelFrameworkModulePkg:
> https://bugzilla.tianocore.org/show_bug.cgi?id=1605
> 
> And for driver:
> IntelFrameworkModulePkg/Bus/Isa/IsaFloppyDxe
> 
> This patch proposes to drop the ISA Floppy device support in OVMF.
> 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: Ray Ni 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Hao Wu 
> ---
>  OvmfPkg/OvmfPkgIa32.dsc| 3 +--
>  OvmfPkg/OvmfPkgIa32X64.dsc | 3 +--
>  OvmfPkg/OvmfPkgX64.dsc | 3 +--
>  OvmfPkg/OvmfPkgIa32.fdf| 3 +--
>  OvmfPkg/OvmfPkgIa32X64.fdf | 3 +--
>  OvmfPkg/OvmfPkgX64.fdf | 3 +--
>  6 files changed, 6 insertions(+), 12 deletions(-)
> 
> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> index 5b885590b2..1710ab5a88 100644
> --- a/OvmfPkg/OvmfPkgIa32.dsc
> +++ b/OvmfPkg/OvmfPkgIa32.dsc
> @@ -1,7 +1,7 @@
>  ## @file
>  #  EFI/Framework Open Virtual Machine Firmware (OVMF) platform
>  #
> -#  Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> +#  Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
>  #  (C) Copyright 2016 Hewlett Packard Enterprise Development LP
>  #
>  #  This program and the accompanying materials
> @@ -756,7 +756,6 @@
>IntelFrameworkModulePkg/Bus/Isa/IsaBusDxe/IsaBusDxe.inf
>IntelFrameworkModulePkg/Bus/Isa/IsaSerialDxe/IsaSerialDxe.inf
>IntelFrameworkModulePkg/Bus/Isa/Ps2KeyboardDxe/Ps2keyboardDxe.inf
> -  IntelFrameworkModulePkg/Bus/Isa/IsaFloppyDxe/IsaFloppyDxe.inf
>  
>#
># SMBIOS Support
> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
> index bbf0853ee6..5bceef3116 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
> @@ -1,7 +1,7 @@
>  ## @file
>  #  EFI/Framework Open Virtual Machine Firmware (OVMF) platform
>  #
> -#  Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> +#  Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
>  #  (C) Copyright 2016 Hewlett Packard Enterprise Development LP
>  #
>  #  This program and the accompanying materials
> @@ -765,7 +765,6 @@
>IntelFrameworkModulePkg/Bus/Isa/IsaBusDxe/IsaBusDxe.inf
>IntelFrameworkModulePkg/Bus/Isa/IsaSerialDxe/IsaSerialDxe.inf
>IntelFrameworkModulePkg/Bus/Isa/Ps2KeyboardDxe/Ps2keyboardDxe.inf
> -  IntelFrameworkModulePkg/Bus/Isa/IsaFloppyDxe/IsaFloppyDxe.inf
>  
>#
># SMBIOS Support
> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
> index d81460f520..3f5d948dbb 100644
> --- a/OvmfPkg/OvmfPkgX64.dsc
> +++ b/OvmfPkg/OvmfPkgX64.dsc
> @@ -1,7 +1,7 @@
>  ## @file
>  #  EFI/Framework Open Virtual Machine Firmware (OVMF) platform
>  #
> -#  Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> +#  Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
>  #  (C) Copyright 2016 Hewlett Packard Enterprise Development LP
>  #
>  #  This program and the accompanying materials
> @@ -763,7 +763,6 @@
>IntelFrameworkModulePkg/Bus/Isa/IsaBusDxe/IsaBusDxe.inf
>IntelFrameworkModulePkg/Bus/Isa/IsaSerialDxe/IsaSerialDxe.inf
>IntelFrameworkModulePkg/Bus/Isa/Ps2KeyboardDxe/Ps2keyboardDxe.inf
> -  IntelFrameworkModulePkg/Bus/Isa/IsaFloppyDxe/IsaFloppyDxe.inf
>  
>#
># SMBIOS Support
> diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
> index 4999403ad7..54d7f06a70 100644
> --- a/OvmfPkg/OvmfPkgIa32.fdf
> +++ b/OvmfPkg/OvmfPkgIa32.fdf
> @@ -1,7 +1,7 @@
>  ## @file
>  #  Open Virtual Machine Firmware: FDF
>  #
> -#  Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.
> +#  Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
>  #  (C) Copyright 2016 Hewlett Packard Enterprise Development LP
>  #
>  #  This program and the accompanying materials
> @@ -273,7 +273,6 @@ INF  
> IntelFrameworkModulePkg/Bus/Isa/IsaSerialDxe/IsaSerialDxe.inf
>  !endif
>  
>  INF  IntelFrameworkModulePkg/Bus/Isa/Ps2KeyboardDxe/Ps2keyboardDxe.inf
> -INF  IntelFrameworkModulePkg/Bus/Isa/IsaFloppyDxe/IsaFloppyDxe.inf
>  
>  INF  MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf
>  INF  OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.inf
> diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
> index d0cc107928..7519b53a9b 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.fdf
> +++ b/OvmfPkg/OvmfPkgIa32X64.fdf
> @@ -1,7 +1,7 @@
>  ## @file
>  #  Open Virtual Machine Firmware: FDF
>  #
> -#  Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.
> +#  Copyright (c) 2006 - 2019, Intel Corporation. Al

Re: [edk2] PATCH] Change EDK II to BSD+Patent License

[Laszlo Ersek]

On 03/23/19 01:44, Kinney, Michael D wrote:
> Hi Laszlo,
> 
> I have entered the following BZ for SPDX identifiers for 
> MIT licensed content in OvmfPkg. 
> 
> https://bugzilla.tianocore.org/show_bug.cgi?id=1654

Thank you!
Laszlo

>> -Original Message-----
>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>> Sent: Wednesday, March 20, 2019 5:10 AM
>> To: Lars Kurth ; Julien Grall
>> ; Kinney, Michael D
>> 
>> Cc: edk2-devel@lists.01.org; Ard Biesheuvel
>> ; Justen, Jordan L
>> ; Anthony Perard
>> ; Marc-André Lureau
>> ; Stefan Berger
>> 
>> Subject: Re: [edk2] PATCH] Change EDK II to BSD+Patent
>> License
>>
>> On 03/15/19 18:48, Lars Kurth wrote:
>>>
>>>
>>> On 15/03/2019, 10:18, "Julien Grall"
>>  wrote:
>>>
>>> >
>>> >  EDK2 is converting the full copyright in
>> each file to SDPX identifier. While the
>>> >  copyright looks like an MIT license, it has
>> never been confirmed. Andrew Cooper
>>> >  suggested you might be able to confirm.
>>> >
>>> > Is there a web-link to the files/repos such that
>> I don’t have to clone the repo
>>> > Lars
>>>
>>> Here an example of files from Xen public headers:
>>>
>>>
>> https://xenbits.xen.org/gitweb/?p=xen.git;a=tree;f=xen/in
>> clude/public;h=0618b0134d2b9babcba71a3f0f86be5a84468b50;h
>> b=HEAD
>>>
>>> OK, this makes this easy then. Because in all
>> likelihood, the files were copied from xen/include/public
>> and then the COPYING file
>> https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/in
>> clude/public/COPYING applies, which states that
>> everything in this directory is MIT, unless stated
>> otherwise in the file.
>>>
>>> So as long as someone confirms that the files in
>> OvmfPkg/Include came from xen/include/public, this is a
>> clear case of a MIT license
>>> If they are files from other directories in Xen, check
>> the COPYING file in the original directory (or if there
>> is none in the parent directory) and check the COPYING
>> file
>>>
>>> I am not so clear about where the files in XenBusDxe
>> came from, but the same principle applies.
>>>
>>> If someone groups these files by "original directory in
>> Xen" to File ... I am happy to do a final sanity check
>> and sign it off and/or deal with any unclear cases
>>
>> Replacing MIT license blocks with SPDX identifiers is
>> something we
>> should do later -- I think it's out of scope for Mike's
>> current patch
>> series, it's just something I noticed and pointed out for
>> the future,
>> while I was verifying the "license block -> SPDX ID"
>> replacements for
>> 2-BSDL (i.e., *not* MIT).
>>
>> Mike mentioned that he was going to file a number of
>> TianoCore BZs as a
>> result of the discussion in this thread. Mike, can you
>> please file one
>> for the MIT->SPDX "refactoring" (under OvmfPkg) as well?
>> If not, I can
>> file it myself later, I just wouldn't like us to end up
>> with duplicates.
>>
>> Once we have that separate BZ, we can discuss it in
>> isolation.
>>
>> Thanks
>> Laszlo

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

Re: [edk2] [PATCH v1 0/2] Ovmf: Stop using ISA drivers within IntelFrameworkModulePkg

[Laszlo Ersek]

On 03/22/19 10:41, Ard Biesheuvel wrote:
> On Fri, 22 Mar 2019 at 10:25, Laszlo Ersek  wrote:
>>
>> On 03/22/19 02:33, Wu, Hao A wrote:
>>>> -Original Message-----
>>>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>>>> Sent: Friday, March 22, 2019 3:04 AM
>>>> To: Ard Biesheuvel; Wu, Hao A
>>>> Cc: edk2-devel@lists.01.org; Justen, Jordan L; Ni, Ray
>>>> Subject: Re: [PATCH v1 0/2] Ovmf: Stop using ISA drivers within
>>>> IntelFrameworkModulePkg
>>>>
>>>> On 03/21/19 11:08, Ard Biesheuvel wrote:
>>>>> On Thu, 21 Mar 2019 at 07:44, Wu, Hao A  wrote:
>>>>>>
>>>>>>>>>
>>>>>>>>> Just a couple of notes from my side - I'm sure Laszlo will have a much
>>>>>>>>> longer list :-)
>>>>>>>>>
>>>>>>>>> - Dropping the floppy driver is fine with me.
>>>>>>>>> - What is OVMF specific about this driver? Is it only the hardcoded
>>>>>>>>> list of COM1/COM2/PS2 keyboard? If so, should we split this into a
>>>>>>>>> driver and a library class, where the driver lives in MdeModulePkg,
>>>>>>>>> and the library is implemented in the context of OVMF?
>>>>>>>>
>>>>>>>> Hello Ard,
>>>>>>>>
>>>>>>>> I think the special thing for this one is that:
>>>>>>>> For QEMU, it does not have a Super I/O (SIO) chip. While, as far as I
>>>>>>>> know, the SIO chip exists on other platforms. The driver proposed here
>>>>>>>> simulates the behavior of an SIO chip. IMO, if we find more platforms
>>>> that
>>>>>>>> do not have a SIO chip, we can convert the driver into a general one.
>>>>>>>>
>>>>>>>> Also, for the implementation of the services in the Super I/O protocol,
>>>>>>>> the proposed driver just does the minimal effort in order to support 
>>>>>>>> the
>>>>>>>> serial/PS2 keyboard.
>>>>>>>
>>>>>>> Here's why I'd like the majority of this driver to live under
>>>>>>> MdeModulePkg (for example through a lib class separation like Ard
>>>> suggests):
>>>>>>>
>>>>>>> Because then its maintenance would not be the responsibility of OvmfPkg
>>>>>>> maintainers.
>>>>>>>
>>>>>>> Consider, this driver is absolutely huge (1.5-2 kLOC), for doing "the
>>>>>>> minimal effort in order to support the serial/PS2 keyboard".
>>>>>>>
>>>>>>> The risk of regressions is extreme (the PS/2 keyboard is the default
>>>>>>> one, and if it breaks *subtly*, almost all users will be inconvenienced,
>>>>>>> but not necessarily soon enough for us to get reports about it *early*
>>>>>>> in the current development cycle).
>>>>>>>
>>>>>>> I realize that IntelFrameworkModulePkg/Bus/Isa/* drivers are frowned
>>>>>>> upon nowadays, they may be ugly / platform specific / etc etc etc, but
>>>>>>> they have also proved themselves to *work*, and (as far as I remember)
>>>>>>> they have required practically zero fixes in order to function well on 
>>>>>>> QEMU.
>>>>>>>
>>>>>>> It is very unwelcome by me to take on the maintenance burden for a
>>>>>>> driver that is all of:
>>>>>>> - not widely tested,
>>>>>>> - replacing a proven set of drivers that is critical to users,
>>>>>>> - large.
>>>>>>>
>>>>>>> I understand that Intel wants to stop maintaining
>>>>>>> IntelFrameworkModulePkg/Bus/Isa/*, but the above price is too high for
>>>> me.
>>>>>>>
>>>>>>> Compare the case if we simply moved the
>>>>>>> IntelFrameworkModulePkg/Bus/Isa/* drivers under OvmfPkg:
>>>>>>> - still large,
>>>>>>> - but widely tested (with minimal churn in the past),
>>>>>>> - and no risk of regressions.
>>>>>>>
>>>>>>> So in this form, I'm generally opposed to the switch. The two sets of
>>&g

Re: [edk2] [PATCH v1 0/2] Ovmf: Stop using ISA drivers within IntelFrameworkModulePkg

[Laszlo Ersek]

On 03/22/19 02:33, Wu, Hao A wrote:
>> -Original Message-
>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>> Sent: Friday, March 22, 2019 3:04 AM
>> To: Ard Biesheuvel; Wu, Hao A
>> Cc: edk2-devel@lists.01.org; Justen, Jordan L; Ni, Ray
>> Subject: Re: [PATCH v1 0/2] Ovmf: Stop using ISA drivers within
>> IntelFrameworkModulePkg
>>
>> On 03/21/19 11:08, Ard Biesheuvel wrote:
>>> On Thu, 21 Mar 2019 at 07:44, Wu, Hao A  wrote:
>>>>
>>>>>>>
>>>>>>> Just a couple of notes from my side - I'm sure Laszlo will have a much
>>>>>>> longer list :-)
>>>>>>>
>>>>>>> - Dropping the floppy driver is fine with me.
>>>>>>> - What is OVMF specific about this driver? Is it only the hardcoded
>>>>>>> list of COM1/COM2/PS2 keyboard? If so, should we split this into a
>>>>>>> driver and a library class, where the driver lives in MdeModulePkg,
>>>>>>> and the library is implemented in the context of OVMF?
>>>>>>
>>>>>> Hello Ard,
>>>>>>
>>>>>> I think the special thing for this one is that:
>>>>>> For QEMU, it does not have a Super I/O (SIO) chip. While, as far as I
>>>>>> know, the SIO chip exists on other platforms. The driver proposed here
>>>>>> simulates the behavior of an SIO chip. IMO, if we find more platforms
>> that
>>>>>> do not have a SIO chip, we can convert the driver into a general one.
>>>>>>
>>>>>> Also, for the implementation of the services in the Super I/O protocol,
>>>>>> the proposed driver just does the minimal effort in order to support the
>>>>>> serial/PS2 keyboard.
>>>>>
>>>>> Here's why I'd like the majority of this driver to live under
>>>>> MdeModulePkg (for example through a lib class separation like Ard
>> suggests):
>>>>>
>>>>> Because then its maintenance would not be the responsibility of OvmfPkg
>>>>> maintainers.
>>>>>
>>>>> Consider, this driver is absolutely huge (1.5-2 kLOC), for doing "the
>>>>> minimal effort in order to support the serial/PS2 keyboard".
>>>>>
>>>>> The risk of regressions is extreme (the PS/2 keyboard is the default
>>>>> one, and if it breaks *subtly*, almost all users will be inconvenienced,
>>>>> but not necessarily soon enough for us to get reports about it *early*
>>>>> in the current development cycle).
>>>>>
>>>>> I realize that IntelFrameworkModulePkg/Bus/Isa/* drivers are frowned
>>>>> upon nowadays, they may be ugly / platform specific / etc etc etc, but
>>>>> they have also proved themselves to *work*, and (as far as I remember)
>>>>> they have required practically zero fixes in order to function well on 
>>>>> QEMU.
>>>>>
>>>>> It is very unwelcome by me to take on the maintenance burden for a
>>>>> driver that is all of:
>>>>> - not widely tested,
>>>>> - replacing a proven set of drivers that is critical to users,
>>>>> - large.
>>>>>
>>>>> I understand that Intel wants to stop maintaining
>>>>> IntelFrameworkModulePkg/Bus/Isa/*, but the above price is too high for
>> me.
>>>>>
>>>>> Compare the case if we simply moved the
>>>>> IntelFrameworkModulePkg/Bus/Isa/* drivers under OvmfPkg:
>>>>> - still large,
>>>>> - but widely tested (with minimal churn in the past),
>>>>> - and no risk of regressions.
>>>>>
>>>>> So in this form, I'm generally opposed to the switch. The two sets of
>>>>> drivers need to coexist for a while, and we must expose the new drivers
>>>>> to users while providing them with some sort of easy fallback. (I'd
>>>>> prefer that fallback to be dynamically configurable, but, again, if your
>>>>> keyboard breaks, how do you interact with e.g. the UEFI shell? So I
>>>>> guess a static build flag would do as well.) I think the old drivers
>>>>
>>>> Hello Laszlo,
>>>>
>>>> I agree with your point. So your suggestion is to:
>>>>
>>>> 1. Duplicate the below drivers into OvmfPkg:
>>>>   PcAtChipsetPkg/IsaAcpiDxe/IsaAcpi.inf
>>>

Re: [edk2] [Xen-devel] [PATCH RESEND 1/3] OvmfPkg/XenSupport: remove usage of prefetchable PCI host bridge aperture

[Laszlo Ersek]

On 03/22/19 09:33, Roger Pau Monné wrote:
> On Wed, Mar 06, 2019 at 12:40:54PM +, Igor Druzhinin wrote:
>> This aperture doesn't exist in OVMF and trying to use it causes
>> failing assertions later in cases there are prefetchable and
>> non-prefetchable BARs following each other. This configuration is
>> quite likely with some PCI passthrough devices.
> 
> According to the PCIe spec, it's fine to place prefetchable BARs in
> non-prefetchable memory space. There's a note that says that most
> implementations will only have 1G of non-prefetchable memory, and
> that most scalable platforms will map 32bit BARs into
> non-prefetchable memory regardless of the prefetchable bit value.
> 
> Shouldn't OVMF be fine with finding both prefetchable and
> non-prefetchable BARs, as long as the memory region is set to
> non-prefetchable?
> 
> Does OVMF have the capability to position BARs by itself? If so we
> could skip of the placement done by hvmloader and just let OVMF
> position things where it see fit.

The core PciBusDxe driver that is built into OVMF certainly does the
resource allocation/placement, but when OVMF is executed on Xen, this
functionality of PciBusDxe is dynamically disabled by setting
PcdPciDisableBusEnumeration to TRUE. (I'm not saying this is right vs.
wrong, just that it happens.)

Note that OVMF itself checks PcdPciDisableBusEnumeration for many things
(just grep OvmfPkg to see), so if we were to flip the PCD while running
on Xen, it would change the behavior of OVMF on Xen in a number of
areas. Can't offer a deeper treatise for now; all the related source
code locations would have to be audited (likely with "git blame" too).

Now, if PciBusDxe *is* allowed/requested to lay out the BARs, through
the PCD, then it (indirectly) depends on platform code to provide the
resource apertures -- of the root bridges -- out of which it can
allocate the BARs. My understanding is that XenSupport.c tries to detect
these apertures "retroactively", from the pre-existing BAR placements.
This was contributed by Ray in commit 49effaf26ec9
("OvmfPkg/PciHostBridgeLib: Scan for root bridges when running over
Xen", 2016-05-11), so I'll have to defer to him on the code.

I believe that, if we flipped the PCD to FALSE on Xen, and hvmloader
would stop pre-configuring the BARs (or OVMF would simply ignore that
pre-config), then this code (XenSupport.c) should be possible to
eliminate -- *however*, in that case, some other Xen-specific code would
become necessary, to expose the root bridge resource apertures (out of
which BARs should be allocated by PciBusDxe, see above).

In QEMU's case: all root bridges share the same apertures between each
other (given any specific resource type). They are communicated via
dynamic PCDs. The 32-bit MMIO aperture PCDs are set in PlatformPei
somewhat simply (based on QEMU machine type, IIRC). The 64-bit MMIO
aperture PCDs are also calculated in PlatformPei, but that calculation
is a *lot* more complex.

All in all, the "root" information is the set of apertures, i.e. what
parts of the GPA space can be used for what resource allocation.

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

Re: [edk2] [PATCH 2/3] Maintainers.txt: Remove EdkCompatibilityPkg information

[Laszlo Ersek]

On 03/22/19 07:32, Gao, Liming wrote:
> Reviewed-by: Liming Gao 

Reviewed-by: Laszlo Ersek 

Thanks
Laszlo

>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Shenglei Zhang
>> Sent: Friday, March 22, 2019 10:35 AM
>> To: edk2-devel@lists.01.org
>> Cc: Kinney, Michael D ; Laszlo Ersek
>> 
>> Subject: [edk2] [PATCH 2/3] Maintainers.txt: Remove EdkCompatibilityPkg
>> information
>>
>> EdkCompatibilityPkg will be deleted from edk2/master.
>> So update the maintainer information of EdkCompatibilityPkg.
>> https://bugzilla.tianocore.org/show_bug.cgi?id=1103
>>
>> Cc: Andrew Fish 
>> Cc: Laszlo Ersek 
>> Cc: Leif Lindholm 
>> Cc: Michael D Kinney 
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Shenglei Zhang 
>> ---
>> Maintainers.txt | 4 
>> 1 file changed, 4 deletions(-)
>>
>> diff --git a/Maintainers.txt b/Maintainers.txt
>> index be77898ee2..e090df7c17 100644
>> --- a/Maintainers.txt
>> +++ b/Maintainers.txt
>> @@ -115,10 +115,6 @@ W:
>> https://github.com/tianocore/tianocore.github.io/wiki/DynamicTablesPkg
>> M: Sami Mujawar 
>> M: Alexei Fedorov 
>>
>> -EdkCompatibilityPkg
>> -W:
>> https://github.com/tianocore/tianocore.github.io/wiki/EdkCompatibilityPkg
>> -M: Liming Gao 
>> -
>> EmbeddedPkg
>> W: https://github.com/tianocore/tianocore.github.io/wiki/EmbeddedPkg
>> M: Leif Lindholm 
>> --
>> 2.18.0.windows.1
>>
>> ___
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel

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

Re: [edk2] [PATCH v1 0/2] Ovmf: Stop using ISA drivers within IntelFrameworkModulePkg

[Laszlo Ersek]

On 03/21/19 11:08, Ard Biesheuvel wrote:
> On Thu, 21 Mar 2019 at 07:44, Wu, Hao A  wrote:
>>
>
> Just a couple of notes from my side - I'm sure Laszlo will have a much
> longer list :-)
>
> - Dropping the floppy driver is fine with me.
> - What is OVMF specific about this driver? Is it only the hardcoded
> list of COM1/COM2/PS2 keyboard? If so, should we split this into a
> driver and a library class, where the driver lives in MdeModulePkg,
> and the library is implemented in the context of OVMF?

 Hello Ard,

 I think the special thing for this one is that:
 For QEMU, it does not have a Super I/O (SIO) chip. While, as far as I
 know, the SIO chip exists on other platforms. The driver proposed here
 simulates the behavior of an SIO chip. IMO, if we find more platforms that
 do not have a SIO chip, we can convert the driver into a general one.

 Also, for the implementation of the services in the Super I/O protocol,
 the proposed driver just does the minimal effort in order to support the
 serial/PS2 keyboard.
>>>
>>> Here's why I'd like the majority of this driver to live under
>>> MdeModulePkg (for example through a lib class separation like Ard suggests):
>>>
>>> Because then its maintenance would not be the responsibility of OvmfPkg
>>> maintainers.
>>>
>>> Consider, this driver is absolutely huge (1.5-2 kLOC), for doing "the
>>> minimal effort in order to support the serial/PS2 keyboard".
>>>
>>> The risk of regressions is extreme (the PS/2 keyboard is the default
>>> one, and if it breaks *subtly*, almost all users will be inconvenienced,
>>> but not necessarily soon enough for us to get reports about it *early*
>>> in the current development cycle).
>>>
>>> I realize that IntelFrameworkModulePkg/Bus/Isa/* drivers are frowned
>>> upon nowadays, they may be ugly / platform specific / etc etc etc, but
>>> they have also proved themselves to *work*, and (as far as I remember)
>>> they have required practically zero fixes in order to function well on QEMU.
>>>
>>> It is very unwelcome by me to take on the maintenance burden for a
>>> driver that is all of:
>>> - not widely tested,
>>> - replacing a proven set of drivers that is critical to users,
>>> - large.
>>>
>>> I understand that Intel wants to stop maintaining
>>> IntelFrameworkModulePkg/Bus/Isa/*, but the above price is too high for me.
>>>
>>> Compare the case if we simply moved the
>>> IntelFrameworkModulePkg/Bus/Isa/* drivers under OvmfPkg:
>>> - still large,
>>> - but widely tested (with minimal churn in the past),
>>> - and no risk of regressions.
>>>
>>> So in this form, I'm generally opposed to the switch. The two sets of
>>> drivers need to coexist for a while, and we must expose the new drivers
>>> to users while providing them with some sort of easy fallback. (I'd
>>> prefer that fallback to be dynamically configurable, but, again, if your
>>> keyboard breaks, how do you interact with e.g. the UEFI shell? So I
>>> guess a static build flag would do as well.) I think the old drivers
>>
>> Hello Laszlo,
>>
>> I agree with your point. So your suggestion is to:
>>
>> 1. Duplicate the below drivers into OvmfPkg:
>>   PcAtChipsetPkg/IsaAcpiDxe/IsaAcpi.inf
>>   IntelFrameworkModulePkg/Bus/Isa/IsaBusDxe/IsaBusDxe.inf
>>   IntelFrameworkModulePkg/Bus/Isa/IsaSerialDxe/IsaSerialDxe.inf
>>   IntelFrameworkModulePkg/Bus/Isa/Ps2KeyboardDxe/Ps2keyboardDxe.inf
>>
>> 2. Meanwhile, add the proposed SioBusDxe driver in the OvmfPkg as well
>>
>> 3. Add a static build flag within OvmfPkg to let users choose between:
>>a) New OVMF SioBusDxe driver + ISA device drivers under
>>   MdeModulePkg/Bus/Isa;
>>b) Legacy ISA stack copied from PcAtChipsetPkg & IntelFrameworkModulePkg
>>
>> Is my understanding correct?

Yes (but see below, at the end).

>>> should be removed only in the edk2 stable tag that comes *after* the
>>> next one, once we've given the drivers enough time to "prove themselves".
>>
>> Do you mean we should keep the copy of the legacy ISA stack from
>> PcAtChipsetPkg & IntelFrameworkModulePkg until the announcement of
>> edk2-stable201905 tag?

Yes, exactly. People that adopt "edk2-stable201905" should be able to
switch back to the old driver stack.

NB: I certainly agree that the new code should be made the *default*.

>>
> 
> I think we should just keep the IntelFrameworkModulePkg components in
> place until we are ready to stop using them in OVMF. Cloning them into
> OvmfPkg now just so we can remove IntelFrameworkModulePkg in its
> entirety has little added value IMO.

I fully agree with this modification (it minimizes the churn), but I'm
unsure how quickly Intel would like to rid themselves of
IntelFrameworkModulePkg. If their deadline is edk2-stable201905, then
that conflicts with my request above, and we might have no choice in
moving the code to OvmfPkg, for the sake of one more stable tag.

Thanks
Laszlo

Re: [edk2] [PATCH V4 09/17] OvmfPkg/PlatformDebugLibIoPort: Add new APIs

[Laszlo Ersek]

On 03/21/19 15:04, Zhichao Gao wrote:
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1395
> 
> Add new APIs' implementation (DebugVPrint, DebugBPrint)
> in the DebugLib instance. These APIs would expose print
> routines with VaList parameter and BaseList parameter.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Zhichao Gao 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: Liming Gao 
> Cc: Sean Brogan 
> Cc: Michael Turner 
> Cc: Bret Barkelew 
> ---
>  OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c | 106 
> +-
>  1 file changed, 101 insertions(+), 5 deletions(-)

This v4 patch is identical to v3.

When you repost a series in order to update a subset of the patches, you
should please pick up the feedback tags from the previous review session
for those patches that you do *not* change.

This is explained here, for example:

https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-guide-for-edk2-contributors-and-maintainers#contrib-26

https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-guide-for-edk2-contributors-and-maintainers#contrib-28

This makes a huge difference for reviewers -- it costs you a bit of
time, but it saves reviewers a lot more time.

For example, the present patch has not been changed from v3 to v4, and I
gave my A-b in the v3 review session. Therefore you should have edited
the commit message on this patch, to include my A-b, for the v4 posting.

Either way, I can give it again here.

Acked-by: Laszlo Ersek 

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

Re: [edk2] PATCH] Change EDK II to BSD+Patent License

[Laszlo Ersek]

On 03/21/19 13:04, Lars Kurth wrote:
> 
> 
> On 20/03/2019, 18:25, "Laszlo Ersek"  wrote:
> 
> But, again, this should be discussed in that separate BZ then.
> 
> > >OvmfPkg/XenBusDxe/XenBus.c
> 
> This file is licensed under the BSD license, aka 
> https://opensource.org/licenses/bsd-license.php
> 
> > >OvmfPkg/XenBusDxe/XenStore.c
> > >OvmfPkg/XenBusDxe/XenStore.h
> >I do not know where these files come from. The files do not appear to 
> come from a Xen project repo. 
> 
> See commit a9090a94bb4a ("OvmfPkg/XenBusDxe: Add XenStore client
> implementation", 2014-10-29), by Anthony.
> 
> https://github.com/tianocore/edk2/commit/a9090a94bb4a
> 
> The commit message states,
> 
> >Origin: FreeBSD 10.0
> >License: This patch adds several files under the MIT licence.
> 
> >So, unless you trust that the license in the headers are correct, the 
> right thing would be to identify the source and check whether the license 
> text has been imported unmodified
> 
> We do trust that the license blocks, as they exist, are correct. Where
> we need help & support is the mapping/replacement of those verbose
> license blocks to/with SPDX-License-Identifier tags.
> 
> As I now understand what is needed, I had a look at the XenStore.* licenses. 
> They are NOT a standard MIT license
> 
> The sources say:
> "Permission is hereby granted, free of charge, to any person obtaining a copy 
> of this source file (the "Software")"
> The MIT license says
> "Permission is hereby granted, free of charge, to any person obtaining a copy 
> of this software and associated documentation files (the "Software")"
> 
> I would argue that replacing "source file" with "software and associated 
> documentation files" is probably OK, but I am not an expert. I am pretty sure 
> this type of issue has come up before when migrating to SPDX. It might be 
> worthwhile reaching out to someone from SPDX.
> 
> Hope this helped

Thank you! We'll revisit this issue (and thread, I assume) later on.

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

Re: [edk2] PATCH] Change EDK II to BSD+Patent License

[Laszlo Ersek]

On 03/20/19 19:42, Julien Grall wrote:
> Hi,
> 
> On 20/03/2019 18:25, Laszlo Ersek wrote:
>> On 03/20/19 14:03, Lars Kurth wrote:
>>> On 15/03/2019, 17:48, "Lars Kurth"  wrote:
>>>  On 15/03/2019, 10:18, "Julien Grall"  wrote:
>>> Is the issue that you don’t trust that the license specified in the
>>> files are correct?
>>
>> No -- the question is whether the license included in the files
>> mentioned is indeed the MIT license, suitable for a replacement with the
>> appropriate SPDX license ID.
>>
>>>
>>>  > (2.2.2) Files that seem to be covered by the MIT license.
>>>  >
>>>  >    OvmfPkg/Include/IndustryStandard/Xen/arch-arm/xen.h
>>>
>>> I can't identify where in the Xen tree this file came from. There is
>>> no corresponding xen.h file in the Xen tree at [xen.git] / xen /
>>> include / public / arch-arm /
>>> @Julien, @Anthony: can you clarify
>>
>> This file was first added to edk2 in b94c3ac93d57 ("Ovmf/Xen: implement
>> XenHypercallLib for ARM", 2015-02-28).
> 
> It is a copy of public/arch-arm.h. Somehow all the other projects
> created the file under arch-arm/xen.h.
> 
>>
>> https://github.com/tianocore/edk2/commit/b94c3ac93d57
>>
>> And from the Xen project (I think), it was Reviewed-by: Stefano
>> Stabellini . (I vaguely recall that
>> Stefano's emai has changed since.)
> 
> That's correct. He is working for Xilinx now.
> 
>>
>>>
>>>  >   
>>> OvmfPkg/Include/IndustryStandard/Xen/arch-x86/xen-x86_32.h
>>>  >   
>>> OvmfPkg/Include/IndustryStandard/Xen/arch-x86/xen-x86_64.h
>>>  >    OvmfPkg/Include/IndustryStandard/Xen/arch-x86/xen.h
>>>  >    OvmfPkg/Include/IndustryStandard/Xen/event_channel.h
>>>  >    OvmfPkg/Include/IndustryStandard/Xen/grant_table.h
>>>  >    OvmfPkg/Include/IndustryStandard/Xen/hvm/hvm_op.h
>>>  >    OvmfPkg/Include/IndustryStandard/Xen/hvm/params.h
>>>  >    OvmfPkg/Include/IndustryStandard/Xen/io/blkif.h
>>>  >    OvmfPkg/Include/IndustryStandard/Xen/io/console.h
>>>  >    OvmfPkg/Include/IndustryStandard/Xen/io/protocols.h
>>>  >    OvmfPkg/Include/IndustryStandard/Xen/io/ring.h
>>>  >    OvmfPkg/Include/IndustryStandard/Xen/io/xenbus.h
>>>  >    OvmfPkg/Include/IndustryStandard/Xen/io/xs_wire.h
>>>  >    OvmfPkg/Include/IndustryStandard/Xen/memory.h
>>>  >    OvmfPkg/Include/IndustryStandard/Xen/xen-compat.h
>>>  >    OvmfPkg/Include/IndustryStandard/Xen/xen.h
>>>
>>> These all appear to originate from [xen.git] / xen / include / public
>>> In the Xen tree these all have explicit MIT licenses, which implies
>>> that the license headers are indeed correct.
>>
>> Thanks -- so can we replace the license blocks with
>>
>>    SPDX-License-Identifier: MIT
>>
>> ? (See e.g. <https://spdx.org/ids-how>.)
> 
> I spoke with Lars today, this identifier would be suitable for the headers.
> 
> Cheers,
> 

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

Re: [edk2] PATCH] Change EDK II to BSD+Patent License

[Laszlo Ersek]

On 03/20/19 14:03, Lars Kurth wrote:
> 
> 
> On 15/03/2019, 17:48, "Lars Kurth"  wrote:
> 
> 
> 
> On 15/03/2019, 10:18, "Julien Grall"  wrote:
> 
> >  
> >  EDK2 is converting the full copyright in each file to SDPX 
> identifier. While the
> >  copyright looks like an MIT license, it has never been 
> confirmed. Andrew Cooper
> >  suggested you might be able to confirm.
> >  
> > Is there a web-link to the files/repos such that I don’t have to 
> clone the repo
> > Lars
> 
> Here an example of files from Xen public headers:
> 
> 
> https://xenbits.xen.org/gitweb/?p=xen.git;a=tree;f=xen/include/public;h=0618b0134d2b9babcba71a3f0f86be5a84468b50;hb=HEAD
> 
> OK, this makes this easy then. Because in all likelihood, the files were 
> copied from xen/include/public and then the COPYING file 
> https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/include/public/COPYING 
> applies, which states that everything in this directory is MIT, unless stated 
> otherwise in the file. 
> 
> So as long as someone confirms that the files in OvmfPkg/Include came 
> from xen/include/public, this is a clear case of a MIT license
> If they are files from other directories in Xen, check the COPYING file 
> in the original directory (or if there is none in the parent directory) and 
> check the COPYING file
> 
> I am not so clear about where the files in XenBusDxe came from, but the 
> same principle applies. 
> 
> If someone groups these files by "original directory in Xen" to File ... 
> I am happy to do a final sanity check and sign it off and/or deal with any 
> unclear cases
> 
> Nobody stepped up, sigh.

Sorry, no capacity. I suggested to handle this in a separate TianoCore
BZ, with much more focused context. I asked Mike to file that BZ (he had
offered earlier, if I understood correctly), or else to notify me to
file it.

> I am also VERY confused by this thread. 

Not surprising -- this is a side topic in the thread we're in.

> Is the issue that you don’t trust that the license specified in the files are 
> correct?

No -- the question is whether the license included in the files
mentioned is indeed the MIT license, suitable for a replacement with the
appropriate SPDX license ID.

> 
> > (2.2.2) Files that seem to be covered by the MIT license.
> > 
> >OvmfPkg/Include/IndustryStandard/Xen/arch-arm/xen.h
> 
> I can't identify where in the Xen tree this file came from. There is no 
> corresponding xen.h file in the Xen tree at [xen.git] / xen / include / 
> public / arch-arm /
> @Julien, @Anthony: can you clarify

This file was first added to edk2 in b94c3ac93d57 ("Ovmf/Xen: implement
XenHypercallLib for ARM", 2015-02-28).

https://github.com/tianocore/edk2/commit/b94c3ac93d57

And from the Xen project (I think), it was Reviewed-by: Stefano
Stabellini . (I vaguely recall that
Stefano's emai has changed since.)

> 
> >OvmfPkg/Include/IndustryStandard/Xen/arch-x86/xen-x86_32.h
> >OvmfPkg/Include/IndustryStandard/Xen/arch-x86/xen-x86_64.h
> >OvmfPkg/Include/IndustryStandard/Xen/arch-x86/xen.h
> >OvmfPkg/Include/IndustryStandard/Xen/event_channel.h
> >OvmfPkg/Include/IndustryStandard/Xen/grant_table.h
> >OvmfPkg/Include/IndustryStandard/Xen/hvm/hvm_op.h
> >OvmfPkg/Include/IndustryStandard/Xen/hvm/params.h
> >OvmfPkg/Include/IndustryStandard/Xen/io/blkif.h
> >OvmfPkg/Include/IndustryStandard/Xen/io/console.h
> >OvmfPkg/Include/IndustryStandard/Xen/io/protocols.h
> >OvmfPkg/Include/IndustryStandard/Xen/io/ring.h
> >OvmfPkg/Include/IndustryStandard/Xen/io/xenbus.h
> >OvmfPkg/Include/IndustryStandard/Xen/io/xs_wire.h
> >OvmfPkg/Include/IndustryStandard/Xen/memory.h
> >OvmfPkg/Include/IndustryStandard/Xen/xen-compat.h
> >OvmfPkg/Include/IndustryStandard/Xen/xen.h
> 
> These all appear to originate from [xen.git] / xen / include / public
> In the Xen tree these all have explicit MIT licenses, which implies that the 
> license headers are indeed correct.

Thanks -- so can we replace the license blocks with

  SPDX-License-Identifier: MIT

? (See e.g. .)

But, again, this should be discussed in that separate BZ then.

> 
> >OvmfPkg/XenBusDxe/XenBus.c
> >OvmfPkg/XenBusDxe/XenStore.c
> >OvmfPkg/XenBusDxe/XenStore.h
> 
> I do not know where these files come from. The files do not appear to come 
> from a Xen project repo. 

See commit a9090a94bb4a ("OvmfPkg/XenBusDxe: Add XenStore client
implementation", 2014-10-29), by Anthony.

https://github.com/tianocore/edk2/commit/a9090a94bb4a

The commit message states,

> 

Re: [edk2] [RFC 0/3] Enable runtime serial debug for ArmVirtQemu

[Laszlo Ersek]

On 03/20/19 13:16, Heyi Guo wrote:
> 
> 
> On 2019/3/20 17:55, Laszlo Ersek wrote:

>> If we don't have to flatten a ridiculous amount of other library code
>> into the RuntimePrepare() function, I think such flattening would be a
>> viable approach. We've run into this constructor loop several times
>> before, and -- if I remember correctly anyway! -- one approach has been
>> to declare SerialPortLib the "lowest level abstraction", and make the
>> affected lib instance self-contained.

> In my RFC, we need to use gDS which is from
> DxeServicesTableLib->EfiGetSystemConfigurationTable()->UefiLib, so that
> we need to flatten EfiGetSystemConfigurationTable().

I think that's acceptable.

> And
> gDS->SetMemorySpaceAttributes() actually relies on
> gEfiCpuArchProtocolGuid or it will return EFI_NOT_AVAILABLE_YET.

This is a valid dependency (even the PI spec spells it out). The way to
deal with it is to add gEfiCpuArchProtocolGuid to the DEPEX section of
the INF file -- this is possible for INF files of library instances as
well, but you have to be careful about module types. Please see the INF
spec on that.

Once you do this, modules linked against the lib instance will inherit
the lib instance's DEPEX, and "and it" together with the rest of their
DEPEX. IOW using the library will delay the containing driver module
until the CPU Arch protocol is available in the protocol database.

Then the constructor can rely on the related DXE services.

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

Re: [edk2] [PATCH V3 09/17] OvmfPkg/PlatformDebugLibIoPort: Add new APIs

[Laszlo Ersek]

On 03/19/19 16:25, Zhichao Gao wrote:
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1395
> 
> Add new APIs' implementation (DebugVPrint, DebugBPrint)
> in the DebugLib instance. These APIs would expose print
> routines with VaList parameter and BaseList parameter.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Zhichao Gao 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: Liming Gao 
> Cc: Sean Brogan 
> Cc: Michael Turner 
> Cc: Bret Barkelew 
> ---
>  OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c | 106 
> +-
>  1 file changed, 101 insertions(+), 5 deletions(-)
> 
> diff --git a/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c 
> b/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c
> index 36cde54976..cda35faf66 100644
> --- a/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c
> +++ b/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c
> @@ -2,7 +2,7 @@
>Base Debug library instance for QEMU debug port.
>It uses PrintLib to send debug messages to a fixed I/O port.
>  
> -  Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.
> +  Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
>Copyright (c) 2012, Red Hat, Inc.
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the BSD 
> License
> @@ -29,6 +29,12 @@
>  //
>  #define MAX_DEBUG_MESSAGE_LENGTH  0x100
>  
> +//
> +// VA_LIST can not initialize to NULL for all compiler, so we use this to
> +// indicate a null VA_LIST
> +//
> +VA_LIST mVaListNull;
> +
>  /**
>Prints a debug message to the debug output device if the specified error 
> level is enabled.
>  
> @@ -51,9 +57,41 @@ DebugPrint (
>IN  CONST CHAR8  *Format,
>...
>)
> +{
> +  VA_LIST Marker;
> +
> +  VA_START (Marker, Format);
> +  DebugVPrint (ErrorLevel, Format, Marker);
> +  VA_END (Marker);
> +}
> +
> +
> +/**
> +  Prints a debug message to the debug output device if the specified
> +  error level is enabled base on Null-terminated format string and a
> +  VA_LIST argument list or a BASE_LIST argument list.
> +
> +  If any bit in ErrorLevel is also set in DebugPrintErrorLevelLib function
> +  GetDebugPrintErrorLevel (), then print the message specified by Format and
> +  the associated variable argument list to the debug output device.
> +
> +  If Format is NULL, then ASSERT().
> +
> +  @param  ErrorLevel  The error level of the debug message.
> +  @param  Format  Format string for the debug message to print.
> +  @param  VaListMarkerVA_LIST marker for the variable argument list.
> +  @param  BaseListMarker  BASE_LIST marker for the variable argument list.
> +
> +**/
> +VOID
> +DebugPrintMarker (
> +  IN  UINTN ErrorLevel,
> +  IN  CONST CHAR8   *Format,
> +  IN  VA_LIST   VaListMarker,
> +  IN  BASE_LIST BaseListMarker
> +  )
>  {
>CHAR8Buffer[MAX_DEBUG_MESSAGE_LENGTH];
> -  VA_LIST  Marker;
>UINTNLength;
>  
>//
> @@ -72,9 +110,11 @@ DebugPrint (
>//
>// Convert the DEBUG() message to an ASCII String
>//
> -  VA_START (Marker, Format);
> -  Length = AsciiVSPrint (Buffer, sizeof (Buffer), Format, Marker);
> -  VA_END (Marker);
> +  if (BaseListMarker == NULL) {
> +Length = AsciiVSPrint (Buffer, sizeof (Buffer), Format, VaListMarker);
> +  } else {
> +Length = AsciiBSPrint (Buffer, sizeof (Buffer), Format, BaseListMarker);
> +  }
>  
>//
>// Send the print string to the debug I/O port
> @@ -83,6 +123,62 @@ DebugPrint (
>  }
>  
>  
> +/**
> +  Prints a debug message to the debug output device if the specified
> +  error level is enabled.
> +
> +  If any bit in ErrorLevel is also set in DebugPrintErrorLevelLib function
> +  GetDebugPrintErrorLevel (), then print the message specified by Format and
> +  the associated variable argument list to the debug output device.
> +
> +  If Format is NULL, then ASSERT().
> +
> +  @param  ErrorLevelThe error level of the debug message.
> +  @param  FormatFormat string for the debug message to print.
> +  @param  VaListMarker  VA_LIST marker for the variable argument list.
> +
> +**/
> +VOID
> +EFIAPI
> +DebugVPrint (
> +  IN  UINTN ErrorLevel,
> +  IN  CONST CHAR8   *Format,
> +  IN  VA_LIST   VaListMarker
> +  )
> +{
> +  DebugPrintMarker (ErrorLevel, Format, VaListMarker, NULL);
> +}
> +
> +
> +/**
> +  Prints a debug message to the debug output device if the specified
> +  error level is enabled.
> +  This functio

Re: [edk2] [PATCH v4] UefiCpuPkg\CpuSmm: Save & restore CR2 on-demand paging in SMM

[Laszlo Ersek]

On 03/18/19 15:38, nkvangup wrote:
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1593
> 
> For every SMI occurrence, save and restore CR2 register only when SMM
> on-demand paging support is enabled in 64 bit operation mode.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Vanguput Narendra K 
> Cc: Eric Dong 
> Cc: Ray Ni 
> Cc: Laszlo Ersek 
> Cc: Yao Jiewen 
> ---
>  UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c   | 22 ++
>  UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c |  2 +-
>  2 files changed, 15 insertions(+), 9 deletions(-)
> 
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> index 3b0b3b52ac..0c07b31c4f 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> @@ -28,6 +28,7 @@ UINTN   mSemaphoreSize;
>  SPIN_LOCK   *mPFLock = NULL;
>  SMM_CPU_SYNC_MODE   mCpuSmmSyncMode;
>  BOOLEAN mMachineCheckSupported = FALSE;
> +BOOLEAN mCpuSmmStaticPageTable = TRUE;

Hmmm. This change is a bit daring, but I think it could be valid.

- In the IA32 build, mCpuSmmStaticPageTable would never be modified, or
read, by *preexistent* code (because all that code is in X64/PageTbl.c).
And the new code, added by this patch, would (presumably) work fine,
with the initial TRUE value.

- In the X64 build, the preexistent code would never read the initial
value (which we now set to TRUE here), i.e. before overwriting the
variable from the PCD -- because that would mean a bug in the
preexistent code. (Well, unless that code relied on the zero initial
value of the variable).

(1) I think I'd like to defer on this to other UefiCpuPkg reviewers.
Honestly I find this style questionable. It makes me feel uncomfortable.
I'd prefer the new APIs with the separate IA32/X64 implementations that
I suggested in my v2 review. But if other reviewers like this one
better, I won't mind.

(After hearing their opinions, I'd attempt to find the time to
regression test the patch (or maybe v5), too.)

Assuming other reviewers prefer this approach over my suggestion, I have
some other comments:

>  
>  /**
>Performs an atomic compare exchange operation to get semaphore.
> @@ -,10 +1112,13 @@ SmiRendezvous (
>  
>ASSERT(CpuIndex < mMaxNumberOfCpus);
>  
> -  //
> -  // Save Cr2 because Page Fault exception in SMM may override its value
> -  //
> -  Cr2 = AsmReadCr2 ();
> +if (!mCpuSmmStaticPageTable) {
> +//
> +// Save and restore Cr2 when using on-demand paging for above 4G memory 
> because Page Fault
> +// exception in SMM may override its value
> +//
> +Cr2 = AsmReadCr2 ();
> +  }

(2) The indentation of the "if" is broken.

(3) Given that we're already using two comment lines, I'd suggest not
exceeding 80 characters per line.

>  
>//
>// Perform CPU specific entry hooks
> @@ -1253,10 +1257,12 @@ SmiRendezvous (
>  
>  Exit:
>SmmCpuFeaturesRendezvousExit (CpuIndex);
> -  //
> -  // Restore Cr2
> -  //
> -  AsmWriteCr2 (Cr2);
> +if (!mCpuSmmStaticPageTable) {

(4) same as (2).

> +//
> +// Restore Cr2
> +//
> +AsmWriteCr2 (Cr2);
> +  }
>  }
>  
>  /**
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
> index 2c77cb47a4..e444b8a031 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
> @@ -21,7 +21,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
> EXPRESS OR IMPLIED.
>  
>  LIST_ENTRY  mPagePool = 
> INITIALIZE_LIST_HEAD_VARIABLE (mPagePool);
>  BOOLEAN m1GPageTableSupport = FALSE;
> -BOOLEAN mCpuSmmStaticPageTable;
> +extern BOOLEAN  mCpuSmmStaticPageTable;

(5) This is generally not great style, and it conflicts with the
existent code of this driver. Namely, declarations of variables with
file scope, static storage duration, and external linkage, should go
into "PiSmmCpuDxeSmm.h"-- we already got a bunch of them there.

Thanks
Laszlo

>  
>  /**
>Disable CET.
> 

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

Re: [edk2] [PATCH V2 09/17] OvmfPkg/PlatformDebugLibIoPort: Add a new api DebugVPrint

[Laszlo Ersek]

On 03/15/19 06:17, Zhichao Gao wrote:
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1395
> 
> Add a new api DebugVPrint implementation in the
> DebugLib instance. This api would expose a print
> routine with VaList parameter.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Zhichao Gao 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: Liming Gao 
> Cc: Sean Brogan 
> Cc: Michael Turner 
> Cc: Bret Barkelew 
> ---
>  OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c | 38 
> ---
>  1 file changed, 33 insertions(+), 5 deletions(-)
> 
> diff --git a/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c 
> b/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c
> index 36cde54976..74013c28a2 100644
> --- a/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c
> +++ b/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c
> @@ -2,7 +2,7 @@
>Base Debug library instance for QEMU debug port.
>It uses PrintLib to send debug messages to a fixed I/O port.
>  
> -  Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.
> +  Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
>Copyright (c) 2012, Red Hat, Inc.
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the BSD 
> License
> @@ -51,9 +51,38 @@ DebugPrint (
>IN  CONST CHAR8  *Format,
>...
>)
> +{
> +  VA_LIST Marker;
> +
> +  VA_START (Marker, Format);
> +  DebugVPrint (ErrorLevel, Format, Marker);
> +  VA_END (Marker);
> +}
> +
> +
> +/**
> +  Prints a debug message to the debug output device if the specified error 
> level is enabled.
> +
> +  If any bit in ErrorLevel is also set in DebugPrintErrorLevelLib function
> +  GetDebugPrintErrorLevel (), then print the message specified by Format and 
> the
> +  associated variable argument list to the debug output device.
> +
> +  If Format is NULL, then ASSERT().
> +
> +  @param  ErrorLevelThe error level of the debug message.
> +  @param  FormatFormat string for the debug message to print.
> +  @param  VaListMarker  VA_LIST marker for the variable argument list.
> +
> +**/
> +VOID
> +EFIAPI
> +DebugVPrint (
> +  IN  UINTNErrorLevel,
> +  IN  CONST CHAR8  *Format,
> +  IN  VA_LIST   VaListMarker
> +  )
>  {
>CHAR8Buffer[MAX_DEBUG_MESSAGE_LENGTH];
> -  VA_LIST  Marker;
>UINTNLength;
>  
>//
> @@ -72,9 +101,7 @@ DebugPrint (
>//
>// Convert the DEBUG() message to an ASCII String
>//
> -  VA_START (Marker, Format);
> -  Length = AsciiVSPrint (Buffer, sizeof (Buffer), Format, Marker);
> -  VA_END (Marker);
> +  Length = AsciiVSPrint (Buffer, sizeof (Buffer), Format, VaListMarker);
>  
>//
>// Send the print string to the debug I/O port
> @@ -270,6 +297,7 @@ DebugPrintLevelEnabled (
>return (BOOLEAN) ((ErrorLevel & PcdGet32(PcdFixedDebugPrintErrorLevel)) != 
> 0);
>  }
>  
> +
>  /**
>Return the result of detecting the debug I/O port device.
>  
> 

Thanks for addressing my v1 comments.

Reviewed-by: Laszlo Ersek 

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

Re: [edk2] [RFC PATCH] MdeModulePkg: add LockBoxNullLib for !IA32/X64 in .dsc

[Laszlo Ersek]

Hi Leif,

On 03/18/19 15:56, Leif Lindholm wrote:
> Commit 05fd2a926833
> ("MdeModulePkg/NvmExpressPei: Consume S3StorageDeviceInitList LockBox")
> added a dependency on LockBoxLib to NvmExpressPei, causing builds using
> MdeModulePkg.dsc to fail on architectures other than IA32/X64 with
> missing reference to
> gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode.
> 
> Add a resolution for LockBoxNullLib for ARM/AARCH64 to restore builds.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Leif Lindholm 
> ---
> 
> Note: this patch hides the symptom, but this isn't really the fix I
> would like to see.
> 
> The build error is caused by the chain of:
> 1) NvmExpressPei depending on LockBoxLib
> 2) LockBoxLib being mapped to SmmLockBoxPeiLib in [LibraryClasses.common.PEIM]
> 3) SmmLockBoxPeiLib depending on PcdDxeIplSwitchToLongMode
> 4) PcdDxeIplSwitchToLongMode being declared in
>[PcdsFeatureFlag.IA32, PcdsFeatureFlag.X64] in MdeModulePkg.dsc
> 
> Now, an alternative quick-fix would be to move the PEIM LockBoxLib mapping
> into a [LibraryClasses.IA32.PEIM, LibraryClasses.X64.PEIM]
> section. But that would leave NvmExpressPei unbuildable on anything not
> IA32/X64.
> 
> Another option would be to add default declaration (for all other
> architectures) of FALSE for PcdDxeIplSwitchToLongMode in MdeModulePkg.dec,
> but the current way this is expressed seems to treat this as an
> architecture-specific feature (which it is).
> 
> What I believe would be the cleanest solution would be to abstract
> NvmExpressPei to the point where it can function without the LockBoxLib.
> But regardless, it does not look valid to me for something as
> architecture-specific as MdeModulePkg/Library/SmmLockBoxLib/ to live under
> .common sections in the .dsc. (And if this changes at some point, because we 
> implement an ARM/AARCH64 equivalent based on StandaloneMmPkg, we will need
> a major refactoring of that library anyway.)
> 
> /
> Leif
> 
> MdeModulePkg/MdeModulePkg.dsc | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/MdeModulePkg/MdeModulePkg.dsc b/MdeModulePkg/MdeModulePkg.dsc
> index 6cd1727a0d..6e27e9cb68 100644
> --- a/MdeModulePkg/MdeModulePkg.dsc
> +++ b/MdeModulePkg/MdeModulePkg.dsc
> @@ -178,6 +178,7 @@ [LibraryClasses.common.MM_STANDALONE]
>  [LibraryClasses.ARM, LibraryClasses.AARCH64]
>ArmLib|ArmPkg/Library/ArmLib/ArmBaseLib.inf
>ArmMmuLib|ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf
> +  LockBoxLib|MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.inf
>  
>#
># It is not possible to prevent ARM compiler calls to generic intrinsic 
> functions.
> 

I think this patch is exactly the right solution.

The code added in commit 05fd2a926833 is gated by (BootMode ==
BOOT_ON_S3_RESUME). That condition can never evaluate to TRUE on
ARM/AARCH64, presently. Accordingly, the stated goal of the commit
doesn't apply to ARM/AARCH64:

The purpose is to perform an on-demand (partial) NVM Express device
enumeration/initialization to benefit the S3 resume performance.

Given that the RestoreLockBox() calls are never reached (which is
correct, by design, at the present level of ACPI S3 enablement in edk2
for ARM/AARCH64), causing the lockbox APIs to "do nothing beyond
compile" is exactly right. IMO anyway.

Once ARM/AARCH64 grow S3 support, a functional and secure LockBox will
have to be part of that. Perhaps it will use "standalone MM"; I'm not
sure. The point is, once the goal of the commit starts applying to
ARM/AARCH64, a functional LockBox will have been implemented for
ARM/AARCH64; and that lib instance will certainly not depend on
PcdDxeIplSwitchToLongMode.

Until such time, this patch is fine.

Reviewed-by: Laszlo Ersek 

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

Re: [edk2] [PATCH v1 0/2] Ovmf: Stop using ISA drivers within IntelFrameworkModulePkg

[Laszlo Ersek]

On 03/18/19 04:45, Wu, Hao A wrote:
>> -Original Message-
>> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
>> Sent: Friday, March 15, 2019 7:10 PM
>> To: Wu, Hao A
>> Cc: edk2-devel@lists.01.org; Justen, Jordan L; Laszlo Ersek; Ni, Ray
>> Subject: Re: [PATCH v1 0/2] Ovmf: Stop using ISA drivers within
>> IntelFrameworkModulePkg
>>
>> On Fri, 15 Mar 2019 at 08:16, Hao Wu  wrote:
>>>
>>> This series will update the OVMF to stop using the ISA drivers within
>>> IntelFrameworkModulePkg.
>>>
>>> As the replacement, a new OVMF Super I/O bus driver has been add which
>>> will install the Super I/O protocol for ISA serial and PS2 keyboard
>>> devices. By doing so, these devices can be managed by:
>>>
>>>   MdeModulePkg/Bus/Pci/PciSioSerialDxe/PciSioSerialDxe.inf
>>>   MdeModulePkg/Bus/Isa/Ps2KeyboardDxe/Ps2KeyboardDxe.inf
>>>
>>> respectively.
>>>
>>
>> Just a couple of notes from my side - I'm sure Laszlo will have a much
>> longer list :-)
>>
>> - Dropping the floppy driver is fine with me.
>> - What is OVMF specific about this driver? Is it only the hardcoded
>> list of COM1/COM2/PS2 keyboard? If so, should we split this into a
>> driver and a library class, where the driver lives in MdeModulePkg,
>> and the library is implemented in the context of OVMF?
> 
> Hello Ard,
> 
> I think the special thing for this one is that:
> For QEMU, it does not have a Super I/O (SIO) chip. While, as far as I
> know, the SIO chip exists on other platforms. The driver proposed here
> simulates the behavior of an SIO chip. IMO, if we find more platforms that
> do not have a SIO chip, we can convert the driver into a general one.
> 
> Also, for the implementation of the services in the Super I/O protocol,
> the proposed driver just does the minimal effort in order to support the
> serial/PS2 keyboard.

Here's why I'd like the majority of this driver to live under
MdeModulePkg (for example through a lib class separation like Ard suggests):

Because then its maintenance would not be the responsibility of OvmfPkg
maintainers.

Consider, this driver is absolutely huge (1.5-2 kLOC), for doing "the
minimal effort in order to support the serial/PS2 keyboard".

The risk of regressions is extreme (the PS/2 keyboard is the default
one, and if it breaks *subtly*, almost all users will be inconvenienced,
but not necessarily soon enough for us to get reports about it *early*
in the current development cycle).

I realize that IntelFrameworkModulePkg/Bus/Isa/* drivers are frowned
upon nowadays, they may be ugly / platform specific / etc etc etc, but
they have also proved themselves to *work*, and (as far as I remember)
they have required practically zero fixes in order to function well on QEMU.

It is very unwelcome by me to take on the maintenance burden for a
driver that is all of:
- not widely tested,
- replacing a proven set of drivers that is critical to users,
- large.

I understand that Intel wants to stop maintaining
IntelFrameworkModulePkg/Bus/Isa/*, but the above price is too high for me.

Compare the case if we simply moved the
IntelFrameworkModulePkg/Bus/Isa/* drivers under OvmfPkg:
- still large,
- but widely tested (with minimal churn in the past),
- and no risk of regressions.

So in this form, I'm generally opposed to the switch. The two sets of
drivers need to coexist for a while, and we must expose the new drivers
to users while providing them with some sort of easy fallback. (I'd
prefer that fallback to be dynamically configurable, but, again, if your
keyboard breaks, how do you interact with e.g. the UEFI shell? So I
guess a static build flag would do as well.) I think the old drivers
should be removed only in the edk2 stable tag that comes *after* the
next one, once we've given the drivers enough time to "prove themselves".

(We did something similar when we switched to the central PCI root
bridge driver in OVMF as well -- an OVMF lib instance for it was
implemented, so the maintenance burden wasn't fully under OvmfPkg to
begin with, plus we kept the old driver around with a build flag for a
while. IIRC.)

Obviously I might feel safer if I could do a thorough review of the
driver, but I *absolutely* don't have time for it now. I'm sorry about that.

Thanks,
Laszlo

>> - Regardless of the previous, adding the new driver should be a patch
>> of its own.
> 
> Agree. I will adopt the detailed approach suggested by Jordan for this one.
> Thanks for the feedback.
> 
>> - I spotted an incorrect reference to PCI_IO_DEV in a comment (patch #2)
> 
> Thanks for the catch. I will address this comment typo in the next version of
> the series.
> 
> 
> I will wait a little longer to see if Laszlo

Re: [edk2] PATCH] Change EDK II to BSD+Patent License

[Laszlo Ersek]

On 03/15/19 18:48, Lars Kurth wrote:
> 
> 
> On 15/03/2019, 10:18, "Julien Grall"  wrote:
> 
> >  
> >  EDK2 is converting the full copyright in each file to SDPX 
> identifier. While the
> >  copyright looks like an MIT license, it has never been confirmed. 
> Andrew Cooper
> >  suggested you might be able to confirm.
> >  
> > Is there a web-link to the files/repos such that I don’t have to clone 
> the repo
> > Lars
> 
> Here an example of files from Xen public headers:
> 
> 
> https://xenbits.xen.org/gitweb/?p=xen.git;a=tree;f=xen/include/public;h=0618b0134d2b9babcba71a3f0f86be5a84468b50;hb=HEAD
> 
> OK, this makes this easy then. Because in all likelihood, the files were 
> copied from xen/include/public and then the COPYING file 
> https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/include/public/COPYING 
> applies, which states that everything in this directory is MIT, unless stated 
> otherwise in the file. 
> 
> So as long as someone confirms that the files in OvmfPkg/Include came from 
> xen/include/public, this is a clear case of a MIT license
> If they are files from other directories in Xen, check the COPYING file in 
> the original directory (or if there is none in the parent directory) and 
> check the COPYING file
> 
> I am not so clear about where the files in XenBusDxe came from, but the same 
> principle applies. 
> 
> If someone groups these files by "original directory in Xen" to File ... I am 
> happy to do a final sanity check and sign it off and/or deal with any unclear 
> cases

Replacing MIT license blocks with SPDX identifiers is something we
should do later -- I think it's out of scope for Mike's current patch
series, it's just something I noticed and pointed out for the future,
while I was verifying the "license block -> SPDX ID" replacements for
2-BSDL (i.e., *not* MIT).

Mike mentioned that he was going to file a number of TianoCore BZs as a
result of the discussion in this thread. Mike, can you please file one
for the MIT->SPDX "refactoring" (under OvmfPkg) as well? If not, I can
file it myself later, I just wouldn't like us to end up with duplicates.

Once we have that separate BZ, we can discuss it in isolation.

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

Re: [edk2] [PATCH RESEND 1/3] OvmfPkg/XenSupport: remove usage of prefetchable PCI host bridge aperture

[Laszlo Ersek]

On 03/19/19 15:03, Anthony PERARD wrote:
> On Thu, Mar 14, 2019 at 07:45:56PM +, Igor Druzhinin wrote:
>> On 14/03/2019 17:41, Anthony PERARD wrote:
>>> Hi,
>>>
>>> On Wed, Mar 06, 2019 at 12:40:54PM +, Igor Druzhinin wrote:
 This aperture doesn't exist in OVMF and trying to use it causes
>>>
>>> I'm trying to understand what you mean by writing "doesn't exist in
>>> OVMF". Are prefetchable BAR not handled by ScanForRootBridges() ?
>>> Or is it the emulation of the config space that isn't correct?
>>> Maybe QEMU should lies about a BAR been prefetchable?
>>
>> The problem here is: hvmloader places BARs initially disregarding
>> prefetchable bit in an arbitrary order because essentially there is only
>> 1 aperture for the host bridge in emulated system under Xen (and KVM as
>> well). In PcatPciRootBridgeParseBars() we construct apertures for high
>> level OVMF code by reading the BAR placement information after
>> hvmloader. It often appears that there are prefetchable and
>> non-prefetchable BARs coexist with each other and make prefetchable and
>> non-prefetchable apertures overlap. This eventually triggers an
>> assertion in high level OVMF code because that shouldn't happen.
> 
> Thanks for the explanation. Could you add it to the patch description?
> 
>> OVMF for KVM is not using prefetchable BAR at all - see
>> PciHostBridgeGetRootBridges() in which it passes mNonExistAperture dummy
>> object to high level code. I think it's wrong to construct a
>> prefetchable aperture for Xen and this code should be removed as it's
>> done for QEMU-KVM. Do you think this patch needs to do that?
> 
> It would be nice to remove the code that isn't useful so feel free to do
> it and/or keep the current patch with the description updated.

Right -- I'd like to add one keyword here, for background: 
EFI_PCI_HOST_BRIDGE_COMBINE_MEM_PMEM. (It's documented in both edk2 
[MdePkg/Include/Protocol/PciHostBridgeResourceAllocation.h] and the PI spec 
[EFI_PCI_HOST_BRIDGE_RESOURCE_ALLOCATION_PROTOCOL.GetAllocAttributes()].)

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

Re: [edk2] [RFC 0/3] Enable runtime serial debug for ArmVirtQemu

[Laszlo Ersek]

On 03/16/19 10:41, Heyi Guo wrote:
> On 2019/3/13 1:05, Laszlo Ersek wrote:

>> Given that you'd have to implement a "special" SerialPortLib instance
>> just for StatusCodeHandlerRuntimeDxe anyway, can we perhaps:
>>
>> (1) Undo -- dependent on a build flag? -- commit ebfca258f5d7; i.e.,
>> stick universally with BaseDebugLibSerialPort, for DebugLib,
>>
>> (2) add a new implementation of "FdtPL011SerialPortLib.inf" with both
>> (a) runtime behavior and (b) handling of a special serial port?
>>
>> In other words, push down the "runtime?" distinction from DebugLib (see
>> commit 7f029e1b31ee) to SerialPortLib. The new SerialPortLib instance
>> would be used only with DXE_RUNTIME_DRIVERs.
>>
>> The lib instance would prepare everything in advance for accessing the
>> "special" serial port at runtime (which could require allocating runtime
>> memory in advance). Once ExitBootServices() is called, a callback should
>> switch over the behavior of the lib instance, without allocating further
>> memory. (The switched-over behavior would not have to be functional
>> until the virtual address map is set.)
> My first idea was also simply implement a runtime serial port instance,
> but the problem is for the initialization.
> 
> Since serial port lib is only a library, it seems we can only initialize
> everything in SerialPortInitialize() or library constructor, but either
> of which could no work in current EDK2 code framework. Please see my
> explanation in earlier mail as below:
> 
> "The long story is: at first I proposed to still use
> BaseSerialPortDebugLib, so I added RuntimePrepare() function into the
> constructor directly, but the builder complained about looped
> constructors, for RuntimePrepare() invokes gBS and some RunTime
> libraries. Then I tried disabling the constructor and moved
> RuntimePrepare() into SerialPortInitialize() which could complete the
> build, but still couldn't guarantee the calling order of these
> constructors, for BaseSerialPortDebugLib has a constructor to call
> SerialPortInitialize()."

(Sorry about the late response (I've been away for a few days), and also
for missing that construction loop that you apparently mentioned earlier.)

You mention that "RuntimePrepare() invokes gBS and some RunTime
libraries". How important is it to rely on those libraries?

For example, "gBS" is simply a convenience; you can get at the same
thing from the parameter list of the constructor function too (assuming
you use a MODULE_TYPE of (minimally) DXE_DRIVER, in the lib instance's
INF file).

If we don't have to flatten a ridiculous amount of other library code
into the RuntimePrepare() function, I think such flattening would be a
viable approach. We've run into this constructor loop several times
before, and -- if I remember correctly anyway! -- one approach has been
to declare SerialPortLib the "lowest level abstraction", and make the
affected lib instance self-contained.

> Can we use event notify or protocol notify to do the runtime
> intialization? Like EndOfDxe event group. Any other advice?

I guess this could work too. I'm not really a fan of callbacks as long
as we can manage otherwise (for example, we can't propagate errors out
of callbacks), but if the lib flattening thing gets too complex, we
could do this as well.

Regarding EndOfDxe -- I think EndOfDxe is considered a trust barrier
(namely between platform fw modules and 3rd party modules), so I
wouldn't tie our initialization to that, for clarity's sake. ReadyToBoot
seems a tiny bit less "forced" -- it is sufficiently late, you can still
allocate resources, and we can claim it is "on the path towards OS
runtime". Just be aware that ReadyToBoot can be signaled multiple times,
e.g. if some boot options fail (so uninstall the handler / close the
event when serving the first callback I guess).

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

Re: [edk2] [staging/PRMCaseStudy]: Creating a new feature branch "PRMCaseStudy"

[Laszlo Ersek]

On 03/14/19 09:46, You, Benjamin wrote:
> Hi,
> 
> 
> 
> A new feature branch "PRMCaseStudy" is being created in edk2-staging.
> 
> 
> Platform Runtime Mechanism (PRM) is an architecture for ACPI codes to call 
> into UEFI BIOS's Runtime Services at OS runtime. Traditionally, ACPI codes 
> call into BIOS through the invocation of Software SMIs. When applicable, PRM 
> provides an alternative for ACPI codes to invoke UEFI Runtime Services, which 
> runs in OS kernel space, without invoking SMM.
> 
> This package contains proof-of-concept codes that implement the ideas of PRM.
> 
> Resources:
> 
> - PRM introduction: https://www.opencompute.org/events/past-summits (Please 
> search for "UEFI Implementation Intel(r) Xeon Based OCP Platform" in the 
> webpage, which lists pointers to video and presentation that introduce the 
> concept of PRM)
> - TianoCore: http://www.tianocore.org
> - UEFI Forum: https://uefi.org/

(I've read the slides now. Hopefully I understand them sufficiently for
making reasonable comments below.)

While this feature looks exciting and nice from a technical standpoint,
I think it would have a bad effect on operating system drivers, in
particular in open source operating systems.

Currently, as far as I know, the best quality OS hw drivers are those
that (a) manipulate hardware directly, and (b) are developed against
open hardware specs.

In comparison, this feature promotes a generic OS->firmware call
interface. It allows platform vendors to liberally define UEFI runtime
services, and OS-level drivers to call those platform-specific UEFI
runtime services through semi-standardized ACPI methods.

As a result, more and more OS hw drivers (especially for platform
hardware) would be written on top of ACPI, and not on top of hardware
access / hardware specs. I don't think that ACPI-based OS drivers for
platform hardware are a bad thing; I think that making that kind of
driver development *too easy* is a bad thing. Here's why:

- every such OS driver is harder to develop & debug for the OS
developer, because there's another layer of software between them and
the hardware that they cannot change, and can debug only with difficulties

- if the semi-standardized ACPI interfaces are too heavy-weight or too
coarse-grained, then they might not integrate well into the driver
framework of an OS. This can lead to bad performance and/or missing
features.

- the *easy* availability of such a runtime OS->firmware interface will
tempt hardware vendors to cut corners and add platform hacks to e.g. PCI
Express or USB devices, or even to implement devices that should be PCIE
or USB in the first place as platform devices. We've already seen too
much of that mess. Devices with platform hacks, and platform devices,
are very hard to isolate and to use from virtual machines (as assigned
(aka "passthrough") devices), for example. But even without
virtualization, the same kind of isolation may be necessary for hw
drivers implemented in userspace.

I'm totally a fan of ACPI (over DT, e.g.) for devices that *must* be
platform devices. I'm very much not a fan of platform devices themselves.

In summary:

The runtime involvement of firmware should be minimized. The PRM
approach seems to make that problem *worse* however, by widening the
firmware's runtime role, through side-stepping the current problems of SMM.


My apologies if I've missed details, or if my comments are otherwise
misguided.

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

Re: [edk2] [PATCH 09/17] OvmfPkg/PlatformDebugLibIoPort: Add a new api DebugVPrint

[Laszlo Ersek]

On 03/14/19 10:03, Zhichao Gao wrote:
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1395
> 
> Add a new api DebugVPrint implementation in the
> DebugLib instance. This api would expose a print
> routine with VaList parameter.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Zhichao Gao 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: Liming Gao 
> Cc: Sean Brogan 
> Cc: Michael Turner 
> Cc: Bret Barkelew 
> ---
>  OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c | 41 
> +++
>  1 file changed, 35 insertions(+), 6 deletions(-)
> 
> diff --git a/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c 
> b/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c
> index 36cde54976..1e64eeec11 100644
> --- a/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c
> +++ b/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c
> @@ -2,7 +2,7 @@
>Base Debug library instance for QEMU debug port.
>It uses PrintLib to send debug messages to a fixed I/O port.
>  
> -  Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.
> +  Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
>Copyright (c) 2012, Red Hat, Inc.
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the BSD 
> License
> @@ -51,9 +51,41 @@ DebugPrint (
>IN  CONST CHAR8  *Format,
>...
>)
> +{
> +  VA_LIST Marker;
> +
> +  ASSERT(Format != NULL);

(1) I think this ASSERT() is redundant.  The rest of this function will
work fine with the ASSERT() removed, and the DebugVPrint() function will
itself contain an ASSERT(), with the same condition. So I'd prefer
removing this one. (The function-level comments will remain valid.)

> +
> +  VA_START(Marker, Format);
> +  DebugVPrint(ErrorLevel, Format, Marker);
> +  VA_END(Marker);

(2) Please insert a space character before each opening parenthesis.

> +}
> +
> +/**
> +  Prints a debug message to the debug output device if the specified error 
> level is enabled.
> +
> +  If any bit in ErrorLevel is also set in DebugPrintErrorLevelLib function
> +  GetDebugPrintErrorLevel (), then print the message specified by Format and 
> the
> +  associated variable argument list to the debug output device.
> +
> +  If Format is NULL, then ASSERT().
> +  If the length of the message string specificed by Format is larger than 
> the maximum allowable
> +  record length, then directly return and not print it.

(3) The last sentence is not enforced by the implementation.

We should
- either implement the check,
- or extend the sentence, saying that there is no such limit in this
library instance,
- or remove the sentence.

I think I'd prefer simply removing the sentence, given that the
DebugPrint() comments lack it as well.

> +
> +  @param  ErrorLevelThe error level of the debug message.
> +  @param  FormatFormat string for the debug message to print.
> +  @param  VaListMarker  VA_LIST marker for the variable argument list.
> +
> +**/
> +VOID
> +EFIAPI
> +DebugVPrint (
> +  IN  UINTNErrorLevel,
> +  IN  CONST CHAR8  *Format,
> +  IN  VA_LIST   VaListMarker
> +  )
>  {
>CHAR8Buffer[MAX_DEBUG_MESSAGE_LENGTH];
> -  VA_LIST  Marker;
>UINTNLength;
>  
>//
> @@ -72,9 +104,7 @@ DebugPrint (
>//
>// Convert the DEBUG() message to an ASCII String
>//
> -  VA_START (Marker, Format);
> -  Length = AsciiVSPrint (Buffer, sizeof (Buffer), Format, Marker);
> -  VA_END (Marker);
> +  Length = AsciiVSPrint (Buffer, sizeof (Buffer), Format, VaListMarker);
>  
>//
>// Send the print string to the debug I/O port
> @@ -82,7 +112,6 @@ DebugPrint (
>IoWriteFifo8 (PcdGet16 (PcdDebugIoPort), Length, Buffer);
>  }
>  
> -
>  /**
>Prints an assert message containing a filename, line number, and 
> description.
>This may be followed by a breakpoint or a dead loop.
> 

(4) This hunk (the last hunk of the patch), which only removes an empty
line, looks superfluous to me. I suggest dropping it.

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

Re: [edk2] PATCH] Change EDK II to BSD+Patent License

[Laszlo Ersek]

Hi Mike,

On 03/13/19 18:54, Kinney, Michael D wrote:
> Hello,
>
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1373
>
> This change is based on the following emails:
>   https://lists.01.org/pipermail/edk2-devel/2019-February/036260.html
>   https://lists.01.org/pipermail/edk2-devel/2018-October/030385.html
>
> RFCs with detailed process for the license change:
>   https://lists.01.org/pipermail/edk2-devel/2019-March/037669.html
>   https://lists.01.org/pipermail/edk2-devel/2019-March/037500.html
>
> I have posted the patch series for review on the following branch
> using edk2-stable201903 as the base for the patch series.
>
>   https://github.com/mdkinney/edk2/tree/Bug_1373_BsdPatentLicense
>
> The commits in patch series can be viewed here:
>
>   https://github.com/mdkinney/edk2/commits/Bug_1373_BsdPatentLicense
>
> The patch series has one patch per package along with a few patches
> to update the license information in the root of the edk2 repository
> as described in the RFC V2.
>
> Due to the size of the patch series, I prefer to not send the
> patch emails.  Instead, please perform code reviews using content
> from the branch.
>
> All EDK II package maintainers and package reviewers should provide
> review feedback for their packages.  The critical part of the review
> is:
> 1) Any changes that cause build breaks or logic changes.  These code
>changes are intended to only modify license contents in comment
>blocks.
> 2) Any file that has been changed to BSD+Patent, but should remain
>with the current license.
> 3) Any file that that has not changed to BSD+Patent, but should be
>changed to BSD+Patent.
>
> Feedback and Reviewed-by emails should identify the patch the feedback
> applies using the patch summary listed below.  The goal is to complete
> all reviews to support the commit of these patches on April 9, 2019.

[...]


> 837a3425bf OvmfPkg: Replace BSD License with BSD+Patent License

(1) For the commit message, I have the following suggestions:

(1.1) please remove the "Cc:" tags, because you aren't actually posting
  the patches to the mailing list, so the people listed in Cc have
  no chance to receive the patch by email ("carbon-copied")

(1.2) please remove the "Branch for review" reference as well -- while I
  certainly prefer such branch references ot remain valid forever,
  in practice their longevity is quite dubious in comparison to e.g.
  mailing list archive links.

(2) Regarding the patch body:

(2.1) I reviewed each of the 348 hunks in the patch file. They are
  correct, with one exception:

(2.1.1) "create-release.py" doesn't only contain a copyright block
(which is correctly patches), but it also *generates* a
copyright block. (Search it manually for
"http://opensource.org/licenses/bsd-license.php;.) In my
opinion, we should simply retire this python script, *before*
the conversion is started -- I don't remember using it in recent
years, plus now we have the stable tags, for open source
community-oriented releases.

(2.2) 30 files under OvmfPkg remain without "SPDX-License-Identifier:
  BSD-2-Clause-Patent" after the patch is applied. These can be
  categorized as follows:

(2.2.1) Files without any copyright notices (very small files,
README-like files, generated files):

  OvmfPkg/Csm/Csm16/ReadMe.txt
  OvmfPkg/Include/IndustryStandard/Xen/README
  OvmfPkg/README

  OvmfPkg/Library/XenHypercallLib/Ia32/hypercall.nasm
  OvmfPkg/Library/XenHypercallLib/X64/hypercall.nasm
  OvmfPkg/XenBusDxe/Helpers.c

  OvmfPkg/QemuVideoDxe/VbeShim.h

It's fine to leave these untouched.

(2.2.2) Files that seem to be covered by the MIT license.

  OvmfPkg/Include/IndustryStandard/Xen/arch-arm/xen.h
  OvmfPkg/Include/IndustryStandard/Xen/arch-x86/xen-x86_32.h
  OvmfPkg/Include/IndustryStandard/Xen/arch-x86/xen-x86_64.h
  OvmfPkg/Include/IndustryStandard/Xen/arch-x86/xen.h
  OvmfPkg/Include/IndustryStandard/Xen/event_channel.h
  OvmfPkg/Include/IndustryStandard/Xen/grant_table.h
  OvmfPkg/Include/IndustryStandard/Xen/hvm/hvm_op.h
  OvmfPkg/Include/IndustryStandard/Xen/hvm/params.h
  OvmfPkg/Include/IndustryStandard/Xen/io/blkif.h
  OvmfPkg/Include/IndustryStandard/Xen/io/console.h
  OvmfPkg/Include/IndustryStandard/Xen/io/protocols.h
  OvmfPkg/Include/IndustryStandard/Xen/io/ring.h
  OvmfPkg/Include/IndustryStandard/Xen/io/xenbus.h
  OvmfPkg/Include/IndustryStandard/Xen/io/xs_wire.h
  OvmfPkg/Include/IndustryStandard/Xen/memory.h
  OvmfPkg/Include/IndustryStandard/Xen/xen-compat.h
  OvmfPkg/Include/IndustryStandard/Xen/xen.h
  OvmfPkg/XenBusDxe/XenBus.c
  OvmfPkg/XenBusDxe/XenStore.c
  OvmfPkg/XenBusDxe/XenStore.h

It's OK to leave these untouched, 

Re: [edk2] F29 Build Issue.

[Laszlo Ersek]

On 03/13/19 14:27, Andrew J. Hutton wrote:
> Unsure if this is a missing build dependency (since there doesn't appear
> to be a check for this) am I missing a make dep or configure step
> somewhere?
> 
> This is stock F29, following the website instructions; the make -C
> BaseTools/Source/C results in the following errror:
> 
> make[1]: Entering directory
> '/home/ajh/KVM/Clover/edk2/BaseTools/Source/C/GenVtf'
> cc  -c -MD -fshort-wchar -fno-strict-aliasing -Wall -Werror
> -Wno-deprecated-declarations -nostdlib -c -g  -I .. -I ../Include/Common
> -I ../Include/ -I ../Include/IndustryStandard -I ../Common/ -I .. -I .
> -I ../Include/X64/  GenVtf.c -o GenVtf.o
> GenVtf.c: In function ‘CreateFitTableAndInitialize’:
> GenVtf.c:1473:3: error: ‘strncpy’ output truncated before terminating
> nul copying 8 bytes from a string of the same length
> [-Werror=stringop-truncation]
>    strncpy ((CHAR8 *) >CompAddress, FIT_SIGNATURE, 8);  //
> "_FIT_ "
>    ^~~
> cc1: all warnings being treated as errors
> make[1]: *** [../Makefiles/footer.makefile:27: GenVtf.o] Error 1
> make[1]: Leaving directory
> '/home/ajh/KVM/Clover/edk2/BaseTools/Source/C/GenVtf'
> make: *** [GNUmakefile:73: GenVtf] Error 2
> make: Leaving directory '/home/ajh/KVM/Clover/edk2/BaseTools/Source/C'

The edk2 codebase that you are consuming is too old. The above symptom
should not be present since commit 1d212a83df0e
("BaseTools/header.makefile: add "-Wno-stringop-truncation"", 2018-03-05).

The command line you quoted also misses "-Wno-unused-result", so I think
you must be missing commit 202726b3ceb3 ("BaseTools Makefile: Enable O2
option for GCC tool chain", 2016-10-08) as well.

I assume clover still uses an edk2 checkout that's 2.5+ years old at
this point.

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

Re: [edk2] [RFC 0/3] Enable runtime serial debug for ArmVirtQemu

[Laszlo Ersek]

Hi Andrew,

On 03/12/19 18:28, Andrew Fish wrote:
> 
> 
>> On Mar 12, 2019, at 10:05 AM, Laszlo Ersek  wrote:
>>
>> Hello Heyi,
>>
>> On 03/12/19 07:56, Heyi Guo wrote:
>>> Hi Laszlo,
>>>
>>> I'm thinking about a proposal as below:
>>>
>>> 1. Reuse the framework of
>>> MdePkg/Library/DxeRuntimeDebugLibSerialPort/DxeRuntimeDebugLibSerialPort.inf
>>>
>>> 2. The boot time behavior of this module is not changed
>>> 3. Switch to status code protocol for runtime debug
>>> 4. Use an overridden SerialPortLib instance for
>>> StatusCodeHandlerRuntimeDxe; the instance must support runtime access.
>>>
>>> Then we can have below benefits:
>>> 1. the boot time firmware log, and the OS log, went to one port; and
>>> there is no dependence for runtime drivers to output serial message at
>>> boot time.
>>> 2. By implementing different instances of SerialPortLib for
>>> StatusCodeHandlerRuntimeDxe, we can have enough flexibility to direct
>>> runtime serial message to platform specific serial port.
>>
>> This looks a bit over-engineered to me. Ultimately our goal is:
>> - for DEBUGs to reach "a" serial port at runtime -- namely one that
>> differs from the "normal" serial port.
>>
>> Given that you'd have to implement a "special" SerialPortLib instance
>> just for StatusCodeHandlerRuntimeDxe anyway, can we perhaps:
>>
>> (1) Undo -- dependent on a build flag? -- commit ebfca258f5d7; i.e.,
>> stick universally with BaseDebugLibSerialPort, for DebugLib,
>>
>> (2) add a new implementation of "FdtPL011SerialPortLib.inf" with both
>> (a) runtime behavior and (b) handling of a special serial port?
>>
>> In other words, push down the "runtime?" distinction from DebugLib (see
>> commit 7f029e1b31ee) to SerialPortLib. The new SerialPortLib instance
>> would be used only with DXE_RUNTIME_DRIVERs.
>>
>> The lib instance would prepare everything in advance for accessing the
>> "special" serial port at runtime (which could require allocating runtime
>> memory in advance). Once ExitBootServices() is called, a callback should
>> switch over the behavior of the lib instance, without allocating further
>> memory. (The switched-over behavior would not have to be functional
>> until the virtual address map is set.)
>>
> 
> Laszlo,
> 
> Runtime does not quite work like that. As soon as the Set Virtual Address map 
> fires it is only legal to call things EFI RT from the virtual mapping. The 
> last stage of the Set Virtual Address Map call is to reapply the fixups in 
> the Runtime Drivers for the virtual address space. That means any absolute 
> address reference in the code now points to the virtual address. Also the Set 
> Virtual Address event told the Runtime Driver to convert all its pointers to 
> point to the new virtual address space. 

I believe I understand this, but I don't understand where my suggestion
was invalid given, your explanation.

What I meant was the following:

- the SerialPortLib instance in question configures the normal serial
  port (which is not hidden from the OS) for boot time logging

- it also sets up the other serial port (which will be hidden from the
  OS, and used for runtime firmware debug messages) with everything
  necessary. Runtime memory allocation (if dynamic memory allocation is
  needed), hardware configuration, pointers to (physical) addresses of
  registers, and even MMIO | RUNTIME entries in the GCD memory space map
  (if they don't exist yet). Any PCDs that we reasonably expect to be
  dynamic, would be cached in globals, and so on.

- Once ExitBootServices() occurs, the callback in the lib instance
  updates a boolean flag. In the SetVirtualAddressMap() handler, the
  pointers to the MMIO registers of the "hidden" serial port are
  converted to their virtual counterparts. No memory allocation or
  hardware configuration is necessary in either event handler.

- Further DEBUG messages are simply directed to the "hidden" serial
  port, via the boolean flag and the converted pointers.

Thanks,
Laszlo

> The blackout and the fact you need to hide the hardware from the OS make 
> doing things at EFI Runtime Time hard. 
> 
> I agree with you that since our logging is really just a serial stream we 
> don't require Report Status Code. Report Status Code exists so that the old 
> PC POST Cards could still be supported, see: 
> https://en.wikipedia.org/wiki/Power-on_self-test#Error_reporting. There is 
> also a Report Status Code layer that allows redirecting the stream to 
> multiple agents, so for example you co

Re: [edk2] [RFC v2] Change EDK II to BSD+Patent License

[Laszlo Ersek]

On 03/10/19 01:15, Kinney, Michael D wrote:
> Hello,
> 
> Changes for V2
> ===
> * Replace 2-Clause BSD License in file headers with SPDX-License-Identifier
>   statement.  This reduces the size of the file headers and the size
>   of the patches for this change.  Based on the following post:
> 
>   
> https://01.org/blogs/jc415/2018/open-source-hacks-one-question-interviews-open-source-experts-how-use-spdx-headers

This looks real nice.

Thanks
Laszlo

> 
> * Update License.txt in root of edk2 before changing file headers.
> * Fix minor typos
> ===
> 
> This RFC follows up on the proposal from Mark Doran to change the 
> EDK II Project to a BSD+Patent License.
> 
>   https://lists.01.org/pipermail/edk2-devel/2019-February/036260.html
> 
> The review period for this license change is 30 days.  If there is no
> unresolved feedback on April 9, 2019, then commits of the license change
> patches will begin on April 9, 2019.  
> 
>   ** Please provide feedback on the proposal by Monday April 8, 2019. **
> 
> Feedback can be sent to edk2-devel@lists.01.org, the EDK II community
> manager or any of the EDK II stewards.
> 
>   * Stephano CetolaCommunity Manager
>   * Leif Lindholm   Steward
>   * Andrew Fish  Steward
>   * Laszlo Ersek   Steward
>   * Michael KinneySteward
> 
> The goal is to convert all of the files in the edk2 repository that are
> currently covered by the 2-Clause BSD License and the TianoCore
> Contribution Agreement to a BSD+Patent License.  
> 
> I will be following up with pointers to public GitHub branches that
> contain the set of changes to the edk2 repository for review.
> 
> The proposal is to perform this change to edk2/master in the steps listed
> below. The license change will not be applied to any of the other existing
> branches in the edk2 repository.
> 
> 1) Add a License-History.txt file to the root of the edk2 repository that
>contains the 2-Clause BSD License and the TianoCore Contribution
>Agreement along with the details on the change to the BSD+Patent License.
> 
> 2) Change License.txt in the root of the edk2 repository from a 2-Clause
>BSD License to the BSD+Patent License. The following is the link to the
>BSD+Patent License and the new License.txt file contents.
> 
>https://opensource.org/licenses/BSDplusPatent
> 
>==
>Redistribution and use in source and binary forms, with or without
>modification, are permitted provided that the following conditions are met:
> 
>1. Redistributions of source code must retain the above copyright notice,
>   this list of conditions and the following disclaimer.
> 
>2. Redistributions in binary form must reproduce the above copyright 
> notice,
>   this list of conditions and the following disclaimer in the 
> documentation
>   and/or other materials provided with the distribution.
> 
>Subject to the terms and conditions of this license, each copyright holder
>and contributor hereby grants to those receiving rights under this license
>a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable
>(except for failure to satisfy the conditions of this license) patent
>license to make, have made, use, offer to sell, sell, import, and otherwise
>transfer this software, where such license applies only to those patent
>claims, already acquired or hereafter acquired, licensable by such 
> copyright
>holder or contributor that are necessarily infringed by:
> 
>(a) their Contribution(s) (the licensed copyrights of copyright holders and
>non-copyrightable additions of contributors, in source or binary form)
>alone; or
> 
>(b) combination of their Contribution(s) with the work of authorship to
>which such Contribution(s) was added by such copyright holder or
>contributor, if, at the time the Contribution is added, such addition
>causes such combination to be necessarily infringed. The patent license
>shall not apply to any other combinations which include the
>Contribution.
> 
>Except as expressly stated above, no rights or licenses from any copyright
>holder or contributor is granted under this license, whether expressly, by
>implication, estoppel or otherwise.
> 
>DISCLAIMER
> 
>THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
>AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
>IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
>ARE DIS

Re: [edk2] [RFC 0/3] Enable runtime serial debug for ArmVirtQemu

[Laszlo Ersek]

Hello Heyi,

On 03/12/19 07:56, Heyi Guo wrote:
> Hi Laszlo,
> 
> I'm thinking about a proposal as below:
> 
> 1. Reuse the framework of
> MdePkg/Library/DxeRuntimeDebugLibSerialPort/DxeRuntimeDebugLibSerialPort.inf
> 
> 2. The boot time behavior of this module is not changed
> 3. Switch to status code protocol for runtime debug
> 4. Use an overridden SerialPortLib instance for
> StatusCodeHandlerRuntimeDxe; the instance must support runtime access.
> 
> Then we can have below benefits:
> 1. the boot time firmware log, and the OS log, went to one port; and
> there is no dependence for runtime drivers to output serial message at
> boot time.
> 2. By implementing different instances of SerialPortLib for
> StatusCodeHandlerRuntimeDxe, we can have enough flexibility to direct
> runtime serial message to platform specific serial port.

This looks a bit over-engineered to me. Ultimately our goal is:
- for DEBUGs to reach "a" serial port at runtime -- namely one that
differs from the "normal" serial port.

Given that you'd have to implement a "special" SerialPortLib instance
just for StatusCodeHandlerRuntimeDxe anyway, can we perhaps:

(1) Undo -- dependent on a build flag? -- commit ebfca258f5d7; i.e.,
stick universally with BaseDebugLibSerialPort, for DebugLib,

(2) add a new implementation of "FdtPL011SerialPortLib.inf" with both
(a) runtime behavior and (b) handling of a special serial port?

In other words, push down the "runtime?" distinction from DebugLib (see
commit 7f029e1b31ee) to SerialPortLib. The new SerialPortLib instance
would be used only with DXE_RUNTIME_DRIVERs.

The lib instance would prepare everything in advance for accessing the
"special" serial port at runtime (which could require allocating runtime
memory in advance). Once ExitBootServices() is called, a callback should
switch over the behavior of the lib instance, without allocating further
memory. (The switched-over behavior would not have to be functional
until the virtual address map is set.)

I've always seen status code reporting cumbersome in comparison to plain
DEBUG messages. My understanding is that status code reporting targets
devices that are even dumber than serial ports. But, we do target a
second serial port. So if we can keep the switchover internal to the
SerialPortLib class, at least for runtime DXE drivers, then I think we
should do that.

Thanks,
Laszlo

> On 2019/3/1 23:27, Laszlo Ersek wrote:
>> +Peter, for the last few paragraphs
>>
>> On 02/28/19 13:10, Ard Biesheuvel wrote:
>>> On Thu, 28 Feb 2019 at 09:06, Heyi Guo  wrote:
>>>> Serial port output is useful when debugging UEFI runtime services in
>>>> OS runtime.
>>>> The patches are trying to provide a handy method to enable runtime
>>>> serial port
>>>> debug for ArmVirtQemu.
>>>>
>>>> Cc: Jian J Wang 
>>>> Cc: Hao Wu 
>>>> Cc: Laszlo Ersek 
>>>> Cc: Ard Biesheuvel 
>>>> Cc: Julien Grall 
>>>>
>>>> Heyi Guo (3):
>>>>    MdeModulePkg/StatusCode: Add PCD to enable runtime serial debug
>>>>    ArmVirtPkg: add runtime instance of FdtPL011SerialPortLib
>>>>    ArmVirtQemu: enable runtime debug by build flag
>>>>
>>> Hello Heyi,
>>>
>>> We have had this discussion before, and IIRC, the proposed solution
>>> was to use status codes.
>>>
>>> I'm not sure how that is supposed to work though - hopefully Laszlo or
>>> one of the MdeModulePkg maintainers can elaborate.
>> Here's the basic idea.
>>
>> Status Code reporting and routing are defined by the PI spec for OS
>> runtime as well, not just boot time.
>>
>> Recently we added status code *routing* to ArmVirtPkg, in commit
>> 5c574b222ec2, via the generic runtime driver
>> "ReportStatusCodeRouterRuntimeDxe". We also added the library resolution
>>
>> ReportStatusCodeLib -->
>> MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
>>
>> (for some module types). As a result, when modules of those types report
>> status codes, they now reach the ReportStatusCodeRouterRuntimeDxe
>> driver, which "routes" the status codes.
>>
>> In the same series, we also modified ArmVirtPkg's PlatformBootManagerLib
>> (built into BdsDxe) to register a status code *handler* callback with
>> ReportStatusCodeRouterRuntimeDxe -- but only for boot time (not
>> runtime), and only for a very specific group of status codes. As a
>> result, when a module of suitable type reports a status code,
>> ReportStatusCodeRouterRuntimeDxe "routes it" to BdsDxe, and then 

Re: [edk2] [PATCH 3/3] UefiCpuPkg/UefiCpuPkg.uni: Add the prompt and help information

[Laszlo Ersek]

On 03/11/19 02:15, Dong, Eric wrote:
> Reviewed-by: Eric Dong 

Thanks. I'm on the verge of email bankruptcy, so I'll skip this review.

Laszlo

>> -Original Message-
>> From: Zhang, Shenglei
>> Sent: Monday, March 11, 2019 8:55 AM
>> To: edk2-devel@lists.01.org
>> Cc: Dong, Eric ; Ni, Ray ; Laszlo
>> Ersek 
>> Subject: [PATCH 3/3] UefiCpuPkg/UefiCpuPkg.uni: Add the prompt and help
>> information
>>
>> The prompt and help information are missing in UefiPkg.uni.
>> https://bugzilla.tianocore.org/show_bug.cgi?id=1600
>>
>> Cc: Eric Dong 
>> Cc: Ray Ni 
>> Cc: Laszlo Ersek 
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Shenglei Zhang 
>> ---
>>  UefiCpuPkg/UefiCpuPkg.uni | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/UefiCpuPkg/UefiCpuPkg.uni b/UefiCpuPkg/UefiCpuPkg.uni index
>> b132ce62cf..0e57b6ac98 100644
>> --- a/UefiCpuPkg/UefiCpuPkg.uni
>> +++ b/UefiCpuPkg/UefiCpuPkg.uni
>> @@ -114,6 +114,10 @@
>>
>>  #string STR_gUefiCpuPkgTokenSpaceGuid_PcdCpuSmmStackSize_HELP
>> #language en-US "Specifies stack size in bytes for each processor in SMM."
>>
>> +#string STR_gUefiCpuPkgTokenSpaceGuid_PcdCpuSmmStackSize_PROMPT
>> #language en-US "Processor stack size in SMM."
>> +
>> +#string STR_gUefiCpuPkgTokenSpaceGuid_PcdCpuSmmStackSize_Help
>> #language en-US "Specifies stack size in bytes for each processor in SMM."
>> +
>>  #string
>> STR_gUefiCpuPkgTokenSpaceGuid_PcdCpuSmmApSyncTimeout_PROMPT
>> #language en-US "AP synchronization timeout value in SMM"
>>
>>  #string
>> STR_gUefiCpuPkgTokenSpaceGuid_PcdCpuSmmApSyncTimeout_HELP
>> #language en-US "Specifies timeout value in microseconds for the BSP in
>> SMM to wait for all APs to come into SMM."
>> --
>> 2.18.0.windows.1
> 

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

Re: [edk2] [PATCH] StdLib: Update resolv.conf to use Google's DNS servers

[Laszlo Ersek]

On 03/08/19 03:14, Rebecca Cran via edk2-devel wrote:
> The current servers listed appear to be unusable. I suspect most
> people will get correct DNS servers via DHCP, but the defaults
> should work for anyone.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Rebecca Cran 
> Reviewed-by: Jaben Carsey 
> Reviewed-by: Laszlo Ersek 
> ---
>  StdLib/Efi/StdLib/etc/resolv.conf | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/StdLib/Efi/StdLib/etc/resolv.conf 
> b/StdLib/Efi/StdLib/etc/resolv.conf
> index 3ac16ac230..724e6297b2 100644
> --- a/StdLib/Efi/StdLib/etc/resolv.conf
> +++ b/StdLib/Efi/StdLib/etc/resolv.conf
> @@ -1,13 +1,13 @@
>  #
>  #   Domain name
>  #
> -domain  intel.com
> +domain  example.com
>  
>  ;
>  ;   Name Servers
>  ;
> -nameserver  206.63.63.61
> -nameserver  216.251.100.1
> +nameserver  8.8.8.8
> +nameserver  8.8.4.4
>  
>  ; nameserver  10.248.2.1
>  ; nameserver  10.22.224.204
> 

Pushed as commit a24a37dba42c.

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

Re: [edk2] [PATCH] Maintainers.txt: clarify Reviewer requirements and responsibilities

[Laszlo Ersek]

On 02/27/19 22:21, Laszlo Ersek wrote:
> The current language for "Package Reviewer" only vaguely hints that
> Package Reviewers should be able to provide guidance and directions.
> Make this more obvious.
> 
> Cc: Andrew Fish 
> Cc: Ard Biesheuvel 
> Cc: Leif Lindholm 
> Cc: Liming Gao 
> Cc: Michael D Kinney 
> Cc: Philippe Mathieu-Daude 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Laszlo Ersek 
> ---
> 
> Notes:
> - this is clearly a political patch; feel free to disagree
> - I'm proposing this for the next development cycle
> 
>  Maintainers.txt | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/Maintainers.txt b/Maintainers.txt
> index 7772926b2fb1..ed090aeb4bdb 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -20,7 +20,10 @@ Descriptions of section entries:
>M: Package Maintainer: Cc address for patches and questions. Responsible
>   for reviewing and pushing package changes to source control.
>R: Package Reviewer: Cc address for patches and questions. Reviewers help
> - maintainers review code, but don't have push access.
> + maintainers review code, but don't have push access. A designated 
> Package
> + Reviewer is reasonably familiar with the Package (or some modules
> + thereof), and/or provides testing or regression testing for the Package
> + (or some modules thereof), in certain platforms and environments.
>W: Web-page with status/info
>T: SCM tree type and location.  Type is one of: git, svn.
>S: Status, one of the following:
> 

Thank you all for the feedback, this has been pushed as commit c9e1e28b6195.

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

Re: [edk2] [edk2-announce] EDK II Stable Tag edk2-stable201903 will be created based on commit 89910a

[Laszlo Ersek]

On 03/08/19 16:48, Gao, Liming wrote:
> Hi, all Sorry for a little late announce. I wait for some time to
> collect the feedback on the CEV fix. There is no rejection on CVE
> fix. So, I add it to this tag release. I will create
> edk2-stable201903 based on current edk2 trunk (commit 89910a
> MdeModulePkg/HiiImage: Fix stack overflow when corrupted BMP is
> parsed (CVE-2018-12181)) before PST time (UTC - 8) 12:00PM of
> 2019-03-08. If you have any comments, please reply the mail. If no
> concern or objection, I will create tag and send another announce
> mail that edk2-stable201903 is completed and normal commit is
> resumed.

Awesome, I can see the tag now. Thank you!
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [edk2-announce] Hard Feature Freeze starts from 2019-03-01(00:00:00 UTC-8) for edk2-stable201903

[Laszlo Ersek]

On 03/08/19 15:30, Tian, Hot wrote:
> For this specific question from Laszlo, I do not have strong recommendation. 
> Liming/Laszlo can work out a recommendation.
> But looking at https://github.com/tianocore/tianocore.github.io/wiki/EDK-II, 
> I do have recommendation to make UDK less prominent (e.g. remove "UDK 
> Releases" section) as we've migrated to quarterly stable tag release model on 
> edk2 master.

Well, I'm not sure if my suggestion is logical, but given that I was
staring at
<https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planning>
when I got lost :) , I think it might help if the "current release
planning" page simply featured a link to "past releases".

The latter can be a standalone wiki page or even a section in a larger page.


Considering the sum of the currently available notes, the inconsistency
is that

- for the first tag we had ("edk2-stable201808"), we seem to offer no
notes (that's OK, we had just started back then);

- for the second tag ("edk2-stable201811"), the notes are at:

https://github.com/tianocore/edk2/releases/tag/edk2-stable201811

which was edited... I got no clue where (certainly not in the edk2-wiki);

- and for the upcoming tag, we have the notes at:

https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Notes#edk2-stable201903-tag

Thanks,
Laszlo


> -Original Message-
> From: Richardson, Brian 
> Sent: Friday, March 08, 2019 22:19
> To: Tian, Hot ; Tian, Hot ; Laszlo 
> Ersek ; Gao, Liming ; 
> edk2-devel@lists.01.org
> Subject: RE: [edk2] [edk2-announce] Hard Feature Freeze starts from 
> 2019-03-01(00:00:00 UTC-8) for edk2-stable201903
> 
> Hot: it looks like we need to revise the wiki page so the stable tag & 
> release notes links are more prominent. Any recommendations on changes?
> 
> Thanks ... br
> ---
> Brian Richardson -- Director, Firmware Ecosystem Development 
> brian.richard...@intel.com -- @intel_brian (Twitter & WeChat) 
> https://software.intel.com/en-us/meet-the-developers/evangelists/team/brian-richardson
>  
> 
> -Original Message-
> From: edk2-devel  On Behalf Of Tian, Hot
> Sent: Friday, March 8, 2019 8:48 AM
> To: Tian, Hot ; Laszlo Ersek ; Gao, 
> Liming ; edk2-devel@lists.01.org
> Subject: Re: [edk2] [edk2-announce] Hard Feature Freeze starts from 
> 2019-03-01(00:00:00 UTC-8) for edk2-stable201903
> 
> I guess 
> https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Notes is 
> also for future release notes. Seems it's not listed on 
> https://github.com/tianocore/tianocore.github.io/wiki/EDK-II.
> 
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Tian, 
> Hot
> Sent: Friday, March 08, 2019 21:38
> To: Laszlo Ersek ; Gao, Liming ; 
> edk2-devel@lists.01.org
> Subject: Re: [edk2] [edk2-announce] Hard Feature Freeze starts from 
> 2019-03-01(00:00:00 UTC-8) for edk2-stable201903
> 
> Hi Laszlo,
> 
> You can find the permanent release notes on 
> https://github.com/tianocore/tianocore.github.io/wiki/EDK-II:
> Under Stable Tags session: 
> https://github.com/tianocore/edk2/releases/tag/edk2-stable201811
> https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planning 
> is for Future Release and Tag Planning.
> 
> Thanks,
> Hot
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo 
> Ersek
> Sent: Friday, March 08, 2019 17:00
> To: Gao, Liming ; edk2-devel@lists.01.org
> Subject: Re: [edk2] [edk2-announce] Hard Feature Freeze starts from 
> 2019-03-01(00:00:00 UTC-8) for edk2-stable201903
> 
> Hi Liming,
> 
> On 03/01/19 09:57, Gao, Liming wrote:
>> Hi, all
>>   Today, we enter into Hard Feature Freeze phase until edk2-stable201903 tag 
>> is created at 2019-03-08. In this phase, there is no feature to be pushed. 
>> The bug fix is still allowed. 
> 
> I meant to ask you about permanent links to already released stable tags, in 
> the Wiki. For example, we have:
> 
> https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Notes#edk2-stable201903-tag
> 
> but we don't seem to have one for the previous stable tag 
> (edk2-stable201811). Which is strange because I remember that we collected 
> the changes for that release too, in the wiki.
> 
> ... Ah, I see it now. The problem is with Wiki commit 63a756e8a134
> ("edk2 wiki: remove edk2-stable201811 tag planning in 
> EDK-II-Release-Planning", 2018-12-10). The content was removed completely.
> 
> For example, if I grep the wiki (currently at commit 664b82ca9684) for 
> "id=1213", there are no hits. That means people cannot l

Re: [edk2] UefiCpuPkg CpuDxe GDT init question?

[Laszlo Ersek]

On 03/08/19 15:13, Yao, Jiewen wrote:
> I guess the historic reason is that AP and BSP share same GDT before. As 
> such, the GDT need to be below 4G, to let AP switch from real mode to 
> protected mode.
> We don't get issue, because Runtime memory is in BIN, and most platform 
> allocates BIN under 4G.
> 
> Some thought:
> 1) I am think we not sure if AP is using same GDT as BSP today. If yes, we 
> need GDT under 4G, by using MaxAddress. If no, there should be no restriction 
> for BSP GDT. The (UINT32) case should be removed for BSP. But we still AP GDT 
> below 4G, to support wake from INIT-SIPI-SIPI.
> 2) I am not sure why we need runtime memory. Do we need touch GDT at UEFI 
> runtime?

I could be confusing things *very badly*, but I vaguely remember that
APs could be woken up spuriously later, and they must be able to execute
code "enough" to go back to sleep.

The following commits look relevant:

- 7615702169b8 ("UefiCpuPkg/MpInitLib: Add AsmRelocateApLoop() assembly
code", 2016-08-17)

- 4d3314f69488 ("UefiCpuPkg/MpInitLib: Place APs in safe loop before
hand-off to OS", 2016-08-17)

- bf2786dc7900 ("UefiCpuPkg/DxeMpLib: Allocate new safe stack < 4GB",
2016-11-28)

Laszlo

> 
> 
> 
> Thank you
> Yao Jiewen
> 
> 
>> -----Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Laszlo Ersek
>> Sent: Friday, March 8, 2019 12:00 AM
>> To: Andrew Fish ; edk2-devel 
>> Subject: Re: [edk2] UefiCpuPkg CpuDxe GDT init question?
>>
>> Hi Andrew,
>>
>> On 03/07/19 23:37, Andrew Fish via edk2-devel wrote:
>>> I'm trying to understand why gdtPtr.Base is casting to (UINT32)?
>>> 1) gdtPtr.Base is a a UINTN
>>> 2) It is legal for AllocateRuntimePool() to return an address > 4GB
>>>
>>> It seems like the code should just cast to (UINTN)?
>>>
>>>
>>>
>> https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/CpuDxe/CpuG
>> dt.c#L151
>>
>> I think you are right.
>>
>> I'm missing the background on this too. I tried to see if any
>> justification was given in a git commit message, but according to "git
>> blame", this code dates back to the original addition of the driver,
>> namely commit a47463f28382 ("Add CPU DXE driver for IA32 & X64
>> processor
>> architectures.", 2009-05-27). The commit message is unhelpful (for 3119
>> lines added).
>>
>> Thanks
>> Laszlo
>>
>>>
>>>
>>>
>>> VOID
>>> InitGlobalDescriptorTable (
>>>   VOID
>>>   )
>>> {
>>>   GDT_ENTRIES *gdt;
>>>   IA32_DESCRIPTOR gdtPtr;
>>>
>>>   //
>>>   // Allocate Runtime Data for the GDT
>>>   //
>>>   gdt = AllocateRuntimePool (sizeof (GdtTemplate) + 8);
>>>   ASSERT (gdt != NULL);
>>>   gdt = ALIGN_POINTER (gdt, 8);
>>>
>>>   //
>>>   // Initialize all GDT entries
>>>   //
>>>   CopyMem (gdt, , sizeof (GdtTemplate));
>>>
>>>   //
>>>   // Write GDT register
>>>   //
>>>   gdtPtr.Base = (UINT32)(UINTN)(VOID*) gdt;
>>>   gdtPtr.Limit = (UINT16) (sizeof (GdtTemplate) - 1);
>>>   AsmWriteGdtr ();
>>>
>>> Thanks,
>>>
>>> Andrew Fish
>>> ___
>>> edk2-devel mailing list
>>> edk2-devel@lists.01.org
>>> https://lists.01.org/mailman/listinfo/edk2-devel
>>>
>>
>> ___
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel

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

Re: [edk2] [PATCH v2 0/2] Fix bugs in HiiDatabase driver

[Laszlo Ersek]

On 03/08/19 09:52, Laszlo Ersek wrote:
> On 03/08/19 07:41, Gao, Liming wrote:
>> This is to fix the security issue. I agree it is an import bug fix. I am OK 
>> to push it for edk2-stable201903 tag
> 
> Me too.
> 
> If we had stable *branches* (as opposed to just stable tags), then we
> wouldn't have to delay the stable tag (the release) -- we'd just apply
> the CVE fix to both the master branch (*after* the stable tag) and on
> the stable branch too. But our development workflow isn't there yet, so
> I guess we can delay the stable tag a bit more. I suggest updating the
> date in
> <https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planning#edk2-stable201903-tag-planning>.

Is there anything else blocking the tag, at the moment?

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

Re: [edk2] [PATCH] Maintainers.txt: remove unexpected unicode BOM

[Laszlo Ersek]

On 03/08/19 10:07, Wang, Jian J wrote:
> Pushed at c2c4b919caa297fbe83f02b897c125b87eb1fd58
> 
> Regards,
> Jian

(I didn't ignore the fixup patch, I was just busy with something else.)

Thanks for this!
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] StdLib: Update resolv.conf to use Google's DNS servers

[Laszlo Ersek]

On 03/08/19 03:14, Rebecca Cran via edk2-devel wrote:
> The current servers listed appear to be unusable. I suspect most
> people will get correct DNS servers via DHCP, but the defaults
> should work for anyone.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Rebecca Cran 
> Reviewed-by: Jaben Carsey 
> Reviewed-by: Laszlo Ersek 
> ---
>  StdLib/Efi/StdLib/etc/resolv.conf | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/StdLib/Efi/StdLib/etc/resolv.conf 
> b/StdLib/Efi/StdLib/etc/resolv.conf
> index 3ac16ac230..724e6297b2 100644
> --- a/StdLib/Efi/StdLib/etc/resolv.conf
> +++ b/StdLib/Efi/StdLib/etc/resolv.conf
> @@ -1,13 +1,13 @@
>  #
>  #   Domain name
>  #
> -domain  intel.com
> +domain  example.com
>  
>  ;
>  ;   Name Servers
>  ;
> -nameserver  206.63.63.61
> -nameserver  216.251.100.1
> +nameserver  8.8.8.8
> +nameserver  8.8.4.4
>  
>  ; nameserver  10.248.2.1
>  ; nameserver  10.22.224.204
> 

Thanks! Looks good. We should push this soon, after the
edk2-stable201903 tag is made. Jaben, please let me know if you need me
to push this.

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

Re: [edk2] [edk2-announce] Hard Feature Freeze starts from 2019-03-01(00:00:00 UTC-8) for edk2-stable201903

[Laszlo Ersek]

Hi Liming,

On 03/01/19 09:57, Gao, Liming wrote:
> Hi, all
>   Today, we enter into Hard Feature Freeze phase until edk2-stable201903 tag 
> is created at 2019-03-08. In this phase, there is no feature to be pushed. 
> The bug fix is still allowed. 

I meant to ask you about permanent links to already released stable
tags, in the Wiki. For example, we have:

https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Notes#edk2-stable201903-tag

but we don't seem to have one for the previous stable tag
(edk2-stable201811). Which is strange because I remember that we
collected the changes for that release too, in the wiki.

... Ah, I see it now. The problem is with Wiki commit 63a756e8a134
("edk2 wiki: remove edk2-stable201811 tag planning in
EDK-II-Release-Planning", 2018-12-10). The content was removed completely.

For example, if I grep the wiki (currently at commit 664b82ca9684) for
"id=1213", there are no hits. That means people cannot learn (or make
references to) the fact, in the Wiki, that the edk2-stable201811 release
fixed TianoCore#1213.

In my opinion, we should rather move that kind of content to a permanent
Release Notes article in the Wiki.

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

Re: [edk2] [PATCH v2 0/2] Fix bugs in HiiDatabase driver

[Laszlo Ersek]

On 03/08/19 07:41, Gao, Liming wrote:
> This is to fix the security issue. I agree it is an import bug fix. I am OK 
> to push it for edk2-stable201903 tag

Me too.

If we had stable *branches* (as opposed to just stable tags), then we
wouldn't have to delay the stable tag (the release) -- we'd just apply
the CVE fix to both the master branch (*after* the stable tag) and on
the stable branch too. But our development workflow isn't there yet, so
I guess we can delay the stable tag a bit more. I suggest updating the
date in
.

Thanks!
Laszlo

>> -Original Message-
>> From: Wang, Jian J
>> Sent: Thursday, March 7, 2019 7:17 PM
>> To: Ni, Ray ; edk2-devel@lists.01.org
>> Cc: Cetola, Stephano ; Gao, Liming 
>> 
>> Subject: RE: [edk2] [PATCH v2 0/2] Fix bugs in HiiDatabase driver
>>
>> Hi all,
>>
>> This is a very important fix for this issue. If no objection, I'd like the 
>> patch be part of this stable tag.
>>
>>
>> As to this patch series,
>>
>> Reviewed-by: Jian J Wang 
>>
>>
>>> -Original Message-
>>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ray 
>>> Ni
>>> Sent: Friday, March 08, 2019 10:35 AM
>>> To: edk2-devel@lists.01.org
>>> Subject: [edk2] [PATCH v2 0/2] Fix bugs in HiiDatabase driver
>>>
>>> v2: put the CVE number in patch title.
>>>
>>> Ray Ni (2):
>>>   MdeModulePkg/HiiDatabase: Fix potential integer overflow
>>> (CVE-2018-12181)
>>>   MdeModulePkg/HiiImage: Fix stack overflow when corrupted BMP is parsed
>>> (CVE-2018-12181)
>>>
>>>  MdeModulePkg/Universal/HiiDatabaseDxe/Image.c | 130 ++
>>>  1 file changed, 105 insertions(+), 25 deletions(-)
>>>
>>> --
>>> 2.20.1.windows.1
>>>
>>> ___
>>> edk2-devel mailing list
>>> edk2-devel@lists.01.org
>>> https://lists.01.org/mailman/listinfo/edk2-devel

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

Re: [edk2] [Patch] Maintainers.txt: Change package maintainer and reviewer of SecurityPkg.

[Laszlo Ersek]

On 03/08/19 03:56, Zhang, Chao B wrote:
> Cc: Yao Jiewen 
> Cc: Jian Wang 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Zhang, Chao B 
> ---
>  Maintainers.txt | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/Maintainers.txt b/Maintainers.txt
> index 7772926b2f..08a676b236 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -1,6 +1,6 @@
> -EDK II Maintainers
> +EDK II Maintainers
>  ==

This hunk (which is now part of commit 6c05b958df53) is incorrect. It
adds a UTF-8 BOM to the beginning of the file.

Please remove the BOM urgently, before the stable tag.

Thanks
Laszlo

>  
>  This file provides information about the primary maintainers for
>  EDK II.
>  
> @@ -237,10 +237,11 @@ M: Kelly Steele 
>  
>  SecurityPkg
>  W: https://github.com/tianocore/tianocore.github.io/wiki/SecurityPkg
>  M: Chao Zhang 
>  M: Jiewen Yao 
> +M: Jian Wang 
>  
>  ShellBinPkg
>  W: https://github.com/tianocore/tianocore.github.io/wiki/ShellPkg
>  M: Jaben Carsey   (Ia32/X64)
>  M: Ray Ni   (Ia32/X64)
> 

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

Re: [edk2] UefiCpuPkg CpuDxe GDT init question?

[Laszlo Ersek]

Hi Andrew,

On 03/07/19 23:37, Andrew Fish via edk2-devel wrote:
> I'm trying to understand why gdtPtr.Base is casting to (UINT32)? 
> 1) gdtPtr.Base is a a UINTN
> 2) It is legal for AllocateRuntimePool() to return an address > 4GB
> 
> It seems like the code should just cast to (UINTN)?
> 
> 
> https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/CpuDxe/CpuGdt.c#L151

I think you are right.

I'm missing the background on this too. I tried to see if any
justification was given in a git commit message, but according to "git
blame", this code dates back to the original addition of the driver,
namely commit a47463f28382 ("Add CPU DXE driver for IA32 & X64 processor
architectures.", 2009-05-27). The commit message is unhelpful (for 3119
lines added).

Thanks
Laszlo

> 
> 
> 
> VOID
> InitGlobalDescriptorTable (
>   VOID
>   )
> {
>   GDT_ENTRIES *gdt;
>   IA32_DESCRIPTOR gdtPtr;
> 
>   //
>   // Allocate Runtime Data for the GDT
>   //
>   gdt = AllocateRuntimePool (sizeof (GdtTemplate) + 8);
>   ASSERT (gdt != NULL);
>   gdt = ALIGN_POINTER (gdt, 8);
> 
>   //
>   // Initialize all GDT entries
>   //
>   CopyMem (gdt, , sizeof (GdtTemplate));
> 
>   //
>   // Write GDT register
>   //
>   gdtPtr.Base = (UINT32)(UINTN)(VOID*) gdt;
>   gdtPtr.Limit = (UINT16) (sizeof (GdtTemplate) - 1);
>   AsmWriteGdtr ();
> 
> Thanks,
> 
> Andrew Fish
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
> 

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

Re: [edk2] [PATCH v2] UefiCpuPkg\CpuSmm: Save & restore CR2 on-demand paging in SMM

[Laszlo Ersek]

On 03/07/19 12:14, nkvangup wrote:
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1593
> 
> For every SMI occurrence, save and restore CR2 register only when SMM
> on-demand paging support is enabled in 64 bit operation mode.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Vanguput Narendra K 
> Cc: Eric Dong 
> Cc: Ray Ni 
> Cc: Laszlo Ersek 
> Cc: Yao Jiewen 
> ---
>  UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c | 20 
>  1 file changed, 12 insertions(+), 8 deletions(-)

(1) There is an open question about the usefulness of this patch in
<https://bugzilla.tianocore.org/show_bug.cgi?id=1593#c1>. It should be
answered in the BZ, or the same description should be included in the
commit message.

(2) Also, the commit message should refer to the BZ.


> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> index 3b0b3b52ac..5be4a2b020 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> @@ -,10 +,12 @@ SmiRendezvous (
>  
>ASSERT(CpuIndex < mMaxNumberOfCpus);
>  
> -  //
> -  // Save Cr2 because Page Fault exception in SMM may override its value
> -  //
> -  Cr2 = AsmReadCr2 ();
> +  if ((sizeof (UINTN) == sizeof (UINT64)) && (!PcdGetBool 
> (PcdCpuSmmStaticPageTable))) {

(3) It doesn't look like a good idea to me to call PcdGetBool() in the
SmiRendezvous() function.

If the PCD is not fixed-at-build (but dynamic), then we'll end up
calling a PI protocol member from a function that is by definition
executed by multiple processors at the same time.

"X64/PageTbl.c" already defines the global variable
"mCpuSmmStaticPageTable", setting it from the PCD on the call stack of
the entry point function of the driver. That is safe -- we can call PI /
UEFI protocols in the entry point functions of a DXE_SMM_DRIVER.

Now, the fact that "mCpuSmmStaticPageTable" is only defined in the X64
build (that is, in "X64/PageTbl.c"), is actually quite informative. It
means that, instead of this conditional code in "MpService.c", we should
introduce two new helper functions, "SaveCr2" and "RestoreCr2". And we
should provide separate implementations for IA32 and X64. For IA32, the
function should do nothing. For X64, the function should depend on
"mCpuSmmStaticPageTable", and massage CR2 as necessary.

However: that *still* depends on whether this change is useful. I
realize the CR2 manipulation may not be overly useful on IA32 (we can't
address >4GB memory, so demand paging for >4GB makes no sense), but its
performance hit should be negligible. Again, back to point (1): what is
the actual issue with the current code?

Thanks
Laszlo

> +//
> +// Save Cr2 because Page Fault exception in SMM may override its value
> +//
> +Cr2 = AsmReadCr2 ();
> +  }
>  
>//
>// Perform CPU specific entry hooks
> @@ -1253,10 +1255,12 @@ SmiRendezvous (
>  
>  Exit:
>SmmCpuFeaturesRendezvousExit (CpuIndex);
> -  //
> -  // Restore Cr2
> -  //
> -  AsmWriteCr2 (Cr2);
> +  if ((sizeof (UINTN) == sizeof (UINT64)) && (!PcdGetBool 
> (PcdCpuSmmStaticPageTable))) {
> +//
> +// Restore Cr2
> +//
> +AsmWriteCr2 (Cr2);
> +  }
>  }
>  
>  /**
> 

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

Re: [edk2] [Patch] UefiCpuPkg/MpInitLib: Direct allocate buffer for Wake up Buffer.

[Laszlo Ersek]

On 03/07/19 03:53, Dong, Eric wrote:
> Hi Star,
> 
> This logic seems much complicated than mine. Also after CSM retired from 
> EDKII, we will change this code back to only require allocate buffer below 
> 1M. I will add such notes in the code comments.  So I prefer to use my change.

I apologize for my inability to follow the recent developments in this
thread. However, what I recall is that we may not retire the CSM from
edk2 entirely. Instead, if someone volunteers to maintain the CSM under
OvmfPkg for example, then we'll keep it there.

Personally I'm not interested in the CSM, but it would be nice if we
didn't implement logic in UefiCpuPkg that would be, by design,
incompatible with an optional feature that we might carry forward in
OvmfPkg.

Thanks
Laszlo

> Thanks,
> Eric
> 
>> -Original Message-
>> From: Zeng, Star
>> Sent: Tuesday, March 5, 2019 3:33 PM
>> To: Dong, Eric ; edk2-devel@lists.01.org
>> Cc: Ni, Ray ; Laszlo Ersek (ler...@redhat.com)
>> ; Zeng, Star 
>> Subject: RE: [edk2] [Patch] UefiCpuPkg/MpInitLib: Direct allocate buffer for
>> Wake up Buffer.
>>
>> Just an idea to avoid hard code value 0x88000.
>>
>> Before EndOfDxe: Allocate buffer in AllocateResetVector(), and free buffer
>> in FreeResetVector().
>> At EndOfDxe (it is after LegacyBiosDxe driver entry point) callback: Allocate
>> buffer and record it to CpuMpData->WakeupBuffer, and always occupy the
>> buffer, that means no free.
>> After EndOfDxe: Use CpuMpData->WakeupBuffer.
>>
>>
>> Thanks,
>> Star
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Eric Dong
>> Sent: Tuesday, March 5, 2019 10:07 AM
>> To: edk2-devel@lists.01.org
>> Subject: [edk2] [Patch] UefiCpuPkg/MpInitLib: Direct allocate buffer for
>> Wake up Buffer.
>>
>> https://bugzilla.tianocore.org/show_bug.cgi?id=1538
>>
>> Current CpuDxe driver "borrows" Wakeup Buffer (through Allocate & free to
>> get the buffer pointer, backup the buffer data before using it and restore it
>> after using).  Now this logic met a problem described in the above BZ
>> because the test tool and the CpuDxe both use the same memory at the
>> same time.
>>
>> In order to fix the above issue, CpuDxe changed to allocate the buffer below
>> 1M instead of borrow it. After investigation, we found below
>> 0x88000 is the possible space which can be used. For now, range
>> 0x6 ~ 0x88000 used for Legacy OPROMs by LegacyBios driver. And it tries
>> to allocate these range page(4K size) by page. It just reports warning
>> message if specific page been used by others already.
>>
>> Also CpuDxe driver will produce CPU arch protocol and LegacyBios driver has
>> dependency for this protocol. So CpuDxe driver will start before LegacyBios
>> driver and CpuDxe driver can allocate that space successful.
>>
>> With this change, CpuDxe driver will use 0x87000 ~ 0x88000 as wakeup buffer.
>>
>> Cc: Ray Ni 
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Eric Dong 
>> ---
>>  UefiCpuPkg/Library/MpInitLib/DxeMpLib.c | 30 +++
>> ---
>>  1 file changed, 19 insertions(+), 11 deletions(-)
>>
>> diff --git a/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
>> b/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
>> index b2307cbb61..5bc9a47efb 100644
>> --- a/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
>> +++ b/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
>> @@ -76,7 +76,7 @@ SaveCpuMpData (
>>  }
>>
>>  /**
>> -  Get available system memory below 1MB by specified size.
>> +  Get available system memory below 0x88000 by specified size.
>>
>>@param[in] WakeupBufferSize   Wakeup buffer size required
>>
>> @@ -91,7 +91,19 @@ GetWakeupBuffer (
>>EFI_STATUS  Status;
>>EFI_PHYSICAL_ADDRESSStartAddress;
>>
>> -  StartAddress = BASE_1MB;
>> +  //
>> +  // Current "Borrow" space mechanism caused potential race condition
>> + if both  // AP and the original owner use the share space.
>> +  //
>> +  // LegacyBios driver tries to allocate 4K pages between 0x6 ~
>> + 0x88000  // space. It will just report an waring message if the page
>> + has been allocate  // by other drivers.
>> +  // LagacyBios driver depends on CPU Arch protocol, so it will start
>> + after  // CpuDxe driver which produce Cpu Arch Protocol and use this
>> library.
>> +  // So below allocate logic will be trigged before LegacyBios driver
>> + and it  // w

Re: [edk2] [PATCH 00/10] Remove .S files for IA32 and X64 arch in MdePkg and UefiCpuPkg

[Laszlo Ersek]

Hi,

On 03/07/19 03:30, Shenglei Zhang wrote:
> .nasm file has been added for X86 arch. .S assembly code
> is not required any more.
> https://bugzilla.tianocore.org/show_bug.cgi?id=1594
> 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Eric Dong 
> Cc: Ray Ni 
> Cc: Laszlo Ersek 
> Shenglei Zhang (10):
>   UefiCpuPkg/SmmCpuFeaturesLib: Remove .S files for IA32 and X64 arch
>   UefiCpuPkg/BaseUefiCpuLib: Remove .S files for IA32 and X64 arch
>   UefiCpuPkg/CpuExceptionHandlerLib:Remove.S files for IA32 and X64 arch

Thanks for the CC; I'll skip this review, and defer to Eric, Mike and Ray.

Laszlo

>   MdePkg/BaseCpuLib: Remove .S files for IA32 and X64 arch
>   MdePkg/BaseLib: Remove .S files for IA32 and X64 arch
>   MdePkg/BaseMemoryLibMmx: Remove .S files for IA32 and X64 arch
>   MdePkg/BaseMemoryLibOptDxe: Remove .S files for IA32 and X64 arch
>   MdePkg/BaseMemoryLibOptPei: Remove .S files for IA32 and X64 arch
>   MdePkg/BaseMemoryLibRepStr: Remove .S files for IA32 and X64 arch
>   MdePkg/BaseMemoryLibSse2: Remove .S files for IA32 and X64 arch


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

Re: [edk2] [PATCH RESEND 3/3] OvmfPkg/XenSupport: turn off address decoding before BAR sizing

[Laszlo Ersek]

On 03/06/19 15:26, Igor Druzhinin wrote:
> On 06/03/2019 13:22, Laszlo Ersek wrote:
>> On 03/06/19 13:40, Igor Druzhinin wrote:
>>> On Xen, hvmloader firmware leaves address decoding enabled for
>>> enumerated PCI device before jumping into OVMF. OVMF seems to
>>> expect it to be disabled and tries to size PCI BARs in several places
>>> without disabling it which causes BAR64, for example, being
>>> incorrectly placed by QEMU.
>>>
>>> Fix it by disabling PCI address decoding explicitly before the
>>> first attempt to size BARs on Xen.
>>>
>>> Contributed-under: TianoCore Contribution Agreement 1.1
>>> Signed-off-by: Igor Druzhinin 
>>> ---
>>>  OvmfPkg/Library/PciHostBridgeLib/XenSupport.c | 34 
>>> +++
>>>  1 file changed, 34 insertions(+)
>>>
>>> diff --git a/OvmfPkg/Library/PciHostBridgeLib/XenSupport.c 
>>> b/OvmfPkg/Library/PciHostBridgeLib/XenSupport.c
>>> index 408fb24..9940335 100644
>>> --- a/OvmfPkg/Library/PciHostBridgeLib/XenSupport.c
>>> +++ b/OvmfPkg/Library/PciHostBridgeLib/XenSupport.c
>>> @@ -55,6 +55,33 @@ PcatPciRootBridgeBarExisted (
>>>EnableInterrupts ();
>>>  }
>>>  
>>> +#define EFI_PCI_COMMAND_DECODE ((UINT16)(EFI_PCI_COMMAND_IO_SPACE | \
>>> + EFI_PCI_COMMAND_MEMORY_SPACE))
>>
>> I thought I asked you not to define a macro here that started with the
>> "EFI_" prefix :/
>>
>> dd8e3c9e-cb76-d3fe-6a10-c0a41c714b56@redhat.com">http://mid.mail-archive.com/dd8e3c9e-cb76-d3fe-6a10-c0a41c714b56@redhat.com
>>
> 
> This is a resend of v1 patch series to get Xen folks into CC and gather
> comments. I expect v2.

My bad, thanks for the clarification. On edk2-devel we very rarely post
RESENDs without updates, and so I missed the implications now.

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

Re: [edk2] [PATCH RESEND 3/3] OvmfPkg/XenSupport: turn off address decoding before BAR sizing

[Laszlo Ersek]

On 03/06/19 13:40, Igor Druzhinin wrote:
> On Xen, hvmloader firmware leaves address decoding enabled for
> enumerated PCI device before jumping into OVMF. OVMF seems to
> expect it to be disabled and tries to size PCI BARs in several places
> without disabling it which causes BAR64, for example, being
> incorrectly placed by QEMU.
> 
> Fix it by disabling PCI address decoding explicitly before the
> first attempt to size BARs on Xen.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Igor Druzhinin 
> ---
>  OvmfPkg/Library/PciHostBridgeLib/XenSupport.c | 34 
> +++
>  1 file changed, 34 insertions(+)
> 
> diff --git a/OvmfPkg/Library/PciHostBridgeLib/XenSupport.c 
> b/OvmfPkg/Library/PciHostBridgeLib/XenSupport.c
> index 408fb24..9940335 100644
> --- a/OvmfPkg/Library/PciHostBridgeLib/XenSupport.c
> +++ b/OvmfPkg/Library/PciHostBridgeLib/XenSupport.c
> @@ -55,6 +55,33 @@ PcatPciRootBridgeBarExisted (
>EnableInterrupts ();
>  }
>  
> +#define EFI_PCI_COMMAND_DECODE ((UINT16)(EFI_PCI_COMMAND_IO_SPACE | \
> + EFI_PCI_COMMAND_MEMORY_SPACE))

I thought I asked you not to define a macro here that started with the
"EFI_" prefix :/

dd8e3c9e-cb76-d3fe-6a10-c0a41c714b56@redhat.com">http://mid.mail-archive.com/dd8e3c9e-cb76-d3fe-6a10-c0a41c714b56@redhat.com

Laszlo

> +STATIC
> +VOID
> +PcatPciRootBridgeDecoding (
> +  IN  UINTN  Address,
> +  IN  BOOLEANEnabled,
> +  OUT UINT16 *OriginalValue
> +  )
> +{
> +  UINT16Value;
> +
> +  //
> +  // Preserve the original value
> +  //
> +  Value = *OriginalValue;
> +  *OriginalValue = PciRead16 (Address);
> +
> +  if (!Enabled) {
> +if (*OriginalValue & EFI_PCI_COMMAND_DECODE)
> +   PciWrite16 (Address, *OriginalValue & ~EFI_PCI_COMMAND_DECODE);
> +  } else {
> +if (Value & EFI_PCI_COMMAND_DECODE)
> +  PciWrite16 (Address, Value);
> +  }
> +}
> +
>  STATIC
>  VOID
>  PcatPciRootBridgeParseBars (
> @@ -76,6 +103,7 @@ PcatPciRootBridgeParseBars (
>UINT32Value;
>UINT32OriginalUpperValue;
>UINT32UpperValue;
> +  UINT16OriginalCommand;
>UINT64Mask;
>UINTN Offset;
>UINT64Base;
> @@ -83,6 +111,12 @@ PcatPciRootBridgeParseBars (
>UINT64Limit;
>PCI_ROOT_BRIDGE_APERTURE  *MemAperture;
>  
> +  // Disable address decoding for every device before OVMF starts sizing it
> +  PcatPciRootBridgeDecoding (
> +PCI_LIB_ADDRESS (Bus, Device, Function, PCI_COMMAND_OFFSET),
> +FALSE, 
> +  );
> +
>for (Offset = BarOffsetBase; Offset < BarOffsetEnd; Offset += sizeof 
> (UINT32)) {
>  PcatPciRootBridgeBarExisted (
>PCI_LIB_ADDRESS (Bus, Device, Function, Offset),
> 

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

Re: [edk2] [PATCH 0/3] Xen PCI passthrough fixes

[Laszlo Ersek]

Hi Igor,

On 03/04/19 16:04, Igor Druzhinin wrote:
> Igor Druzhinin (3):
>   OvmfPkg/XenSupport: remove usage of prefetchable PCI host bridge
> aperture
>   OvmfPkg/XenSupport: use a correct PCI host bridge aperture for BAR64
>   OvmfPkg/XenSupport: turn off address decoding before BAR sizing
> 
>  OvmfPkg/Library/PciHostBridgeLib/XenSupport.c | 44 
> ++-
>  1 file changed, 37 insertions(+), 7 deletions(-)
> 

thank you for the patches! I'll let our Xen reviewers check and approve
them.

For patch#3, I have one suggestion: please don't #define macros that
start with EFI_ but are not directly related to the UEFI, PI, PCI etc
standards. If you think the helper macro is suitable for general use and
it actually corresponds to ideas from e.g. the PCI standard(s), then
yoou might want to suggest the macro in a separate patch for e.g.
"MdePkg/Include/IndustryStandard/Pci22.h". (Adding Ray.)

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

Re: [edk2] [RFC 0/3] Enable runtime serial debug for ArmVirtQemu

[Laszlo Ersek]

On 03/01/19 16:09, Peter Maydell wrote:
> On Fri, 1 Mar 2019 at 14:59, Laszlo Ersek  wrote:
>>
>> +Peter
>>
>> On 03/01/19 13:24, Heyi Guo wrote:
>>> On 2019/2/28 21:39, Laszlo Ersek wrote:
>>
>>>> (4) What's most worrying is that this change would lead to an unexpected
>>>> sharing of the PL011 device between the OS and the firmware. I don't
>>>> think that's a great idea, especially if QEMU's ACPI payload explicitly
>>>> advertises the port to the OS.
>>> That's true, so I propose to disable the feature by default. It is only
>>> used for UEFI runtime code debug. It is always painful when we don't a
>>> handy debug tool for runtime services code.
>>
>> I think this is the only problem that we have at the design level.
>>
>> What I'd like to understand is whether it is safe to drive the PL011
>> serial port from both the firmware and the kernel.
> 
> I would suggest that it probably is not safe. Certainly it
> does not seem likely to be robust against all possible future
> changes to the kernel's driver and/or the firmware's driver.
> 
>> This is why I'm not a big fan of this approach. Using separate devices
>> for kernel and firmware would be a lot better.
>>
>> I remember that Peter did some work to enable two PL011 devices on the
>> "virt" board. IIRC the issue was that the PL011 enumeration order /
>> numbering in edk2, and in the Linux (guest) kernel, was exactly the
>> opposite. And that caused both logs to go to different devices; you
>> couldn't have a single log file that started with the firmware log, and
>> continued (after a definite switch-over) with the kernel log.
> 
> Yes, that's basically it (I forget the exact details and it's the
> kind of thing that may well depend on exactly what version of the
> kernel or what version of the firmware you were using). I do still
> have a todo list item to add a 2nd UART (probably "if the user
> specifically asked for it with an extra -serial option"), but
> we can't just add it to the board by default.

Thanks for the info!

> Note that if you are using QEMU under emulation where it is emulating
> EL3 then you always get a second UART which is visible only to the
> secure world. This is specifically intended for firmware to use.

The ArmVirtQemu firmware doesn't handle the secure world at all (yet?).

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

Re: [edk2] [Patch v2 4/4] UefiCpuPkg/RegisterCpuFeaturesLib: Correct comments.

[Laszlo Ersek]

On 03/01/19 06:39, Eric Dong wrote:
> Cc: Ray Ni 
> Cc: Laszlo Ersek 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Eric Dong 
> ---
>  UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git 
> a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c 
> b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c
> index 3e8e899766..a78ef44491 100644
> --- a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c
> +++ b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c
> @@ -1174,8 +1174,8 @@ PreSmmCpuRegisterTableWrite (
>@param[in]  CpuBitMaskSize  The size of CPU feature bit mask buffer
>@param[in]  Feature The bit number of the CPU feature
>  
> -  @retval  TRUE   The CPU feature is set in PcdCpuFeaturesSupport.
> -  @retval  FALSE  The CPU feature is not set in PcdCpuFeaturesSupport.
> +  @retval  TRUE   The CPU feature is set in CpuBitMask.
> +  @retval  FALSE  The CPU feature is not set in CpuBitMask.
>  
>  **/
>  BOOLEAN
> 

Okay, this patch is simple enough, and I vaguely remember that I
suggested it.

Reviewed-by: Laszlo Ersek 

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

Re: [edk2] [Patch v2 0/4] Simplify CPU Features solution.

[Laszlo Ersek]

Hi Eric,

On 03/01/19 06:39, Eric Dong wrote:
> V2 Changes include:
> 1. Add ASSERT to make sure PcdCpuFeaturesSetting and
>PcdCpuFeaturesCapability have equal size.
> 2. Correct comment block on IsCpuFeatureSetInCpuPcd() references
>"PcdCpuFeaturesSupport". It should reference "CpuBitMask".
> 
> V1 Changes includes:
> 1. Optimize PCD PcdCpuFeaturesUserConfiguration 
> 2. Limit useage of PcdCpuFeaturesSupport 
> 3. Remove some useless APIs.
> Detail explanation please check each patch's introduction.
> 
> Cc: Ray Ni 
> Cc: Laszlo Ersek 
> Eric Dong (4):
>   UefiCpuPkg/RegisterCpuFeaturesLib: Remove useless functions.
>   UefiCpuPkg/RegisterCpuFeaturesLib: Optimize PCD 
> PcdCpuFeaturesUserConfiguration.
>   UefiCpuPkg/RegisterCpuFeaturesLib: Simplify PcdCpuFeaturesSupport.
>   UefiCpuPkg/RegisterCpuFeaturesLib: Correct comments.
> 
>  .../Include/Library/RegisterCpuFeaturesLib.h   |  34 --
>  .../RegisterCpuFeaturesLib/CpuFeaturesInitialize.c | 114 
> ++---
>  .../DxeRegisterCpuFeaturesLib.inf  |   3 +-
>  .../PeiRegisterCpuFeaturesLib.inf  |   3 +-
>  .../RegisterCpuFeaturesLib/RegisterCpuFeatures.h   |   2 -
>  .../RegisterCpuFeaturesLib.c   |  64 ++--
>  UefiCpuPkg/UefiCpuPkg.dec  |   9 +-
>  7 files changed, 45 insertions(+), 184 deletions(-)
> 

sorry, I'm overloaded. Given that the platforms that I co-maintain don't
use RegisterCpuFeaturesLib, I'd like to skip the v2 review.

Please remember to push this series *after* the edk2-stable201903 tag is
made. Because this is not a bugfix.

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

Re: [edk2] [RFC 0/3] Enable runtime serial debug for ArmVirtQemu

[Laszlo Ersek]

+Peter, for the last few paragraphs

On 02/28/19 13:10, Ard Biesheuvel wrote:
> On Thu, 28 Feb 2019 at 09:06, Heyi Guo  wrote:
>>
>> Serial port output is useful when debugging UEFI runtime services in OS 
>> runtime.
>> The patches are trying to provide a handy method to enable runtime serial 
>> port
>> debug for ArmVirtQemu.
>>
>> Cc: Jian J Wang 
>> Cc: Hao Wu 
>> Cc: Laszlo Ersek 
>> Cc: Ard Biesheuvel 
>> Cc: Julien Grall 
>>
>> Heyi Guo (3):
>>   MdeModulePkg/StatusCode: Add PCD to enable runtime serial debug
>>   ArmVirtPkg: add runtime instance of FdtPL011SerialPortLib
>>   ArmVirtQemu: enable runtime debug by build flag
>>
> 
> Hello Heyi,
> 
> We have had this discussion before, and IIRC, the proposed solution
> was to use status codes.
> 
> I'm not sure how that is supposed to work though - hopefully Laszlo or
> one of the MdeModulePkg maintainers can elaborate.

Here's the basic idea.

Status Code reporting and routing are defined by the PI spec for OS
runtime as well, not just boot time.

Recently we added status code *routing* to ArmVirtPkg, in commit
5c574b222ec2, via the generic runtime driver
"ReportStatusCodeRouterRuntimeDxe". We also added the library resolution

ReportStatusCodeLib -->
MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf

(for some module types). As a result, when modules of those types report
status codes, they now reach the ReportStatusCodeRouterRuntimeDxe
driver, which "routes" the status codes.

In the same series, we also modified ArmVirtPkg's PlatformBootManagerLib
(built into BdsDxe) to register a status code *handler* callback with
ReportStatusCodeRouterRuntimeDxe -- but only for boot time (not
runtime), and only for a very specific group of status codes. As a
result, when a module of suitable type reports a status code,
ReportStatusCodeRouterRuntimeDxe "routes it" to BdsDxe, and then BdsDxe
"handles it" (in our implementation, we simply format it to the UEFI
console), assuming the status code is the kind we are interested in.


Now we come to the current series. First, the series adds the following
DebugLib class resolution:

DebugLib -->
MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/PeiDxeDebugLibReportStatusCode.inf

This will cause modules to publish their DEBUG messages as status codes
via ReportStatusCodeLib, rather than log them via SerialPortLib. (I'm
too lazy to check the exact status code classes etc that
PeiDxeDebugLibReportStatusCode embeds the DEBUG messages into.) As a
result, DEBUG messages will reach ReportStatusCodeRouterRuntimeDxe for
"routing". As another result, until we reach a late enough stage in the
boot, those messages will not be printed by anything (because there's
not going to be any "handling" for them).

(The present series also updates the ReportStatusCodeLib resolution so
it can be used at runtime too, but that's quite auxiliary to this
discussion.)

Second, this series includes the generic Status Code *handling* driver
(also a runtime driver): "StatusCodeHandlerRuntimeDxe". Independently of
the particular handling that we already have in BdsDxe via the earlier
series, this generic status handler driver registers a handler callback
that simply prints status codes to the serial port (dependent on a PCD
setting), via SerialPortLib.

With the modification from the first patch, this generic status code
*handler* driver is extended to runtime serial port operation. And, the
second patch in the series provides a SerialPortLib instance for it that
can work at runtime.

All in all, when a runtime driver calls DEBUG, this happens:

  runtime driver calls DEBUG
  -> PeiDxeDebugLibReportStatusCode
-> RuntimeDxeReportStatusCodeLib
   [status code reporting]

=> ReportStatusCodeRouterRuntimeDxe
   [status code routing]

=> StatusCodeHandlerRuntimeDxe
   [status code handling, such as SerialPortWrite():]
  -> FdtPL011SerialPortLibRuntime

This is actually a good idea, but it would be nice if:
- QEMU had two PL011 ports,
- the boot time firmware log, and the OS log, went to one port
- the runtme firmware log went to the other port.

Given that this series provides the SerialPortLib instance for
StatusCodeHandlerRuntimeDxe anyway, we could implement it so that it
locate a "special" PL011 in QEMU's DTB -- the port that we'd only use
for runtime firmware logging.

I don't insist that this series implement all of that, but it should
either prevent a conflict on the one PL011 between the firmware and the
OS, or else be very explicit about the possible conflict in the commit
messages.

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

Re: [edk2] [RFC 0/3] Enable runtime serial debug for ArmVirtQemu

[Laszlo Ersek]

+Peter

On 03/01/19 13:24, Heyi Guo wrote:
> On 2019/2/28 21:39, Laszlo Ersek wrote:

>> (4) What's most worrying is that this change would lead to an unexpected
>> sharing of the PL011 device between the OS and the firmware. I don't
>> think that's a great idea, especially if QEMU's ACPI payload explicitly
>> advertises the port to the OS.
> That's true, so I propose to disable the feature by default. It is only
> used for UEFI runtime code debug. It is always painful when we don't a
> handy debug tool for runtime services code.

I think this is the only problem that we have at the design level.

What I'd like to understand is whether it is safe to drive the PL011
serial port from both the firmware and the kernel. Consider a situation
where one VCPU in the guest executes a runtime service call, and writes
to PL011 from firmware code. Meanwhile a different VCPU in the guest
executes some kernel code that produces a log message directly on the
serial console. (Because, I don't think that a runtime service call on
one CPU stops the world for *all* CPUs, in the Linux kernel.) For
starters, the serial output could be garbled, as a consequence, but will
the PL011 register state be messed up irrevocably as well? I don't know.

This is why I'm not a big fan of this approach. Using separate devices
for kernel and firmware would be a lot better.

I remember that Peter did some work to enable two PL011 devices on the
"virt" board. IIRC the issue was that the PL011 enumeration order /
numbering in edk2, and in the Linux (guest) kernel, was exactly the
opposite. And that caused both logs to go to different devices; you
couldn't have a single log file that started with the firmware log, and
continued (after a definite switch-over) with the kernel log.

But in this case, where the firmware could produce log messages on
serial during OS runtime, that's actually the setup I would recommend. A
clean separation between the serial devices used by the firmware and the OS.

The rest of the issues in this series should be more simple to clean up
(rework some commit messages, remove stale code etc).

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

Re: [edk2] [PATCH 2] UefiCpuPkg: restore strict page attributes via #DB in nonstop mode only

[Laszlo Ersek]

On 03/01/19 04:26, Wang, Jian J wrote:
> Thanks. To catch cold freeze, pushed earlier 
> (2a9324cfca12c66f13a41d52fb0a82fb924e)

This is definitely a bugfix, so it is eligible for pushing.

Thanks
Laszlo

>> -Original Message-
>> From: Dong, Eric
>> Sent: Friday, March 01, 2019 9:55 AM
>> To: Wang, Jian J ; edk2-devel@lists.01.org
>> Cc: Ni, Ray ; Laszlo Ersek ; Zeng, Star
>> 
>> Subject: RE: [edk2] [PATCH 2] UefiCpuPkg: restore strict page attributes via 
>> #DB
>> in nonstop mode only
>>
>> Reviewed-by: Eric Dong 
>>
>>> -Original Message-
>>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>>> Jian J Wang
>>> Sent: Friday, March 1, 2019 8:58 AM
>>> To: edk2-devel@lists.01.org
>>> Cc: Ni, Ray ; Laszlo Ersek ; Dong,
>>> Eric ; Zeng, Star 
>>> Subject: [edk2] [PATCH 2] UefiCpuPkg: restore strict page attributes via #DB
>>> in nonstop mode only
>>>
>>>> v2: Per Laszlo's comments, repack origianl two patches into one with
>>>> title changed and relevant commits added
>>>
>>> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1576
>>>
>>> The root cause of this issue is that non-stop mode of Heap Guard and NULL
>>> Detection set TF bit (single-step) in EFLAG unconditionally in the common
>>> handler in CpuExceptionLib.
>>>
>>> If PcdCpuSmmStaticPageTable is FALSE, the SMM will only create page table
>>> for memory below 4G. If SMM tries to access memory beyond 4G, a page
>>> fault exception will be triggered and the memory to access will be added to
>>> page table so that SMM code can continue the access.
>>>
>>> Because of above issue, the TF bit is set after the page fault is handled 
>>> and
>>> then fall into another DEBUG exception. Since non-stop mode of Heap Guard
>>> and NULL Detection are not enabled, no special DEBUG exception handler is
>>> registered. The default handler just prints exception context and go into
>>> dead loop.
>>>
>>> Actually EFLAGS can be changed in any standard exception handler.
>>> There's no need to do single-step setup in assembly code. So the fix is to
>>> move the logic to C code part of page fault exception handler so that we can
>>> fully validate the configuration and prevent TF bit from being set
>>> unexpectedly.
>>>
>>> Fixes: dcc026217fdc363f55c217039fc43d344f69fed6
>>>16b918bbaf51211a32ae04d9d8a5ba6ccca25a6a
>>> Test:
>>>  - Pass special test of accessing memory beyond 4G in SMM mode
>>>  - Boot to OS with Qemu emulator platform (Fedora27, Ubuntu18.04,
>>>Windows7, Windows10)
>>>
>>> Cc: Eric Dong 
>>> Cc: Laszlo Ersek 
>>> Cc: Ruiyu Ni 
>>> Cc: Star Zeng 
>>> Contributed-under: TianoCore Contribution Agreement 1.1
>>> Signed-off-by: Jian J Wang 
>>> Acked-by: Laszlo Ersek 
>>> ---
>>>  UefiCpuPkg/CpuDxe/CpuPageTable.c  | 11 ++-
>>>  .../Ia32/ExceptionHandlerAsm.nasm |  7 ---
>>>  .../X64/ExceptionHandlerAsm.nasm  |  4 
>>>  3 files changed, 10 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/UefiCpuPkg/CpuDxe/CpuPageTable.c
>>> b/UefiCpuPkg/CpuDxe/CpuPageTable.c
>>> index 4bee8c7772..812537417d 100644
>>> --- a/UefiCpuPkg/CpuDxe/CpuPageTable.c
>>> +++ b/UefiCpuPkg/CpuDxe/CpuPageTable.c
>>> @@ -1300,7 +1300,16 @@ PageFaultExceptionHandler (
>>>// Display ExceptionType, CPU information and Image information
>>>//
>>>DumpCpuContext (ExceptionType, SystemContext);
>>> -  if (!NonStopMode) {
>>> +  if (NonStopMode) {
>>> +//
>>> +// Set TF in EFLAGS
>>> +//
>>> +if (mPagingContext.MachineType == IMAGE_FILE_MACHINE_I386) {
>>> +  SystemContext.SystemContextIa32->Eflags |= (UINT32)BIT8;
>>> +} else {
>>> +  SystemContext.SystemContextX64->Rflags |= (UINT64)BIT8;
>>> +}
>>> +  } else {
>>>  CpuDeadLoop ();
>>>}
>>>  }
>>> diff --git
>>> a/UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ExceptionHandlerAsm.
>>> nasm
>>> b/UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ExceptionHandlerAsm.
>>> nasm
>>> index 6fcf5fb23f..45d6474091 100644
>>> ---
>>> a/UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ExceptionH

Re: [edk2] [edk2-announce] Soft Feature Freeze starts today for edk2-stable201903

[Laszlo Ersek]

On 03/01/19 02:15, Gao, Liming wrote:
> OK. To be clear, I take your suggestion. wiki page has been updated. 

Looks great, thank you!
Laszlo

> 
>> -Original Message-----
>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>> Sent: Thursday, February 28, 2019 7:58 PM
>> To: Gao, Liming 
>> Cc: edk2-devel@lists.01.org
>> Subject: Re: [edk2] [edk2-announce] Soft Feature Freeze starts today for 
>> edk2-stable201903
>>
>> On 02/28/19 03:22, Gao, Liming wrote:
>>
>>> I update wiki page 
>>> https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planning
>>>  with UTC zone.
>>> I think the nature time of day is the begin time of one day. 00:00:00 
>>> should be common sense. We may not highlight it.
>>
>> I disagree: many organizations use "start of business" (e.g. 9AM) or
>> "end of business" (e.g. 5PM) as "common sense" deadlines, on any given date.
>>
>> I think it's a really simple update. Just replace, in the header,
>>
>>   Date(UTC-8)
>>
>> with
>>
>>   Date (00:00:00 UTC-8)
>>
>> That should suffice.
>>
>> Thanks
>> Laszlo

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