Re: [edk2] [Patch] UefiCpuPkg/MpInitLib: Optimize get processor number performance.

Jeff [mailto:vanjeff_...@hotmail.com] > Sent: Wednesday, July 4, 2018 5:39 PM > To: Dong, Eric ; edk2-devel@lists.01.org > Cc: Ni, Ruiyu ; Laszlo Ersek > Subject: 答复: [Patch] UefiCpuPkg/MpInitLib: Optimize get processor number > performance. > > > Eric, > > > &

Re: [edk2] [PATCH v2 1/1] MdeModulePkg/Variable: Check EFI_MEMORY_RUNTIME attribute before setting it

> Justen, Jordan L ; Laszlo Ersek > ; Zeng, Star > Subject: RE: [PATCH v2 1/1] MdeModulePkg/Variable: Check EFI_MEMORY_RUNTIME > attribute before setting it > > Reviewed-by: Star Zeng > > > Thanks, > Star > -Original Message- > From: Brijesh S

Re: [edk2] [PATCH v3 0/7] Add platform hook for ultimate boot failure.

Hi Ray, On 07/03/18 08:37, Ruiyu Ni wrote: > Ruiyu Ni (7): > MdeModulePkg/PlatformBootManager: Add PlatformBootManagerUnableToBoot > CorebootPayload/PlatformBDS: Impl PlatformBootManagerUnableToBoot > OvmfPkg/PlatformBds: Implement PlatformBootManagerUnableToBoot > Nt32Pkg/PlatformBDS:

Re: [edk2] [PATCH v3 3/7] OvmfPkg/PlatformBds: Implement PlatformBootManagerUnableToBoot

On 07/03/18 08:37, Ruiyu Ni wrote: > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ruiyu Ni > Cc: Jordan Justen > Cc: Laszlo Ersek > Cc: Ard Biesheuvel > Cc: Anthony Perard > Cc: Julien Grall > --- > .../Library/PlatformBootMana

Re: [edk2] [PATCH v3 7/7] MdeModulePkg/BdsDxe: Call PlatformBootManagerUnableToBoot()

On 07/03/18 08:37, Ruiyu Ni wrote: > When no boot option can be launched, BDS core calls > PlatformBootManagerUnableToBoot() to let platform BdsDxe handle it. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ruiyu Ni > Cc: Laszlo Ersek >

Re: [edk2] [PATCH v3 6/7] MdeModulePkg/BdsDxe: Revert "fall back to UI loop before hanging"

tformBootManagerUnableToBoot() is added, the commit > can be reverted. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ruiyu Ni > Cc: Eric Dong > Cc: Laszlo Ersek > --- > MdeModulePkg/Universal/BdsDxe/BdsEntry.c | 60 > +++-

Re: [edk2] [PATCH v3 1/7] MdeModulePkg/PlatformBootManager: Add PlatformBootManagerUnableToBoot

Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ruiyu Ni > Cc: Sean Brogan > Cc: Michael Turner > Cc: Laszlo Ersek > Cc: Sunny Wang > --- > MdeModulePkg/Include/Library/PlatformBootManagerLib.h | 13 + > .../PlatformBoot

Re: [edk2] [PATCH 2/2] OvmfPkg/QemuFlashFvbServicesRuntimeDxe: mark Runtime Data as MMIO when SEV is active

Hi Brijesh, On 07/03/18 05:11, Brijesh Singh wrote: > When SEV is active, the flash memory range is mapped as unencrypted by > AmdSevDxe. Mark the flash memory range with EfiGcdMemoryTypeMemoryMappedIo > so that OS maps this memory range as unencrypted. > > Cc: Justen Jordan

Re: [edk2] [PATCH] UefiCpuPkg/MpInitLib: Avoid calling PEI services from AP

gisters. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ruiyu Ni > Cc: Jeff Fan > Cc: Eric Dong > Cc: Jiewen Yao > Cc: Fish Andrew > Cc: Laszlo Ersek > --- > UefiCpuPkg/Library/MpInitLib/MpLib.c| 59 > +++-

Re: [edk2] [PATCH v3] UefiCpuPkg/MpInitLib: Avoid calling PEI services from AP

puMpData structure is stored just after IDT, the CpuMPData > address equals to IDTR.BASE + IDTR.LIMIT + 1. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ruiyu Ni > Cc: Jeff Fan > Cc: Eric Dong > Cc: Jiewen Yao > Cc: Fish Andrew > Cc: Laszlo

Re: [edk2] [PATCH] OvmfPkg/BDS: Provide platform callback for ultimate boot failure

Hi Ray, thanks a lot for this patch, I have some small logic requests: On 06/29/18 08:05, Ruiyu Ni wrote: > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ruiyu Ni > Cc: Laszlo Ersek > --- > .../Library/PlatformBootManagerLib/BdsPl

Re: [edk2] [PATCH v2 2/2] MdeModulePkg/BdsDxe: Call *UnableToBoot() for ultimate boot failure

oCore Contribution Agreement 1.1 > Signed-off-by: Ruiyu Ni > Cc: Sean Brogan > Cc: Michael Turner > Cc: Laszlo Ersek > Cc: Sunny Wang > --- > MdeModulePkg/Universal/BdsDxe/BdsEntry.c | 65 > +++- > 1 file changed, 13 insertions(+), 5

