Re: [edk2] [PATCH v3 04/52] UefiCpuPkg: CpuDxe: broadcast MTRR changes to APs

On 10/16/15 23:17, Kinney, Michael D wrote: > Laszlo, > > Here is a proposed fix on top of your v3 patch services to address a > race condition that was introduced by the v3 patch series call to > StartupAllAPs() with SingleThread set to TRUE in the MP > initialization. If the APs have not entere

[edk2] How do you compile EDK2 git repo on Windows ?

I've asked a similar question before for Linux:Re: [edk2] Is edk2 broken for linux GCC Compile ? |   | |   | |   |   |   |   |   | | Re: [edk2] Is edk2 broken for linux GCC Compile ?On 09/03/15 05:42, Shubha Ramani wrote:> I grabbed the latest code from github, See below. But it seems like lin

[edk2] [PATCH 1/1] AppPkg: Allow interactive Python on platforms without STDERR

AppPkg: Python, as distributed, sends its prompts and other interactive output to stderr, which uses the platforms STDERR device for output. If STDERR output is not visible, it may appear that Python has hung. Several people have reported problems on platforms that don't enable STDERR. These inc

Re: [edk2] [PATCH v3 04/52] UefiCpuPkg: CpuDxe: broadcast MTRR changes to APs

Laszlo, Here is a proposed fix on top of your v3 patch services to address a race condition that was introduced by the v3 patch series call to StartupAllAPs() with SingleThread set to TRUE in the MP initialization. If the APs have not entered their idle loop before StartupAllAPs() is called, t

Re: [edk2] [PATCH v3 51/52] OvmfPkg: double the SMRAM (TSEG) size for the 64-bit DXE phase builds

On 10/16/15 22:50, Kinney, Michael D wrote: > Laszlo, > > The PCD setting for TSEG size needs to be set for both IA32 and X64 modules > in OvmfPkg/OvmfPkgIa32X64.dsc. > The this current patch, TSEG PCD is set to DEC default value for PEIMs of 1MB > and 2MB for DXE/SMM phase. > This causes SMM

Re: [edk2] [PATCH v3 51/52] OvmfPkg: double the SMRAM (TSEG) size for the 64-bit DXE phase builds

Laszlo, The PCD setting for TSEG size needs to be set for both IA32 and X64 modules in OvmfPkg/OvmfPkgIa32X64.dsc. The this current patch, TSEG PCD is set to DEC default value for PEIMs of 1MB and 2MB for DXE/SMM phase. This causes SMM Core to only see 1MB SMRAM area. I found this when trying

Re: [edk2] [PATCH 0/2] OvmfPkg: VirtioScsiDxe, VirtioBlkDxe: reset device at ExitBootServices()

On 10/16/15 21:25, Jordan Justen wrote: > Series Reviewed-by: Jordan Justen Greatly appreciated! Lately I've been trying to do too many things again, and being allowed to flush some of them quickly helps significantly. Committed to SVN as revs 18623 & 18624. Cheers! Laszlo > On 2015-10-16 04:2

Re: [edk2] [PATCH 0/2] OvmfPkg: VirtioScsiDxe, VirtioBlkDxe: reset device at ExitBootServices()

Series Reviewed-by: Jordan Justen On 2015-10-16 04:25:52, Laszlo Ersek wrote: > I've been aware for a while that I should have added such callbacks to > the virtio-blk and virtio-scsi drivers too. Because there had been no > error reports, I could convince myself to code them up only now, due to

Re: [edk2] [PATCH v3 03/52] UefiCpuPkg: PiSmmCpuDxeSmm: do not execute RSM from 64-bit mode

On 10/16/15 18:39, Kinney, Michael D wrote: > Paolo, > > Thanks for the reference. We believe this is a document issue. > > We would prefer to drop this patch. I'm unsure if that will require another KVM patch, but given that the original code runs on phys hardware alright, and the patch is for

Re: [edk2] KVM: MTRR: fix memory type handling if MTRR is completely disabled

On 10/16/15 05:05, Xiao Guangrong wrote: > > > On 10/16/2015 12:18 AM, Laszlo Ersek wrote: >> CC'ing Jordan and Chen Fan. >> >> On 10/15/15 09:10, Xiao Guangrong wrote: >>> >>> >>> On 10/15/2015 02:58 PM, Janusz wrote: W dniu 15.10.2015 o 08:41, Xiao Guangrong pisze: > > > On 10/

Re: [edk2] [PATCH v2 14/16] UefiCpuPkg: Add PiSmmCpuDxeSmm module no IA32/X64 files

On 10/15/15 01:26, Michael Kinney wrote: > Add module that initializes a CPU for the SMM environment and > installs the first level SMI handler. This module along with the > SMM IPL and SMM Core provide the services required for > DXE_SMM_DRIVERS to register hardware and software SMI handlers. >

Re: [edk2] [PATCH v2 13/16] UefiCpuPkg: Update DEC/DSC files for new includes and libraries

