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

> On Apr 2, 2019, at 8:18 PM, Dong, Eric wrote: > > Hi Andrew, > > I double confirmed in SDM, CR2 is not included in SMRAM State Save Map. Do > you means we should add this info in the commit message? > Eric, Sorry I was confused by the commit message. I thought the state save was

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

> On Apr 1, 2019, at 9:47 AM, Laszlo Ersek wrote: > > 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. >>

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

> On Mar 29, 2019, at 2:22 PM, Desimone, Nathaniel L > wrote: > > 1. Why would you do this for 64 bit but not 32 bit? Is paging enabled on 32-bit, it is required for Long mode? Also I'm not clear why it is an enhancement given you could take a periodic SMM in the kernels page fault

Re: [edk2] [PATCH V2 17/17] MdeModulePkg: Add PEIM and lib to dsc file

I understand the motivation for this change as I've done something much less portable that looks a lot like this to save the PEI XIP space I seem to remember a long time ago we add a public VA_LIST to an API and we ran into an issue due to the marker format being compiler specific. You

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

> On Mar 14, 2019, at 7:28 AM, Laszlo Ersek wrote: > > 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

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

> On Mar 13, 2019, at 1:16 PM, Brian J. Johnson wrote: > > On 3/12/19 12:28 PM, Andrew Fish via edk2-devel wrote: >>> On Mar 12, 2019, at 10:05 AM, Laszlo Ersek wrote: >>> >>> Hello Heyi, >>> >>> On 03/12/19 07:56, Heyi Guo wrote: &g

Re: [edk2] F29 Build Issue.

Andrew, This looks like a newer warning added in GCC 8 -Wall? BaseTools/Source/C/GenVtf/GenVtf.h:46:#define FIT_SIGNATURE "_FIT_ " So it looks like the intent is to copy the 8 chars in the string, but not the NULL. That is the intent of -Werror=stringop-truncation. I think

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

> 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.

Re: [edk2] UefiCpuPkg CpuDxe GDT init question?

Andrew Fish > Thank you > Yao Jiewen > > > >> -Original Message- >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of >> Andrew Fish via edk2-devel >> Sent: Monday, March 11, 2019 11:59 PM >> To: Yao, Jiewen >>

Re: [edk2] UefiCpuPkg CpuDxe GDT init question?

eal mode. > > Thanks, > > Andrew Fish > > >> Laszlo >> >>> >>> >>> >>> Thank you >>> Yao Jiewen >>> >>> >>>> -Original Message- >>>> From: edk2-devel [mailto

Re: [edk2] UefiCpuPkg CpuDxe GDT init question?

el-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, >>> >>&g

Re: [edk2] [PATCH 3/3] MdePkg/BaseSynchronizationLib: Remove inline X86 assembly code

2* %2, align 4 > %4 = load i32, i32* %2, align 4 > %5 = call i64 asm sideeffect "rdmsr", > "=A,{cx},~{dirflag},~{fpsr},~{flags}"(i32 %4) #2, !srcloc !4 > store i64 %5, i64* %3, align 8 > %6 = load i64, i64* %3, align 8 > ret i64 %6 > } > >

Re: [edk2] UefiCpuPkg CpuDxe GDT init question?

Actually it looks like the the CpuDxe driver is coded to only run if it it is loaded under 4 GB? Is that following the spec? Is that intentional? I noticed that SetCodeSelector is coded to use a far jump and that is a 32-bit absolute value? Note [rsp+4]

[edk2] UefiCpuPkg CpuDxe GDT init question?

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

Re: [edk2] [PATCH 3/3] MdePkg/BaseSynchronizationLib: Remove inline X86 assembly code

6 > } > > > The alloca, store, load, etc are the same bitcode instructions you would see > with C code. > > > A recently case that SetJump/LongJump, I updated the NASM file for both IA32 > and X64. > > Later, to my surprise, only X64 version NASM works, and IA32

Re: [edk2] [PATCH 3/3] MdePkg/BaseSynchronizationLib: Remove inline X86 assembly code

e have data on what size benefit we can get with these inline function, > from whole image level? > We can do evaluation at function level, case by case. > If we see a huge size benefit, I agree to keep this function. > If we see no size benefit, I suggest we do the cleanup for thi

Re: [edk2] [PATCH 3/3] MdePkg/BaseSynchronizationLib: Remove inline X86 assembly code

> On Mar 6, 2019, at 4:41 PM, Kinney, Michael D > wrote: > > Liming, > > That does not work either because inline assembly uses compiler specific > syntax. > > Please update with the specific list of functions that you think the inline > should be removed to improve maintenance with no

Re: [edk2] Does ARM platform produce MP protocol?