Re: [edk2] [PATCH v2 1/2] MdeModulePkg/UefiBootManagerLib: new APIs for ultimate boot failure

ations built into firmware > volumes, a platform callback registered through > EfiBootManagerRegisterUnableToBootHandler() is called. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ruiyu Ni > Cc: Sean Brogan > Cc: Michael Turner >

Re: [edk2] [Patch V2] UefiCpuPkg/MpInitLib: Remove redundant parameter.

Hi Eric, On 06/29/18 05:20, Eric Dong wrote: > Parameter StartCount duplicates with RunningCount. After this change, > RunningCount means the running AP count. > > V2 changes: Remove volatile for RunningCount. > > Done Test: > 1.PI SCT Test > 2.Boot OS / S3 > > Cc: Ruiyu Ni > Cc: Jeff Fan >

Re: [edk2] [Patch 2/2] UefiCpuPkg/MpInitLib: Remove redundant parameter.

On 06/29/18 03:48, Dong, Eric wrote: > Hi Laszlo, > >> -Original Message----- >> From: Laszlo Ersek [mailto:ler...@redhat.com] >> I'm currently missing a good understanding of how these counters are >> modified. They are all qualified "volatile",

Re: [edk2] [Patch 2/2] UefiCpuPkg/MpInitLib: Remove redundant parameter.

Hi Eric, On 06/28/18 13:29, Eric Dong wrote: > Parameter StartCount duplicates with RunningCount. After this change, > RunningCount means the running AP count. > > Done Tests: > 1.PI SCT Test > 2.Boot OS / S3 > > Cc: Ruiyu Ni > Cc: Jeff Fan > Cc: Laszlo Ersek

Re: [edk2] [PATCH] MdeModulePkg/UefiBootManagerLib: handle ultimate boot failure

On 06/28/18 11:02, Wang, Sunny (HPS SW) wrote: > Hi Ray, > > Does the ultimate boot failure include the case where the system > doesn't have "BootManagerMenu" application? If so, I think we should > move EfiBootManagerUnableBoot() call out of BdsBootManagerMenuLoop(). > The

Re: [edk2] [edk2 ] MS signed EFI Shell

On 06/28/18 12:09, vikash kumar wrote: > Hi all, > > From where I can download Microsoft's signed efi shell (Shellx64.efi)? You can't. The UEFI shell is a powerful tool that can do just about anything; in particular what it does is dicated by the shell scripts that it runs, and it might

Re: [edk2] [RFC PATCH 1/1] OvmfPkg/QemuFlash: Fix Runtime variable access when SEV is enabled

On 06/28/18 14:57, Laszlo Ersek wrote: > On 06/27/18 19:49, Brijesh Singh wrote: >> >> >> On 06/27/2018 11:59 AM, Laszlo Ersek wrote: >>> On 06/27/18 18:34, Brijesh Singh wrote: >>>> On 06/27/2018 07:54 AM, Laszlo Ersek wrote: >>>>>

Re: [edk2] [RFC PATCH 1/1] OvmfPkg/QemuFlash: Fix Runtime variable access when SEV is enabled

On 06/28/18 08:25, Zeng, Star wrote: > My understanding is MMIO is not managed by UEFI memory services, but GCD > services. > PI spec says " If the memory range specified by BaseAddress and Length is of > type EfiGcdMemoryTypeSystemMemory or EfiGcdMemoryTypeMoreReliable, then the > memory range

Re: [edk2] [RFC PATCH 1/1] OvmfPkg/QemuFlash: Fix Runtime variable access when SEV is enabled

platform as long as you never boot an OS / never call ExitBootServices(). In that case however, runtime aspects have no meaning at all. Thanks! Laszlo > > > Thanks, > Star > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Lasz

Re: [edk2] [RFC PATCH 1/1] OvmfPkg/QemuFlash: Fix Runtime variable access when SEV is enabled

On 06/27/18 19:49, Brijesh Singh wrote: > > > On 06/27/2018 11:59 AM, Laszlo Ersek wrote: >> On 06/27/18 18:34, Brijesh Singh wrote: >>> On 06/27/2018 07:54 AM, Laszlo Ersek wrote: >>>> On 06/26/18 21:46, Brijesh Singh wrote: >> >>>>> Af

Re: [edk2] [RFC PATCH 1/1] OvmfPkg/QemuFlash: Fix Runtime variable access when SEV is enabled

On 06/27/18 18:34, Brijesh Singh wrote: > On 06/27/2018 07:54 AM, Laszlo Ersek wrote: >> On 06/26/18 21:46, Brijesh Singh wrote: >>> After that, any access >>> to the flash will end up going through the encryption engine. I did try >>> hacking EDK2 to

Re: [edk2] [RFC PATCH 1/1] OvmfPkg/QemuFlash: Fix Runtime variable access when SEV is enabled