One comment below: On 10/15/15 01:26, Michael Kinney wrote: > Add SmmCpuPlatformHookLib library class declaration > Add SmmCpuFeaturesLib library class declaration > Add gEfiSmmCpuServiceProtocolGuid protocol declaration > Build SmmCpuPlatformHookLibNull library instance > Build SmmCpuFeaturesLib

Re: [edk2] [PATCH v2 11/16] UefiCpuPkg: Add ACPI CPU Data include file

On 10/15/15 01:26, Michael Kinney wrote: > Add AcpuCpuData.h that defines a data structure that is shared between > modules and is required for ACPI S3 support. > APState field removed between V1 and V2 patch. > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Michael Kin

Re: [edk2] [PATCH v2 00/16] UefiCpuPkg: Add CPU SMM and SecCore

On 10/15/15 01:26, Michael Kinney wrote: > Public branch: I diffed this against my own CRLF-ization of your v1 patches, plus two patches applied ("UefiCpuPkg: CpuDxe: Fix ASSERT() when only 1 CPU detected", "UefiCpuPkg: PiSmmCpuDxeSmm: pr

Re: [edk2] [PATCH] OvmfPkg: Sec: Fix SOURCE_DEBUG_ENABLE ASSERT()

On 10/15/15 00:18, Michael Kinney wrote: > The update to the LocalApicLib instances to make sure the > Local APIC is initialize before use generates an ASSERT() > when SOURCE_DEBUG_ENABLE is enabled for OVMF. > > The fix is to initialize the Local APIC Timer and mask it > before initialing the Deb

Re: [edk2] [PATCH v3 03/52] UefiCpuPkg: PiSmmCpuDxeSmm: do not execute RSM from 64-bit mode

Paolo, Thanks for the reference. We believe this is a document issue. We would prefer to drop this patch. Thanks, Mike >-Original Message- >From: Paolo Bonzini [mailto:pbonz...@redhat.com] >Sent: Friday, October 16, 2015 1:38 AM >To: Yao, Jiewen; Fan, Jeff; Laszlo Ersek; edk2-de...@m

[edk2] [PATCHv2] ArmPlatformPkg/ArmJunoPkg correct ACPI tables

v2 Removed mali definition as its not been completely tested yet. v1 This set of patches updates the ACPI tables for the JunoR1 in keeping with recent changes to the linux kernel. These changes allow both the RHEL and mainline kernels to boot with a functional USB and network adapter. Given the

[edk2] [PATCH] Update the ACPI device information for ARM Juno.

These patches correct a number of problems with the JUNO ACPI tables. First, put CCA attributes on the devices which can do DMA. This is because the linux kernel now requires ARM64 devices specify a coherency model. Without CCA the devices are unable to perform DMA. Update the EHCI window to a fu

Re: [edk2] [PATCH v2 0/8] serial and DEBUG output tweaks

On 10/14/15 14:30, Laszlo Ersek wrote: > Addressing v1 review feedback, and adding an early hello message for > ARM. Changes are noted per patch. > > Testing on Xen and/or physical ARM|AARCH64 platforms would be > appreciated. (The patches should be easy to apply from the mailing list > -- no new

Re: [edk2] [PATCHv2] ArmVirtPkg: include BaseStackCheckLib also for AARCH64

On 10/16/15 14:52, Mark Rutland wrote: > Some AArch64 toolchains also invoke the software stack checker > functions on certain code - so include BaseStackCheckLib for > AARCH64 as well as for ARM. Since this was the only difference > between [LibraryClasses.ARM] and [LibraryClasses.AARCH64], > merg

Re: [edk2] [PATCH] Update the ACPI device information for ARM Juno.

On 10/16/2015 09:19 AM, Leif Lindholm wrote: So ... I'm not sure there are any ACPI-aware drivers for the Mali bits yet - I would be happier to leave that out until we've verified it works. Could you resubmit with that single change please? Leif, I will pull them, those changes were a little

Re: [edk2] [PATCH] Update the ACPI device information for ARM Juno.

Hi Jeremy, Thanks for this. On Wed, Oct 14, 2015 at 10:10:06AM -0500, Jeremy Linton wrote: > These patches correct a number of problems with the JUNO ACPI tables. > > First, put CCA attributes on the devices which can do DMA. This is > because the linux kernel now requires ARM64 devices specify

Re: [edk2] [PATCH] [PATCH] ArmVirtPkg: include BaseStackCheckLib also for AARCH64

On Fri, Oct 16, 2015 at 12:48:37PM +0200, Laszlo Ersek wrote: > On 10/16/15 12:15, Mark Rutland wrote: > > Some AArch64 toolchains also invoke the software stack checker > > functions on certain code - so include BaseStackCheckLib for > > AARCH64 as well as for ARM. Since this was the only differen

[edk2] [PATCHv2] ArmVirtPkg: include BaseStackCheckLib also for AARCH64

Some AArch64 toolchains also invoke the software stack checker functions on certain code - so include BaseStackCheckLib for AARCH64 as well as for ARM. Since this was the only difference between [LibraryClasses.ARM] and [LibraryClasses.AARCH64], merge the two into the existing [LibraryClasses.commo

Re: [edk2] [PATCH 0/2] OvmfPkg: VirtioScsiDxe, VirtioBlkDxe: reset device at ExitBootServices()

On 10/16/15 13:25, Laszlo Ersek wrote: > I've been aware for a while that I should have added such callbacks to > the virtio-blk and virtio-scsi drivers too. Because there had been no > error reports, I could convince myself to code them up only now, due to >

[edk2] [PATCH 0/2] OvmfPkg: VirtioScsiDxe, VirtioBlkDxe: reset device at ExitBootServices()

I've been aware for a while that I should have added such callbacks to the virtio-blk and virtio-scsi drivers too. Because there had been no error reports, I could convince myself to code them up only now, due to . Cc: Jorda

[edk2] [PATCH 2/2] OvmfPkg: VirtioBlkDxe: reset device at ExitBootServices()

(1) VirtioLib allocates the virtio ring in EfiBootServicesData memory. (This is intentional.) Code that executes after ExitBootServices() is permitted to reuse such memory. (2) The hypervisor is allowed to look at, and act upon, a live virtio ring at any time, even without explicit vir

[edk2] [PATCH 1/2] OvmfPkg: VirtioScsiDxe: reset device at ExitBootServices()

(1) VirtioLib allocates the virtio ring in EfiBootServicesData memory. (This is intentional.) Code that executes after ExitBootServices() is permitted to reuse such memory. (2) The hypervisor is allowed to look at, and act upon, a live virtio ring at any time, even without explicit vir

Re: [edk2] [PATCH] [PATCH] ArmVirtPkg: include BaseStackCheckLib also for AARCH64

On Fri, Oct 16, 2015 at 12:48:37PM +0200, Laszlo Ersek wrote: > On 10/16/15 12:15, Mark Rutland wrote: > > Some AArch64 toolchains also invoke the software stack checker > > functions on certain code - so include BaseStackCheckLib for > > AARCH64 as well as for ARM. Since this was the only differen

Re: [edk2] [PATCH] [PATCH] ArmVirtPkg: include BaseStackCheckLib also for AARCH64

On 10/16/15 12:15, Mark Rutland wrote: > Some AArch64 toolchains also invoke the software stack checker > functions on certain code - so include BaseStackCheckLib for > AARCH64 as well as for ARM. Since this was the only difference > between [LibraryClasses.ARM] and [LibraryClasses.AARCH64], > merg

[edk2] [PATCH] [PATCH] ArmVirtPkg: include BaseStackCheckLib also for AARCH64

Some AArch64 toolchains also invoke the software stack checker functions on certain code - so include BaseStackCheckLib for AARCH64 as well as for ARM. Since this was the only difference between [LibraryClasses.ARM] and [LibraryClasses.AARCH64], merge the two into a single [LibraryClasses.common].

Re: [edk2] List Archive

On 10/16/15 06:17, Narinder Dhillon wrote: > Where can I go to look at the old posts for this list ? In decreasing order of preference, and "chronological reach": - Current archive (for the 01.org-based list): http://news.gmane.org/gmane.comp.bios.edk2.devel - Recommended archive for the old (

Re: [edk2] [PATCH v3 03/52] UefiCpuPkg: PiSmmCpuDxeSmm: do not execute RSM from 64-bit mode

On 16/10/2015 09:41, Yao, Jiewen wrote: > Hello According to "IA32 SDM, page 1428, 4-330 Vol. 2B, RSM?Resume > from System Management Mode", I do not find word say: 64bit mode is > invalid. Would you please point out where you find "RSM is invalid in > 64-bit mode "? It's in the heading. It say

Re: [edk2] SMM core problems

Hi, Fist of all: I am DimitRi. UDK2014/UEFI 2.4 does not have EFI_PROPERTIES_TABLE feature. Anyway we have a bug by default. Collegue from Apple confirmed that os x boot loader move EfiRuntime memory to different physical address. I did not find in UEFI spec that it is prohibited. So we shoul

Re: [edk2] [PATCH v3 03/52] UefiCpuPkg: PiSmmCpuDxeSmm: do not execute RSM from 64-bit mode

Hello According to "IA32 SDM, page 1428, 4-330 Vol. 2B, RSM?Resume from System Management Mode", I do not find word say: 64bit mode is invalid. Would you please point out where you find "RSM is invalid in 64-bit mode "? === Operation ReturnFromSMM; IF (IA-32e mode supporte

Re: [edk2] [PATCH v3 03/52] UefiCpuPkg: PiSmmCpuDxeSmm: do not execute RSM from 64-bit mode

On 15/10/2015 03:31, Fan, Jeff wrote: > Ersek & Bonzini, > > From SDM 34.5.2, SMI Handler Operating Mode Switching. > "Any required change to operating mode is performed by the RSM instruction; > there is no need for the SMI > handler to change modes explicitly prior to executing RSM." > > So,