> On Mar 6, 2019, at 5:22 AM, Ard Biesheuvel wrote: > > On Wed, 6 Mar 2019 at 13:41, Achin Gupta > wrote: >> >> On Wed, Mar 06, 2019 at 10:37:58AM +0100, Ard Biesheuvel wrote: >>> (adding Achin and Charles) >>> >>> On Wed, 6 Mar 2019 at 10:16, Ni, Ray wrote:

Re: [edk2] [PATCH 3/3] MdePkg/BaseSynchronizationLib: Remove inline X86 assembly code

> On Mar 5, 2019, at 1:32 PM, Gao, Liming wrote: > > Andrew: > BZ 1163 is to remove inline X86 assembly code in C source file. But, this > patch is wrong. I have gave my comments to update this patch. > Why do we want to remove inline X86 assembly. As I mentioned it will lead to larger

Re: [edk2] [PATCH 3/3] MdePkg/BaseSynchronizationLib: Remove inline X86 assembly code

Shenglei, I was confused by the names of these patches. From a C point of view this is inline assembly: VOID EFIAPI CpuBreakpoint ( VOID ) { __asm__ __volatile__ ("int $3"); } These patches seem to be removing GAS and MASM assembly files, but not the inline assembly *.c files? We don't want

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

Reviewed-by: Andrew Fish > On Feb 27, 2019, at 5:12 PM, Gao, Liming wrote: > > Reviewed-by: Liming Gao > >> -Original Message- >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of >> Laszlo Ersek >> Sent: Thursday, February 28, 2019 5:22 AM >> To: edk2-devel-01

Re: [edk2] [PATCH] OvmfPkg/Sec: Clear the Cache Disable flag in the CR0 register