being mapped encrypted, and restoring the C-bit failing. (4) Whether we should modify MarkMemoryRangeForRuntimeAccess() to install the range into GCD as MMIO. (I feel *very* uncomfortable about this, however; the current code has existed as-is for years, and regressions look very

Re: [edk2] [PATCH] UefiCpuPkg/MpInitLib: AP uses memory preceding IDT to store CpuMpData

On 06/27/18 08:00, Ni, Ruiyu wrote: > On 6/27/2018 2:57 AM, Laszlo Ersek wrote: >> Second, even assuming that PushCpuMpData() and PopCpuMpData() are >> atomic, the order in which APs complete the AP procedure is not >> deterministic, and it need not be the exact reverse of t

Re: [edk2] [PATCH] UefiCpuPkg/MpInitLib: AP uses memory preceding IDT to store CpuMpData

On 06/26/18 19:20, Andrew Fish wrote: >> On Jun 26, 2018, at 10:06 AM, Laszlo Ersek wrote: >> On 06/25/18 04:54, Ruiyu Ni wrote: >>> Today's MpInitLib PEI implementation directly calls >>> PeiServices->GetHobList() from AP which may cause racing issue. &g

Re: [edk2] [PATCH] UefiCpuPkg/MpInitLib: AP uses memory preceding IDT to store CpuMpData

(replying again to the patch email directly, for keeping context -- adding some people to the CC list. Comments below.) On 06/25/18 04:54, Ruiyu Ni wrote: > Today's MpInitLib PEI implementation directly calls > PeiServices->GetHobList() from AP which may cause racing issue. > > This patch fixes

Re: [edk2] [PATCH] UefiCpuPkg/MpInitLib: AP uses memory preceding IDT to store CpuMpData

Hi Ray, On 06/26/18 09:50, Ni, Ruiyu wrote: > On 6/26/2018 1:01 AM, Laszlo Ersek wrote: >> On 06/25/18 18:01, Laszlo Ersek wrote: >>> Hello Ray, >>> >>> On 06/25/18 04:54, Ruiyu Ni wrote: >>>> Today's MpInitLib PEI implementation directly calls

Re: [edk2] [PATCH] UefiCpuPkg/MpInitLib: AP uses memory preceding IDT to store CpuMpData

On 06/25/18 18:01, Laszlo Ersek wrote: > Hello Ray, > > On 06/25/18 04:54, Ruiyu Ni wrote: >> Today's MpInitLib PEI implementation directly calls >> PeiServices->GetHobList() from AP which may cause racing issue. >> >> This patch fixes this issue by storing

Re: [edk2] [PATCH] UefiCpuPkg/MpInitLib: AP uses memory preceding IDT to store CpuMpData

Hello Ray, On 06/25/18 04:54, Ruiyu Ni wrote: > Today's MpInitLib PEI implementation directly calls > PeiServices->GetHobList() from AP which may cause racing issue. > > This patch fixes this issue by storing the CpuMpData to memory > preceding IDT. Pointer to PeiServices pointer is stored there,

Re: [edk2] [RFC] EDK II stable tag releases

On 06/25/18 01:07, Kinney, Michael D wrote: > Hello, > > This is a proposal for periodic stable tags on edk2 repositories. > > The goal is to produce a stable tag for edk2 repositories every 3 months > with the initial proposed dates of 8/10/2018 and 11/16/2018. Each release > is preceded by a

Re: [edk2] Query about variable initialization

On 06/20/18 20:03, Ard Biesheuvel wrote: > On 20 June 2018 at 19:48, Evan Lloyd wrote: >> Hi Ard, Leif. >> I've noticed a number of comments like Ard's recent "We don't permit >> initialized automatic variables.", >> and similar changes have been made to Sami's AcpiView. Note: I'm not >>

Re: [edk2] [PATCH] EmbeddedPkg/GdbSerialLib: avoid left shift of negative quantity

On 06/19/18 11:54, Leif Lindholm wrote: > On Tue, Jun 19, 2018 at 12:51:49AM +0200, Laszlo Ersek wrote: >> On 06/18/18 23:57, Leif Lindholm wrote: >>> On Mon, Jun 18, 2018 at 10:49:18PM +0200, Ard Biesheuvel wrote: >>>> Clang complains about left shifting a

Re: [edk2] [PATCH] EmbeddedPkg/GdbSerialLib: avoid left shift of negative quantity

On 06/18/18 23:57, Leif Lindholm wrote: > On Mon, Jun 18, 2018 at 10:49:18PM +0200, Ard Biesheuvel wrote: >> Clang complains about left shifting a negative value being undefined. > > As well it should. > >> EmbeddedPkg/Library/GdbSerialLib/GdbSerialLib.c:151:30: >> error: shifting a negative

Re: [edk2] [PATCH v2] MdeModulePkg: Enable SATA Controller PCI mem space

off-topic: On 06/15/18 16:13, Sami Mujawar wrote: > - Enable IO space, suggestion to use EFI_PCI_DEVICE_ENABLE[ZENG] My understanding is that "Star" is Star's given name, and "Zeng" is his surname. Let's not start calling each other by surname, shall we? (Email addresses under

Re: [edk2] [PATCH] BaseTools/tools_def IA32: drop -no-pie linker option for GCC49

lf32-i386 > -*_GCC49_IA32_DLINK2_FLAGS = DEF(GCC49_IA32_DLINK2_FLAGS) -no-pie > +*_GCC49_IA32_DLINK2_FLAGS = DEF(GCC49_IA32_DLINK2_FLAGS) > *_GCC49_IA32_RC_FLAGS = DEF(GCC_IA32_RC_FLAGS) > *_GCC49_IA32_OBJCOPY_FLAGS= > *_GCC49_IA32_NASM_FLAGS = -f el

Re: [edk2] [OvmfPkg] Secure Boot issues

On 06/18/18 14:14, Philipp Deppenwiese wrote: > Hey Laszlo, > > We guess that's an issue on our side because of some > NVRAM issues with VirtualBox. We located it through Windows 10 > debugging. Good job! :) > Thanks a lot for your support and testing! > > Maybe you are interested to join the

Re: [edk2] [OvmfPkg] Secure Boot issues

ce I installed the virtio-net driver). Thanks, Laszlo > On 13.06.2018 23:18, Laszlo Ersek wrote: >> On 06/13/18 21:41, Philipp Deppenwiese wrote: >>> Hey Laszlo, >>> >>> It's free for trial and available under: >>> >>> https://www.microso

Re: [edk2] [PATCH] UefiCpuPkg/LocalApicLib: Exclude second SendIpi sequence on AMD processors.

3,8 +685,10 @@ SendInitSipiSipiAllExcludingSelf ( >IcrLow.Bits.Level = 1; >IcrLow.Bits.DestinationShorthand = > LOCAL_APIC_DESTINATION_SHORTHAND_ALL_EXCLUDING_SELF; >SendIpi (IcrLow.Uint32, 0); > - MicroSecondDelay (200); > - SendIpi (IcrLow.Uint32, 0); > + if (!StandardS

Re: [edk2] [PATCH] UefiCpuPkg/LocalApicLib: Exclude second SendIpi sequence on AMD processors.

On 06/14/18 16:52, Andrew Fish wrote: > > >> On Jun 14, 2018, at 7:08 AM, Duran, Leo wrote: >> >> >> >>> -Original Message- >>> From: Laszlo Ersek mailto:ler...@redhat.com>> >>> Sent: Wednesday, June 13, 2018 3:50 PM >&

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

On 06/13/18 22:30, Ard Biesheuvel wrote: > On 13 June 2018 at 21:15, Laszlo Ersek wrote: >> On 06/13/18 21:03, Laszlo Ersek wrote: >>> On 06/13/18 20:20, Laszlo Ersek wrote: >>> >>>> * testing on aarch64/KVM: >>>> >>>> T

Re: [edk2] [OvmfPkg] Secure Boot issues

rtio-win driver CD (so that it could continue reading the virtio-scsi Windows installer ISO, post-EFI), at which point I forced off the VM. Nonetheless, until that point, everything seemed to work fine. Did you encounter the crash after that point, or before it? Thanks Laszlo > On 13.06.2018 2

Re: [edk2] [PATCH] UefiCpuPkg/LocalApicLib: Exclude second SendIpi sequence on AMD processors.

Hello Leo, On 06/13/18 22:11, Leo Duran wrote: > On AMD processors the second SendIpi in the SendInitSipiSipi and > SendInitSipiSipiAllExcludingSelf routines is not required, and may cause > undesired side-effects during MP initialization. > > This patch leverages the

Re: [edk2] [PATCH v2 1/2] UefiCpuPkg/CpuDxe: allow accessing (DXE) page table in SMM mode

On 06/13/18 17:14, Andrew Fish wrote: > > >> On Jun 12, 2018, at 10:35 PM, Jian J Wang wrote: >> >>> v2: >>> a. add more specific explanations in commit message >>> b. add more comments in code >>> c. remove redundant logic in IsInSmm() >>> d. fix a logic hole in GetCurrentPagingContext()

Re: [edk2] [OvmfPkg] Secure Boot issues

On 06/13/18 15:45, Philipp Deppenwiese wrote: > Hey Laszlo, > > We are using VirtualBox as virtualization solution and > don't load guest drivers. But we had the same issue with > the current Qemu version as well. > > Can you try to test your setup with the latest Windows 10 LTSB ? > That would

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

On 06/13/18 21:03, Laszlo Ersek wrote: > On 06/13/18 20:20, Laszlo Ersek wrote: > >> * testing on aarch64/KVM: >> >> The graphics output looks great as long as I'm in the UEFI shell / the >> setup TUI / the grub menu. However, once I boot a Fedora 28 Server >

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

On 06/13/18 20:20, Laszlo Ersek wrote: > * testing on aarch64/KVM: > > The graphics output looks great as long as I'm in the UEFI shell / the > setup TUI / the grub menu. However, once I boot a Fedora 28 Server > ISO, and the graphical Anacona Welcome screen appears, I get t

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

SICAL_ADDRESS FbBase; > - UINTN FbSize, MaxFbSize; > - UINTN FwCfgSize, Pages, Index; > + UINTN FbSize, MaxFbSize, Pages; > + UINTN FwCfgSize; > + UINTN Index; > >if (!Qe

Re: [edk2] [PATCH v2 1/2] UefiCpuPkg/CpuDxe: allow accessing (DXE) page table in SMM mode

xe > driver. If CpuDxe detects it's in SMM mode, it will use this global > variable to access page table instead of current processor registers. > This can avoid retrieving wrong DXE memory paging attributes and changing > SMM page table attributes unexpectedly. > > Cc: Eric Dong

Re: [edk2] [RFC PATCH 00/11] GCC/X64: use hidden visibility for LTO PIE code

e/x64-lto-visibility > > Cc: Michael D Kinney > Cc: Liming Gao > Cc: Ruiyu Ni > Cc: Hao Wu > Cc: Leif Lindholm > Cc: Jordan Justen > Cc: Andrew Fish > Cc: Star Zeng > Cc: Eric Dong > Cc: Laszlo Ersek > Cc: Zenith432 > Cc: "Shi, Steven&quo

Re: [edk2] [OvmfPkg] Secure Boot issues

On 06/12/18 16:51, Philipp Deppenwiese wrote: > Also Windows 10 in safe mode with secure boot works but not the > normal mode. > > We use the > 14393.0.160715-1616.RS1_RELEASE_CLIENTENTERPRISE_S_EVAL_X64 LTSB > release for testing. Interesting, this reminds me of the "new" driver signing

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

Hi Gerd, On 06/12/18 11:31, Gerd Hoffmann wrote: > Add a driver for the qemu ramfb display device. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Gerd Hoffmann > --- > OvmfPkg/QemuRamfbDxe/QemuRamfb.c | 396 > ++ >

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

lorerLib.inf > > PciPcdProducerLib|ArmVirtPkg/Library/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf > @@ -380,6 +381,7 @@ ># ># Video support ># > + OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf >OvmfPkg/VirtioGpuDxe/VirtioGpu.inf >OvmfPkg/PlatformDxe/Platform.inf > > 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 3/4] OvmfPkg: add QemuRamfb to platform console

+ 0, // Port > + 0// Index > + ), > + }, > + gEndEntire > +}; > + > // > // Predefined platform default console device path > // > @@ -113,6 +160,10 @@ PLATFORM_CONSOLE_CONNECT_ENTRY gPlatformCo

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

0x4d9c, {0x8a, > 0xe1, 0x8e, 0x09, 0x83, 0x75, 0x89, 0xd7}} >gRootBridgesConnectedEventGroupGuid = {0x24a2d66f, 0xeedd, 0x4086, {0x90, > 0x42, 0xf2, 0x6e, 0x47, 0x97, 0xee, 0x69}} > > Reviewed-by: Laszlo Ersek ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [OvmfPkg] Secure Boot issues

On 06/12/18 15:12, Philipp Deppenwiese wrote: > Hey people, > > We are experiencing issues with UEFI secure boot enabled > on UDK 2018 for the OvmfPkg. UDK2018 does not include OvmfPkg; no UDK does, to my knowledge. > Reproducible issue: > > 1) Add following code + files as dxe driver. >

Re: [edk2] [PATCH 1/2] UefiCpuPkg/CpuDxe: allow accessing (DXE) page table in SMM mode

On 06/12/18 10:44, Wang, Jian J wrote: > Hi Laszlo, thanks for the answers, they sound OK to me. From my side, please feel free to post v2. Thanks! Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org

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

On 06/12/18 11:15, Gerd Hoffmann wrote: > Hi, > >>> + { >>> +.HorizontalResolution = 640, >>> +.VerticalResolution= 480, >>> + },{ >>> +.HorizontalResolution = 800, >>> +.VerticalResolution= 600, >>> + },{ >>> +.HorizontalResolution = 1024, >>> +

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

On 06/12/18 11:21, Gerd Hoffmann wrote: > Hi, > >> - What happens in the UEFI shell if you do recursive connect/disconnect >> cycles for all handles in the system? (Preferably initiated from serial.) > > Seems to work fine (tried "disconnect -a" and "connect"). Cool. > >> - What happens if

Re: [edk2] [PATCH 1/2] UefiCpuPkg/CpuDxe: allow accessing (DXE) page table in SMM mode

On 06/12/18 06:32, Wang, Jian J wrote: > Hi Laszlo, > > Thank you very much for such thorough review. I'd like to explain a bit in > advance. > > Putting aside the specific coding issues in my patch, one thing is clear that > SMM mode > has its own page table. CpuDxe should not touch it even

Re: [edk2] [PATCH 1/2] UefiCpuPkg/CpuDxe: allow accessing (DXE) page table in SMM mode

e- > From: Zeng, Star > Sent: Tuesday, June 12, 2018 11:35 AM > To: Laszlo Ersek ; Wang, Jian J ; > edk2-devel@lists.01.org > Cc: Ni, Ruiyu ; Yao, Jiewen ; Dong, > Eric ; Zeng, Star > Subject: RE: [edk2] [PATCH 1/2] UefiCpuPkg/CpuDxe: allow accessing (DXE) page > tab

Re: [edk2] [PATCH v2] BaseTools/tools_def IA32: disable PIE code generation explicitly

locations) > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ard Biesheuvel > Acked-by: Laszlo Ersek > --- > BaseTools/Conf/tools_def.template | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a

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

On 06/11/18 18:24, Laszlo Ersek wrote: > On 06/08/18 13:39, Gerd Hoffmann wrote: >> Add QemuRamfbDxe device path to the list of platform console devices, >> so ConSplitter will pick up the device even though it isn't a PCI GPU. > > This explanation is not wrong, but I'll li

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

On 06/08/18 13:39, Gerd Hoffmann wrote: > This is the efi driver for qemu ramfb, a simple boot framebuffer. > Qemu patches just have been posted to qemu-devel. > > Gerd Hoffmann (4): > OvmfPkg: add QEMU_RAMFB_GUID > OvmfPkg: add QemuRamfbDxe > OvmfPkg: add QemuRamfb to platform console >

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

ion like that: Reviewed-by: Laszlo Ersek Thanks! Laszlo > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Gerd Hoffmann > --- > ArmVirtPkg/ArmVirtQemu.dsc | 2 ++ > ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc | 1 + > ArmVirtPkg/ArmVirtQemuKe

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

On 06/08/18 13:39, Gerd Hoffmann wrote: > Add QemuRamfbDxe device path to the list of platform console devices, > so ConSplitter will pick up the device even though it isn't a PCI GPU. This explanation is not wrong, but I'll list more details, just in case. By adding the devpath to

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

On 06/08/18 13:39, Gerd Hoffmann wrote: > diff --git a/OvmfPkg/QemuRamfbDxe/QemuRamfb.c > b/OvmfPkg/QemuRamfbDxe/QemuRamfb.c > new file mode 100644 > index 00..f04a314c24 > --- /dev/null > +++ b/OvmfPkg/QemuRamfbDxe/QemuRamfb.c > @@ -0,0 +1,308 @@ > +#include (1) I think we should be

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

Hi Gerd, On 06/08/18 13:39, Gerd Hoffmann wrote: > Add GUID header file for the QemuRamfbDxe driver. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Gerd Hoffmann > --- > OvmfPkg/Include/Guid/QemuRamfb.h | 25 + > OvmfPkg/OvmfPkg.dec

Re: [edk2] [PATCH 1/2] UefiCpuPkg/CpuDxe: allow accessing (DXE) page table in SMM mode

tp://mid.mail-archive.com/4A89E2EF3DFEDB4C8BFDE51014F606A14E22344D@SHSMSX104.ccr.corp.intel.com>. > Cc: Eric Dong > Cc: Laszlo Ersek > Cc: Jiewen Yao > Cc: Ruiyu Ni > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Jian J Wang > --- > UefiCpuPkg/CpuDxe/

Re: [edk2] [PATCH v3 1/2] MdePkg/BaseIoLibIntrinsic: make BaseIoLibIntrinsic safe for ArmVirt/KVM

mVirt.uni | 23 + > MdePkg/Library/BaseIoLibIntrinsic/IoLibArmVirt.c| 733 > ++++++++ > MdePkg/MdePkg.dsc | 1 + > 8 files changed, 1400 insertions(+) Acked-by: Laszlo Ersek ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Bug 843 - Need to remove unnecessary return statements in void functions of EDKII.

On 06/11/18 11:47, Laszlo Ersek wrote: > On 06/11/18 09:17, Mohammad Younas Khan Pathan wrote: > (4) Please split the patch to one patch per top-level directory. For > example, you should have a separate patch for OvmfPkg. This is required by our development workflow, but it's also

Re: [edk2] Bug 843 - Need to remove unnecessary return statements in void functions of EDKII.

Hello Younas, On 06/11/18 09:17, Mohammad Younas Khan Pathan wrote: > Hi all, > > Please find the differences updated below, review and share your comments: (1) Please submit the patch according to the edk2 development process.

Re: [edk2] [PATCH] BaseTools/tools_def IA32: disable PIE code generation explicitly

_GCC5_IA32_RC_FLAGS = DEF(GCC_IA32_RC_FLAGS) > *_GCC5_IA32_OBJCOPY_FLAGS= > *_GCC5_IA32_NASM_FLAGS = -f elf32 > Acked-by: Laszlo Ersek ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdeModulePkg/EmmcDxe: demote DEBUG print to DEBUG_BLKIO

_BLKIO, > + "Emmc%a(): Part %d Lba 0x%x BlkNo 0x%x Event %p with %r\n", > + IsRead ? "Read " : "Write", Partition->PartitionType, Lba, BlockNum, > + (Token != NULL) ? Token->Event : NULL, Status)); > > Lba += BlockNum; >

Re: [edk2] [PATCH] MdePkg/BaseIoLibIntrinsic: make BaseIoLibIntrinsic safe for ArmVirt/KVM

On 06/07/18 12:46, Ard Biesheuvel wrote: > KVM on ARM refuses to decode load/store instructions used to perform > I/O to emulated devices, and instead relies on the exception syndrome > information to describe the operand register, access size, etc. > This is only possible for instructions that

Re: [edk2] [PATCH] MdePkg/BaseIoLibIntrinsic: make BaseIoLibIntrinsic safe for ArmVirt/KVM

On 06/07/18 17:09, Ard Biesheuvel wrote: > On 7 June 2018 at 17:08, Gao, Liming wrote: >> Ard: >> If this library instance is specific to ARM emulator with KVM, how about >> add it into ArmVirtPkg? >> > > Laszlo, do you want to take this question? Certainly. Liming, in commit b6d11d7c4678,

Re: [edk2] Bug 868 - Need to add several functions related to date and time in BaseLib.

On 06/06/18 10:21, Mohammad Younas Khan Pathan wrote: > Hi All, > > If there is any generic library function, then we do not need to have > 2 or more definitions for same function like IsLeapYear(). > > Searching for 'isleapyear' > By Mask: > *.c >

Re: [edk2] Bug 843 - Need to remove unnecessary return statements in void functions of EDKII.