> On Feb 18, 2019, at 5:23 AM, Laszlo Ersek wrote: > > generic comment (applies to all NASM usage I guess): > > On 02/18/19 11:10, Jordan Justen wrote: > >> +mov eax, cr0 >> +and eax, ~(1 << 30) >> +mov cr0, eax > >> +mov rax, cr0 >> +and eax, ~(1 <<

Re: [edk2] EmulatorPkg Unix Host Segmentation fault.

> On Feb 15, 2019, at 11:40 PM, Ni, Ray > wrote: > > I also met this issue. > I found three solutions: > 1. Forcing PeiMain CC flag to "-O0" works. > 2. Changing EmulatorPkg/Sec to not produce TemporaryRamSupportPpi also works. > 3. Implement the temporary migration

Re: [edk2] [edk2-announce] Community Meeting Minutes

> On Feb 8, 2019, at 9:33 AM, Rebecca Cran via edk2-devel > wrote: > > > On February 8, 2019 at 2:01:59 AM, Laszlo Ersek > (ler...@redhat.com(mailto:ler...@redhat.com)) wrote: > >> I don't see the workflow modification as viable. The "patch series" >> concept is integral to every single

Re: [edk2] Hello Andrew query on BdsSetMemoryTypeInformationVariable

Forwarding to the edk2 list > On Feb 8, 2019, at 8:28 AM, galla rao wrote: > > Hi Andrew, > > Am sorry for direct message! > > There is a function BdsSetMemoryTypeInformationVariable which causes a reset > when i enabled Secureboot related drivers > > Any clue why this function is

Re: [edk2] Self-replicating image

> On Feb 8, 2019, at 6:42 AM, Tomas Pilar (tpilar) > wrote: > > Hi, > > I am currently pondering the most elegant way to implement capsule update for > our devices that would work in the presence of multiple devices in the host. > > Capsule allows embedding a driver that is executed prior

Re: [edk2] [PATCH v4 edk2-platforms 01/23] Silicon/Broadcom/Bcm282x: Add interrupt driver

> On Jan 31, 2019, at 11:57 AM, Leif Lindholm wrote: > > +Andrew, Laszlo, Mike. > > On Thu, Jan 31, 2019 at 06:19:48PM +0100, Ard Biesheuvel wrote: >> On Thu, 31 Jan 2019 at 16:24, Leif Lindholm wrote: >>> >>> On Tue, Jan 29, 2019 at 04:26:33PM +, Pete Batard wrote:

Re: [edk2] [RFC] Proposal to split Pkgs

> On Jan 28, 2019, at 9:59 PM, Ni, Ray wrote: > > Hello, > I'd like to propose to split today's BIG packages in following ways: > > ==Overview = > > 1. Separate Industry standard definitions from UEFI and PI interfaces. Ray, >From a big picture point of view

Re: [edk2] [PATCH edk2-staging 10/20] IntelUndiPkg/XGigUndiDxe: drop StdLibC library class reference

> On Jan 30, 2019, at 9:26 AM, Ryszard Knop > wrote: > > That's actually not quite correct - we need this package to build on > IA32. It's named rather unfortunately, since it's not the EDK2 StdLibC, > but rather a package in this repository - see IntelUndiPkg/LibC. It > contains the bare

Re: [edk2] [PATCH edk2-staging 07/20] IntelUndiPkg/XGigUndiDxe: drop definition of gImageHandle

> On Jan 30, 2019, at 8:05 AM, Ryszard Knop > wrote: > > Hmm, is there a list/something I can generate to see which globals > build tools emit? There are some more variables I'd happily get rid > of, eg if I could drop gSystemTable and others. > Ryszard, You need to use libs by including

Re: [edk2] [question] A piece of log.txt showed in uefi shell is not the same as showed in notepad++

Krishna, From an EFI point of view BackSpace 0x08, LF 0x0A, and CR 0xD are defined for a ConOut device. From Ascii Control Codes: 0x0C - Form Feed 0x0E - Shift Out The Shift Out is used with graphics characters. How did you dump the log? If EFI sends data to a serial terminal then it would

Re: [edk2] [question] A piece of log.txt showed in uefi shell is not the same as showed in notepad++

> On Jan 23, 2019, at 7:17 PM, krishnaLee wrote: > > Hi, > I dumped a small log.txt from my work,but the log.txt showed in uefi shell,is > not the same as it showed in notepad++. > I had upload the log here: > https://github.com/krishna116/test/blob/master/log.zip > > > it seems the log

Re: [edk2] Network Stack Budgeting

> On Jan 23, 2019, at 8:27 AM, Tomas Pilar (tpilar) > wrote: > > >> The set of devices connected during BDS is platform policy. It is not >> the "network stack" that calls Snp.Start(), but the platform BDS code >> that calls gBS->ConnectController() on the device, possibly without a >> good

Re: [edk2] Drop CSM support in OvmfPkg?

> On Jan 22, 2019, at 7:43 PM, Ni, Ray wrote: > >> -Original Message- >> From: David Woodhouse mailto:dw...@infradead.org>> >> Sent: Wednesday, January 23, 2019 12:23 AM >> To: Ni, Ray mailto:ray...@intel.com>>; Gerd Hoffmann >> mailto:kra...@redhat.com>>; >> Laszlo Ersek

Re: [edk2] History question about Base.h and its alternate parallel name space.... Should we change it?

specific set that would have the most >> benefit? >>> >>> Is EFI_GUID sufficient? >>> >>> Mike >>> >>>> -Original Message- >>>> From: Felix Polyudov [mailto:fel...@ami.com] >>>> Sent: Wednesday, January 16, 2019 3:1

Re: [edk2] History question about Base.h and its alternate parallel name space.... Should we change it?

icant impact on the ability to detect poorly >> written Base libraries. >> >> -Original Message- >> From: edk2-devel [mailto:edk2-devel- >> boun...@lists.01.org] On Behalf Of Andrew Fish via edk2- >> devel >> Sent: Wednesday, January 16, 2019 5:18 PM

Re: [edk2] Query on Variable Services

> On Jan 17, 2019, at 10:26 AM, galla rao wrote: > > Thanks Andrew! > > SPI driver has failed the call to, in the log i could see the failure > > Status = gDS->SetMemorySpaceAttributes ( > > BaseAddress, > > Length, > >

Re: [edk2] Query on Variable Services

Galla, The PCD value usually get set as the result of the build. EFI_MEMORY_RUNTIME attribute is used to request a virtual mapping from the OS. When the variable services are called from the OS the run in a virtual address space provided by the OS. Thus trying to access 0xFFE0 would page

Re: [edk2] History question about Base.h and its alternate parallel name space.... Should we change it?

ck doing anything that is not Base. So I'm asking if redefining the name for EFI_GUID to GUID for Base is really that helpful? Thanks, Andrew Fish > Thanks, > > Mike > >> -Original Message- >> From: edk2-devel [mailto:edk2-devel- >> boun...@lists.

[edk2] History question about Base.h and its alternate parallel name space.... Should we change it?

I had some one ask me recently why EFI_GUID does not work with #include . I explained they needed to use GUID vs. EFI_GUID. That prompted the question of why we have 2 names for the same thing. Well the historical answer was kind of political as some team wanted to use edk2, but not

Re: [edk2] Missing PI definitions?

Liming, Sorry I guess I was confusing this with EFI_RESOURCE_ATTRIBUTE_TESTED. I'll a little confused that it is implementation given it is passed into gDS->AddMemorySpace() the PI Spec defines the values of Capabilities to be defined in the UEFI Spec. as the GetMemoryMap() attributes. It is