Hello Younas, On 06/06/18 10:28, Mohammad Younas Khan Pathan wrote: > Hi all, > > I have updated the changes after removing all the unecessary return > statements in EDKII packages. > > I have created EDKIIBug843 branch under master. > Also attached the changes here. > > Please help to review

Re: [edk2] [PATCH] ArmPkg/ArmSmcPsciResetSystemLib: implement fallback for warm reboot

On 06/06/18 14:37, Ard Biesheuvel wrote: > Implement ResetSystemLib's EnterS3WithImmediateWake() routine using > a jump back to the PEI entry point with interrupts and MMU+caches > disabled. This is only possible at boot time, when we are sure that > the current CPU is the only one up and running.

Re: [edk2] 4MB flash size as build default.

On 06/06/18 05:05, Prerna wrote: > Hi Laszlo, > I noticed that the following commit was used to make the 4MB flash layout > the default for edk2 builds briefly: > > bba8dfbec3bb OvmfPkg: make the 4MB flash size the default > > However, it was later reverted : > > 6e49d01cfb43 Revert "OvmfPkg:

Re: [edk2] [PATCH] ArmVirtPkg: implement KVM safe IoLib instance

On 06/05/18 13:05, Ard Biesheuvel wrote: > KVM on ARM refuses to decode load/store instructions used to perform > I/O to emulated devices, and instead relies on the exception syndrome > information to describe the operand register, access size, etc. > This is only possible for instructions that

Re: [edk2] [RFC PATCH] MdePkg/BaseIoLibIntrinsic ARM AARCH64: avoid C code for MMIO access

ry reason. The C code is not wrong (knowing the compiler), and the generated assembly is also not wrong on the bare metal. I don't insist though that you update the commit message; I prefer working code to documentation that's polished to my taste. :) Acked-by: Laszlo Ersek Th

Re: [edk2] [PATCH] ArmVirtPkg/ArmVirtQemu ARM: work around KVM limitations in LTO build

On 06/04/18 17:30, Ard Biesheuvel wrote: > On 4 June 2018 at 17:18, Laszlo Ersek wrote: >> On 06/04/18 16:50, Ard Biesheuvel wrote: >>> KVM on ARM refuses to decode load/store instructions used to perform >>> I/O to emulated devices, and instead relies on the excepti

Re: [edk2] [PATCH] ArmVirtPkg/ArmVirtQemu ARM: work around KVM limitations in LTO build

On 06/04/18 16:50, Ard Biesheuvel wrote: > KVM on ARM refuses to decode load/store instructions used to perform > I/O to emulated devices, and instead relies on the exception syndrome > information to describe the operand register, access size, etc. > This is only possible for instructions that

Re: [edk2] [PATCH 1/3] MdeModulePkg/DxeResetSystemLib: Avoid depending on UefiRuntimeLib

Hi Ray, On 06/01/18 09:22, Ruiyu Ni wrote: > Current DxeResetSystemLib depends on UefiRuntimeLib because it calls > EfiResetSystem() API exposed by UefiRuntimeLib. > > Due to the commit XXX which reverts UefiRuntimeLib to only support I really just cursorily skimmed the commit messages here,

Re: [edk2] [Patch 1/5] Build Spec: Add !error statement support

Hello Yonghong, On 05/31/18 02:56, Yonghong Zhu wrote: > Cc: Liming Gao > Cc: Michael Kinney > Cc: Kevin W Shaw > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Yonghong Zhu > --- > 8_pre-build_autogen_stage/82_auto-generation_process.md | 6 ++ > README.md

Re: [edk2] [Patch][edk2-platforms/devel-MinnowBoardMax-UDK2017] Vlv2TbltDevicePkg: Change SMM stack size

On 05/31/18 08:43, Guo, Mang wrote: > Old SMM stack size was 0x2000 which was not enough for Windows 10 16299 > version. Because this version OS needs larger SMM stack size to set variable. > Changed SMM stack size from 0x2000 to 0x4000 to fix this issue. > >

Re: [edk2] [Patch] OvmfPkg BasePciCapLib: Fix VS build failure

On 05/29/18 07:04, Liming Gao wrote: > Fix VS warning C4244: 'function': conversion from 'UINT32' to 'UINT16', > possible loss of data. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Liming Gao > Cc: Laszlo Ersek > --- > OvmfP

Re: [edk2] [PATCH] OvmfPkg: raise DXEFV size to 11 MB

On 05/28/18 20:49, Laszlo Ersek wrote: > Almost exactly two years after commit 2f7b34b20842f, we've grown out the > 10MB DXEFV: > >> build -a IA32 -a X64 -p OvmfPkg/OvmfPkgIa32X64.dsc -b NOOPT -t GCC48 \ >> -D SMM_REQUIRE -D SECURE_BOOT_ENABLE -D TLS_ENABLE -D E

Re: [edk2] [PATCH] OvmfPkg: raise DXEFV size to 11 MB

k on the refactoring, and the patch fixes a build issue. Thanks! Laszlo >> -Original Message- >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of >> Laszlo Ersek >> Sent: Tuesday, May 29, 2018 2:50 AM >> To: edk2-devel-01 >>

[edk2] [PATCH] OvmfPkg: raise DXEFV size to 11 MB

der: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek --- Notes: - repo & branch: https://github.com/lersek/edk2.git ; dxefv_11mb - regression-tested with the "crash" tool for vmcore analysis - regression-tested using S3 suspend/resume with my u

Re: [edk2] [PATCH v3 3/5] MdePkg/DxeServicesLib: introduce AllocatePeiAccessiblePages routine

MdePkg/Library/DxeServicesLib/Allocate.c | 54 +++ > MdePkg/Library/DxeServicesLib/DxeServicesLib.inf | 11 +++- > MdePkg/Library/DxeServicesLib/X64/Allocate.c | 69 > 4 files changed, 155 insertions(+), 2 deletions(-) Reviewed-by: Laszlo Ersek &

Re: [edk2] smm lock query

On 05/27/18 22:44, Andrew Fish wrote: > > >> On May 27, 2018, at 9:47 AM, Marvin H?user >> wrote: >> >> Good day Abhishek, >> >> I CC'd the MdeModulePkg maintainers, Ruiyu for the Platform BDS aspect >> (exposes the ReadyToLock protocol) and Laszlo for his

Re: [edk2] CpuS3DataDxe / DxeRegisterCpuFeaturesLib dependency.

On 05/25/18 12:54, Marvin H?user wrote: > Good day, > > While I was inspecting CpuS3DataDxe and the modules depending on its > PCD PcdCpuS3DataAddress, (Side remark: see e.g. the commit message on 92b87f1c8c0b, "OvmfPkg: build CpuS3DataDxe for -D SMM_REQUIRE", 2015-11-30.) > I noticed that

Re: [edk2] [PATCH v2] EmulatorPkg/SmbiosLib: Declare the correct library class.

On 05/24/18 22:36, Jordan Justen wrote: > Reviewed-by: Jordan Justen > > Pushed as 7dc7c7435e. > > On 2018-05-17 05:43:30, Marvin Häuser wrote: >> Currently, SmbiosLib declares the PcdLib library class. Update the >> declaration to declare SmbiosLib. >> >> V2: >> -

Re: [edk2] [PATCH v2 0/7] OvmfPkg, ArmVirtPkg: add and use PCI(E) Capabilities Library

On 05/23/18 22:21, Laszlo Ersek wrote: > Repo: https://github.com/lersek/edk2.git > Branch: pci_cap_v2 > > In v2, the new libs are initially introduced under OvmfPkg, rather > than MdePkg. v1 was posted at > <20180504213637.11266-1-lersek@redhat.com"&g

Re: [edk2] [PATCH v2 1/7] OvmfPkg: introduce PciCapLib

On 05/24/18 16:41, Ard Biesheuvel wrote: > On 24 May 2018 at 16:39, Laszlo Ersek <ler...@redhat.com> wrote: >> On 05/24/18 09:53, Ard Biesheuvel wrote: >>>> +RETURN_STATUS >>>> +EFIAPI >>>> +PciCapGetInfo ( >>&g

Re: [edk2] [PATCH v2 3/7] OvmfPkg: introduce PciCapPciIoLib

On 05/24/18 16:54, Ard Biesheuvel wrote: > On 24 May 2018 at 16:50, Laszlo Ersek <ler...@redhat.com> wrote: >> On 05/24/18 10:13, Ard Biesheuvel wrote: >>> On 23 May 2018 at 22:21, Laszlo Ersek <ler...@redhat.com> wrote: >>>> Add a library class, and a

Re: [edk2] [PATCH v2 7/7] OvmfPkg/Virtio10Dxe: convert to PciCapLib

On 05/24/18 10:16, Ard Biesheuvel wrote: > On 23 May 2018 at 22:21, Laszlo Ersek <ler...@redhat.com> wrote: >> Replace the manual capability list parsing in OvmfPkg/Virtio10Dxe with >> PciCapLib and PciCapPciIoLib API calls. >> >> The VIRTIO_PCI_CAP_LINK structu

Re: [edk2] [PATCH v2 3/7] OvmfPkg: introduce PciCapPciIoLib

On 05/24/18 10:13, Ard Biesheuvel wrote: > On 23 May 2018 at 22:21, Laszlo Ersek <ler...@redhat.com> wrote: >> Add a library class, and a UEFI_DRIVER lib instance, that are layered on >> top of PciCapLib, and allow clients to plug an EFI_PCI_IO_PROTOCOL backend >> into

<    7   8   9   10   11   12   13   14   15   16   >